[kitten] New URI Discovery Draft

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] New URI Discovery Draft

Nathaniel McCallum-5
https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc
overy/

I've submitted a new version of the draft. This version matches the
code that is now merged into MIT Kerberos.

We need to move forward. If that is as an individual submission, then
so be it. But we really can't wait any longer. So unless I hear some
noise to the contrary ASAP, I plan to go this route.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Petr Spacek
On 24.9.2016 00:25, Nathaniel McCallum wrote:
> https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc
> overy/
>
> I've submitted a new version of the draft. This version matches the
> code that is now merged into MIT Kerberos.
>
> We need to move forward. If that is as an individual submission, then
> so be it. But we really can't wait any longer. So unless I hear some
> noise to the contrary ASAP, I plan to go this route.

Hello,

in general it makes sense. The new URI format opened an encoding-Pandora-box
so it needs more work to make it fully specified. Here are nits I found in the
03 version of the draft:

1]
> 4.  Required URI Format
>    krb5srv:[flags]:transport:residual
Nitpick: I do not really like naming "transport:residual". Something like
"transport-type:transport-options" would be more descriptive.


2] Is this a good idea?
>    Flags are not considered critical, therefore flags that are not used
>    or unknown to the implementation SHOULD be ignored.
Just wondering out loud, not insisting on it:
If we say there is no criticality, it will be impossible to add later on.

What about using capitalization to indicate criticality of a flag? Records
with critical but unsupported flags should be skipped as if there were not
present in DNS. Records with non-critical unsupported flags should be used as
usual.

Or maybe we can limit valid flags to lowercase ASCII letters for now so there
is a room for extension in future?


3] In any case, there is disagreement between
> 4.2.  Flags
>    This field contains a sequence of zero or more case-insensitive
vs.
> 9.1.  Kerberos Server Discovery Flags
> 9.1.1.  Registration Template
>    Value:  A single unique ASCII character that identifies the entry,

"A single unique ASCII character" is case-sensitive by definition. This
conflicts with case-insensitivity defined in 4.2.


3] The draft is not clear on whether transport field is case-sensitive or not.
> 4.3.  Transport
> 9.2.  Kerberos Server Discovery Transport Types


4] Residual formats are not sufficiently specified:

> 4.4.  Residual
> 9.2.  Kerberos Server Discovery Transport Types
> 9.2.2.  Initial Registry Contents
>
>    o Value: "udp"
>    o Description: User Datagram Protocol
>    o Residual Format: "host[:port]"
>    o Case Sensitive: None
>    o Default KDC Port: 88
>    o Default Admin Service Port: 749
>    o Default Password Service Port: 464
>    o Reference: [RFC0768]

There is no definition of "host" and there is none in RFC 768.
Can it be IP(v?) address?
Can it be DNS name?
How this field should be encoded into the URI?

>    o Value: "tcp"
>    o Description: Transport Control Protocol
>    o Residual Format: "host[:port]"
>    o Case Sensitive: None
>    o Default KDC Port: 88
>    o Default Admin Service Port: 749
>    o Default Password Service Port: 464
>    o Reference: [RFC0793]

Again there is no definition of "host".
Can it be IP(v?) address?
Can it be DNS name?
How this field should be encoded into the URI?

>    o Value: "kkdcp"
>    o Description: Kerberos Key Distribution Center Proxy Protocol
>    o Residual Format: https://host[:port][/path]

This is technically URI inside URI, am I right?
How is it encoded? Should usual %-encoding be used here?
> 10.1.  URI Format Examples
suggest that %-encoding is not used. I would like to see this clearly
specified and explained why not.

At this point I would rather say "use URL as specified by [MS-KKDCP]" instead
of specifying "https://host[:port][/path]".

Also, to make this bullet-proof, I would mention that "/KdcProxy" must be
explicitly specified in the URI record and is not implicitly assumed by clients.

>    o Case Sensitive: [/path]
>    o Default KDC Port: 443
>    o Default Admin Service Port: 443
>    o Default Password Service Port: 443
>    o Reference: [MS-KKDCP]


Other than that it makes sense and I'm looking forward to see this deployed!

--
Petr^2 Spacek

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Greg Hudson
On 09/24/2016 12:29 PM, Petr Spacek wrote:
> Just wondering out loud, not insisting on it:
> If we say there is no criticality, it will be impossible to add later on.

I think that's fine.  Let's not over-engineer this.

> What about using capitalization to indicate criticality of a flag?

It's definitely not worth introducing case-sensitivity to an otherwise
case-insensitive DNS value format.

> Or maybe we can limit valid flags to lowercase ASCII letters for now so there
> is a room for extension in future?

Criticality cannot be introduced later as an extension.  But again, I
don't think we need to engineer critical flags into this spec.  Flags
are only barely necessary at all.

> There is no definition of "host" and there is none in RFC 768.
> Can it be IP(v?) address?
> Can it be DNS name?
> How this field should be encoded into the URI?

Per the implementation, it can be a DNS hostname, and IPv4 address, or
an IPv6 address enclosed in square brackets.

>>    o Value: "kkdcp"
>>    o Description: Kerberos Key Distribution Center Proxy Protocol
>>    o Residual Format: https://host[:port][/path]
>
> This is technically URI inside URI, am I right?
> How is it encoded? Should usual %-encoding be used here?

% encoding is not used.  Formally, you can imagine the https URI syntax
being incorporated into the syntax of the krb5srv part.  I'm not sure
how best to express that in the document.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Matt Rogers
In reply to this post by Petr Spacek
On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote:

> On 24.9.2016 00:25, Nathaniel McCallum wrote:
> >
> > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-
> > disc
> > overy/
> >
> > I've submitted a new version of the draft. This version matches the
> > code that is now merged into MIT Kerberos.
> >
> > We need to move forward. If that is as an individual submission,
> > then
> > so be it. But we really can't wait any longer. So unless I hear
> > some
> > noise to the contrary ASAP, I plan to go this route.
>
> Hello,
>
> in general it makes sense. The new URI format opened an encoding-
> Pandora-box
> so it needs more work to make it fully specified. Here are nits I
> found in the
> 03 version of the draft:
>

Hi Petr, thanks for reviewing! 

> 1]
> >
> > 4.  Required URI Format
> >    krb5srv:[flags]:transport:residual
> Nitpick: I do not really like naming "transport:residual". Something
> like
> "transport-type:transport-options" would be more descriptive.
>

"transport-options" may make it seem that it's an optional field or
carries something other than a hostname or URI for the client to
contact. How about "transport-type:transport-target"?

>
> 2] Is this a good idea?
> >
> >    Flags are not considered critical, therefore flags that are not
> > used
> >    or unknown to the implementation SHOULD be ignored.
> Just wondering out loud, not insisting on it:
> If we say there is no criticality, it will be impossible to add later
> on.
>
> What about using capitalization to indicate criticality of a flag?
> Records
> with critical but unsupported flags should be skipped as if there
> were not
> present in DNS. Records with non-critical unsupported flags should be
> used as
> usual.
>
> Or maybe we can limit valid flags to lowercase ASCII letters for now
> so there
> is a room for extension in future?

I think avoiding having case-sensitive fields is the most appropriate
thing to do for DNS data, our exception here being the path part of a
KKDCP URL, which we can leave as defined by MS-KKDCP (see below)

If we want to later add criticality to a flag then it could be a flag
prepended by a '!' or some such character rather than using the case.

>
>
> 3] In any case, there is disagreement between
> >
> > 4.2.  Flags
> >    This field contains a sequence of zero or more case-insensitive
> vs.
> >
> > 9.1.  Kerberos Server Discovery Flags
> > 9.1.1.  Registration Template
> >    Value:  A single unique ASCII character that identifies the
> > entry,
>
> "A single unique ASCII character" is case-sensitive by definition.
> This
> conflicts with case-insensitivity defined in 4.2.
>
>
> 3] The draft is not clear on whether transport field is case-
> sensitive or not.
> >
> > 4.3.  Transport
> > 9.2.  Kerberos Server Discovery Transport Types
>

I'll clear this up.

>
> 4] Residual formats are not sufficiently specified:
> >
> > 4.4.  Residual
> > 9.2.  Kerberos Server Discovery Transport Types
> > 9.2.2.  Initial Registry Contents
> >
> >    o Value: "udp"
> >    o Description: User Datagram Protocol
> >    o Residual Format: "host[:port]"
> >    o Case Sensitive: None
> >    o Default KDC Port: 88
> >    o Default Admin Service Port: 749
> >    o Default Password Service Port: 464
> >    o Reference: [RFC0768]
>
> There is no definition of "host" and there is none in RFC 768.
> Can it be IP(v?) address?
> Can it be DNS name?
> How this field should be encoded into the URI?
>
> >
> >    o Value: "tcp"
> >    o Description: Transport Control Protocol
> >    o Residual Format: "host[:port]"
> >    o Case Sensitive: None
> >    o Default KDC Port: 88
> >    o Default Admin Service Port: 749
> >    o Default Password Service Port: 464
> >    o Reference: [RFC0793]
>
> Again there is no definition of "host".
> Can it be IP(v?) address?
> Can it be DNS name?
> How this field should be encoded into the URI?

Good point, I'll clear this up as well.

>
> >
> >    o Value: "kkdcp"
> >    o Description: Kerberos Key Distribution Center Proxy Protocol
> >    o Residual Format: https://host[:port][/path]
>
> This is technically URI inside URI, am I right?
> How is it encoded? Should usual %-encoding be used here?
> >
> > 10.1.  URI Format Examples
> suggest that %-encoding is not used. I would like to see this clearly
> specified and explained why not.
>
> At this point I would rather say "use URL as specified by [MS-KKDCP]"
> instead
> of specifying "https://host[:port][/path]".

I agree with this, especially since MS-KKDCP defines the URI with
RFC3986 encoding rules. I think then the registration template can also
leave out the case-sensitivity definition as the path is defined as
case-sensitive with RFC3986.

>
> Also, to make this bullet-proof, I would mention that "/KdcProxy"
> must be
> explicitly specified in the URI record and is not implicitly assumed
> by clients.
>

Sure, that makes sense. 

Thanks again,
Matt

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Petr Spacek
On 26.9.2016 17:55, Matt Rogers wrote:

> On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote:
>> On 24.9.2016 00:25, Nathaniel McCallum wrote:
>>>
>>> https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-
>>> disc
>>> overy/
>>>
>>> I've submitted a new version of the draft. This version matches the
>>> code that is now merged into MIT Kerberos.
>>>
>>> We need to move forward. If that is as an individual submission,
>>> then
>>> so be it. But we really can't wait any longer. So unless I hear
>>> some
>>> noise to the contrary ASAP, I plan to go this route.
>>
>> Hello,
>>
>> in general it makes sense. The new URI format opened an encoding-
>> Pandora-box
>> so it needs more work to make it fully specified. Here are nits I
>> found in the
>> 03 version of the draft:
>>
>
> Hi Petr, thanks for reviewing!
>
>> 1]
>>>
>>> 4.  Required URI Format
>>>    krb5srv:[flags]:transport:residual
>> Nitpick: I do not really like naming "transport:residual". Something
>> like
>> "transport-type:transport-options" would be more descriptive.
>>
>
> "transport-options" may make it seem that it's an optional field or
> carries something other than a hostname or URI for the client to
> contact. How about "transport-type:transport-target"?

Sounds good.


>> 2] Is this a good idea?
>>>
>>>    Flags are not considered critical, therefore flags that are not
>>> used
>>>    or unknown to the implementation SHOULD be ignored.
>> Just wondering out loud, not insisting on it:
>> If we say there is no criticality, it will be impossible to add later
>> on.
>>
>> What about using capitalization to indicate criticality of a flag?
>> Records
>> with critical but unsupported flags should be skipped as if there
>> were not
>> present in DNS. Records with non-critical unsupported flags should be
>> used as
>> usual.
>>
>> Or maybe we can limit valid flags to lowercase ASCII letters for now
>> so there
>> is a room for extension in future?
>
> I think avoiding having case-sensitive fields is the most appropriate
> thing to do for DNS data, our exception here being the path part of a
> KKDCP URL, which we can leave as defined by MS-KKDCP (see below)
>
> If we want to later add criticality to a flag then it could be a flag
> prepended by a '!' or some such character rather than using the case.

Fine with me. The main point is that if we do not define criticality or at
least reserved character now it will be impossible to enforce it on older
clients. Maybe we can reserve "!" character now and say that character
immediately following "!" must be ignored by clients implementing this version
of the draft?


>> 3] In any case, there is disagreement between
>>>
>>> 4.2.  Flags
>>>    This field contains a sequence of zero or more case-insensitive
>> vs.
>>>
>>> 9.1.  Kerberos Server Discovery Flags
>>> 9.1.1.  Registration Template
>>>    Value:  A single unique ASCII character that identifies the
>>> entry,
>>
>> "A single unique ASCII character" is case-sensitive by definition.
>> This
>> conflicts with case-insensitivity defined in 4.2.
>>
>>
>> 3] The draft is not clear on whether transport field is case-
>> sensitive or not.
>>>
>>> 4.3.  Transport
>>> 9.2.  Kerberos Server Discovery Transport Types
>>
>
> I'll clear this up.
>
>>
>> 4] Residual formats are not sufficiently specified:
>>>
>>> 4.4.  Residual
>>> 9.2.  Kerberos Server Discovery Transport Types
>>> 9.2.2.  Initial Registry Contents
>>>
>>>    o Value: "udp"
>>>    o Description: User Datagram Protocol
>>>    o Residual Format: "host[:port]"
>>>    o Case Sensitive: None
>>>    o Default KDC Port: 88
>>>    o Default Admin Service Port: 749
>>>    o Default Password Service Port: 464
>>>    o Reference: [RFC0768]
>>
>> There is no definition of "host" and there is none in RFC 768.
>> Can it be IP(v?) address?
>> Can it be DNS name?
>> How this field should be encoded into the URI?
>>
>>>
>>>    o Value: "tcp"
>>>    o Description: Transport Control Protocol
>>>    o Residual Format: "host[:port]"
>>>    o Case Sensitive: None
>>>    o Default KDC Port: 88
>>>    o Default Admin Service Port: 749
>>>    o Default Password Service Port: 464
>>>    o Reference: [RFC0793]
>>
>> Again there is no definition of "host".
>> Can it be IP(v?) address?
>> Can it be DNS name?
>> How this field should be encoded into the URI?
>
> Good point, I'll clear this up as well.
>
>>
>>>
>>>    o Value: "kkdcp"
>>>    o Description: Kerberos Key Distribution Center Proxy Protocol
>>>    o Residual Format: https://host[:port][/path]
>>
>> This is technically URI inside URI, am I right?
>> How is it encoded? Should usual %-encoding be used here?
>>>
>>> 10.1.  URI Format Examples
>> suggest that %-encoding is not used. I would like to see this clearly
>> specified and explained why not.
>>
>> At this point I would rather say "use URL as specified by [MS-KKDCP]"
>> instead
>> of specifying "https://host[:port][/path]".
>
> I agree with this, especially since MS-KKDCP defines the URI with
> RFC3986 encoding rules. I think then the registration template can also
> leave out the case-sensitivity definition as the path is defined as
> case-sensitive with RFC3986.
>
>>
>> Also, to make this bullet-proof, I would mention that "/KdcProxy"
>> must be
>> explicitly specified in the URI record and is not implicitly assumed
>> by clients.
>>
>
> Sure, that makes sense.
>
> Thanks again,
I'm happy to review it again.

--
Petr^2 Spacek

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Matt Rogers
On Mon, 2016-09-26 at 18:01 +0200, Petr Spacek wrote:


> Fine with me. The main point is that if we do not define criticality
> or at
> least reserved character now it will be impossible to enforce it on
> older
> clients. Maybe we can reserve "!" character now and say that
> character
> immediately following "!" must be ignored by clients implementing
> this version
> of the draft?
>

I'm thinking that the flag should not be ignored, but just that in this
version of the draft '!' is reserved but ignored and no criticality is
assumed on the following flag. In a future version the '!' could
indicate that the following flag is critical.

Regards,
Matt

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Nathaniel McCallum-5
In reply to this post by Petr Spacek
On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote:

> On 24.9.2016 00:25, Nathaniel McCallum wrote:
> > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-
> > disc
> > overy/
> >
> > I've submitted a new version of the draft. This version matches the
> > code that is now merged into MIT Kerberos.
> >
> > We need to move forward. If that is as an individual submission,
> > then
> > so be it. But we really can't wait any longer. So unless I hear
> > some
> > noise to the contrary ASAP, I plan to go this route.
>
>
> Hello,
>
> in general it makes sense. The new URI format opened an encoding-
> Pandora-box
> so it needs more work to make it fully specified. Here are nits I
> found in the
> 03 version of the draft:
>
> 1]
> > 4.  Required URI Format
> >    krb5srv:[flags]:transport:residual
>
> Nitpick: I do not really like naming "transport:residual". Something
> like
> "transport-type:transport-options" would be more descriptive.
>
>
> 2] Is this a good idea?
> >    Flags are not considered critical, therefore flags that are not
> > used
> >    or unknown to the implementation SHOULD be ignored.
>
> Just wondering out loud, not insisting on it:
> If we say there is no criticality, it will be impossible to add later
> on.
>
> What about using capitalization to indicate criticality of a flag?
> Records
> with critical but unsupported flags should be skipped as if there
> were not
> present in DNS. Records with non-critical unsupported flags should be
> used as
> usual.
>
> Or maybe we can limit valid flags to lowercase ASCII letters for now
> so there
> is a room for extension in future?
>
>
> 3] In any case, there is disagreement between
> > 4.2.  Flags
> >    This field contains a sequence of zero or more case-insensitive
>
> vs.
> > 9.1.  Kerberos Server Discovery Flags
> > 9.1.1.  Registration Template
> >    Value:  A single unique ASCII character that identifies the
> > entry,
>
>
> "A single unique ASCII character" is case-sensitive by definition.
> This
> conflicts with case-insensitivity defined in 4.2.

There is actually a bigger issue here which is that referring to it as
"ASCII character" is too broad. What we really want here are the
letters a-z.

> 3] The draft is not clear on whether transport field is case-
> sensitive or not.
> > 4.3.  Transport
> > 9.2.  Kerberos Server Discovery Transport Types
>
>
>
> 4] Residual formats are not sufficiently specified:
> > 4.4.  Residual
> > 9.2.  Kerberos Server Discovery Transport Types
> > 9.2.2.  Initial Registry Contents
> >
> >    o Value: "udp"
> >    o Description: User Datagram Protocol
> >    o Residual Format: "host[:port]"
> >    o Case Sensitive: None
> >    o Default KDC Port: 88
> >    o Default Admin Service Port: 749
> >    o Default Password Service Port: 464
> >    o Reference: [RFC0768]
>
>
> There is no definition of "host" and there is none in RFC 768.
> Can it be IP(v?) address?
> Can it be DNS name?
> How this field should be encoded into the URI?
>
> >    o Value: "tcp"
> >    o Description: Transport Control Protocol
> >    o Residual Format: "host[:port]"
> >    o Case Sensitive: None
> >    o Default KDC Port: 88
> >    o Default Admin Service Port: 749
> >    o Default Password Service Port: 464
> >    o Reference: [RFC0793]
>
>
> Again there is no definition of "host".
> Can it be IP(v?) address?
> Can it be DNS name?
> How this field should be encoded into the URI?
>
> >    o Value: "kkdcp"
> >    o Description: Kerberos Key Distribution Center Proxy Protocol
> >    o Residual Format: https://host[:port][/path]
>
>
> This is technically URI inside URI, am I right?
> How is it encoded? Should usual %-encoding be used here?
> > 10.1.  URI Format Examples
>
> suggest that %-encoding is not used. I would like to see this clearly
> specified and explained why not.
>
> At this point I would rather say "use URL as specified by [MS-KKDCP]"
> instead
> of specifying "https://host[:port][/path]".
>
> Also, to make this bullet-proof, I would mention that "/KdcProxy"
> must be
> explicitly specified in the URI record and is not implicitly assumed
> by clients.
>
> >    o Case Sensitive: [/path]
> >    o Default KDC Port: 443
> >    o Default Admin Service Port: 443
> >    o Default Password Service Port: 443
> >    o Reference: [MS-KKDCP]
>
>
>
> Other than that it makes sense and I'm looking forward to see this
> deployed!
>
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Nathaniel McCallum-5
In reply to this post by Petr Spacek
On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote:

> On 24.9.2016 00:25, Nathaniel McCallum wrote:
> > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-
> > disc
> > overy/
> >
> > I've submitted a new version of the draft. This version matches the
> > code that is now merged into MIT Kerberos.
> >
> > We need to move forward. If that is as an individual submission,
> > then
> > so be it. But we really can't wait any longer. So unless I hear
> > some
> > noise to the contrary ASAP, I plan to go this route.
>
>
> Hello,
>
> in general it makes sense. The new URI format opened an encoding-
> Pandora-box
> so it needs more work to make it fully specified. Here are nits I
> found in the
> 03 version of the draft:
>
> 1]
> > 4.  Required URI Format
> >    krb5srv:[flags]:transport:residual
>
> Nitpick: I do not really like naming "transport:residual". Something
> like
> "transport-type:transport-options" would be more descriptive.

transport-info? transport-data? transport-spec?

> 2] Is this a good idea?
> >    Flags are not considered critical, therefore flags that are not
> > used
> >    or unknown to the implementation SHOULD be ignored.
>
> Just wondering out loud, not insisting on it:
> If we say there is no criticality, it will be impossible to add later
> on.
>
> What about using capitalization to indicate criticality of a flag?
> Records
> with critical but unsupported flags should be skipped as if there
> were not
> present in DNS. Records with non-critical unsupported flags should be
> used as
> usual.
>
> Or maybe we can limit valid flags to lowercase ASCII letters for now
> so there
> is a room for extension in future?

I had proposed using case for criticality in another conversation and
I'm increasingly coming to prefer this method if criticality is defined
as "don't use this server if you don't understand the flag."

Note that with either case-insensitivity or critical-uppercase we have
the same number of letters. So I don't think there is any cost except
the (minor) cost of updating the exiting MIT code.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Greg Hudson
On 09/28/2016 12:07 PM, Nathaniel McCallum wrote:
> transport-info? transport-data? transport-spec?

I like transport-info.

> I had proposed using case for criticality in another conversation and
> I'm increasingly coming to prefer this method if criticality is defined
> as "don't use this server if you don't understand the flag."

My opinion hasn't changed; I still think we have no need for critical
flags, and don't want to add complexity.

(It's very normal to define an extensible protocol field with no support
for critical values.  padata and ticket flags are two examples that come
to mind.)

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Benjamin Kaduk-2
In reply to this post by Nathaniel McCallum-5
On Fri, 23 Sep 2016, Nathaniel McCallum wrote:

> https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc
> overy/
>
> I've submitted a new version of the draft. This version matches the
> code that is now merged into MIT Kerberos.
>
> We need to move forward. If that is as an individual submission, then
> so be it. But we really can't wait any longer. So unless I hear some
> noise to the contrary ASAP, I plan to go this route.

The chairs talked about this, and it seems like we've made enough progress
getting WG consensus on documents [that are now blocking on shepherd
writeups] that we're probably in a state where accepting new WG documents
can happen fairly soon.  That said, we'd really like to get some more
review on draft-ietf-kitten-rfc5653bis-03 so that can move forward as
well.  Any chance you'll be able to provide a review?

Thanks,

Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Benjamin Kaduk-2
In reply to this post by Nathaniel McCallum-5
On Fri, 23 Sep 2016, Nathaniel McCallum wrote:

> https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc
> overy/
>
> I've submitted a new version of the draft. This version matches the
> code that is now merged into MIT Kerberos.

A few comments (with no particular hat):

Section 4.2.1, "master server" is only implicitly defined; would it be
reasonable to say that such are "expected to be an authoritative source
for KDC database information, not subject to propagation delay"?

It's probably worth a forward reference to the IANA considerations
somewhere in Section 4.2 to note how new flags can be allocated.  Likewise
for the transport types in 4.3 (as well as a list of the types specified
by this document!).

I'd be slightly tempted to reorder things so section 4 comes after
sections 5, 6, and 7 (so that the queries come first and the field
contents later), but that's really a stylistic question and subject to
authorial discretion.

Sections 5, 6, and 7 say "[t]arget SHOULD contain one of the URI formats
specified in this document", but doesn't this document only contain one
(required) URI format?

Section 7 should probably note that the kadmin protocol is not
standardized and consumers must be aware of the server implementation.
(If we're really excited, we could even include a field to indicate what
the server implementation is, but that would run the risk of introducing
IETF politics at IETF LC or IESG review.)

I don't believe that the kitten list can be a designated expert (and it's
unclear what exactly the document is saying will be done for expert
review).  IIRC, the necessary things in this part are to give the IESG
guidance for selecting Designated Expert(s) (e.g., well-known kerberos
implementors, past or current krb-wg/kitten chairs, etc.), as well as
instructions for what review/criteria the expert should apply when
considering registration requests.  Requiring the expert to call for open
discussion on the kitten list can be part of the instructions to the
expert, but probably ought not be the entirety of those instructions.
Also, it's my understanding that IANA likes things to be written in the
form "IANA has done $X", though for drafts, people tend to write "IANA
[will do|has done]" with literal brackets and pipe.

We already covered the non-case-sensitivity of the flags, but as a nit,
the reference field should be to a document that describes the details of
the flag.  I don't see how the reference for the 'm' flag would not be
"[this document]".

The examples would be more useful if accompanied by prose description of
what they mean.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New URI Discovery Draft

Matt Rogers
On Thu, 2016-09-29 at 23:53 -0400, Benjamin Kaduk wrote:

Thanks for the review!

>
> A few comments (with no particular hat):
>
> Section 4.2.1, "master server" is only implicitly defined; would it
> be
> reasonable to say that such are "expected to be an authoritative
> source
> for KDC database information, not subject to propagation delay"?
>

With this re-wording would it be more appropriate to specify in the
IANA definition for 'm' and not under 4.2?

> It's probably worth a forward reference to the IANA considerations
> somewhere in Section 4.2 to note how new flags can be allocated. 
> Likewise
> for the transport types in 4.3 (as well as a list of the types
> specified
> by this document!).
>

Ack.

> I'd be slightly tempted to reorder things so section 4 comes after
> sections 5, 6, and 7 (so that the queries come first and the field
> contents later), but that's really a stylistic question and subject
> to
> authorial discretion.
>

Not a bad suggestion for the overall flow of the document.

> Sections 5, 6, and 7 say "[t]arget SHOULD contain one of the URI
> formats
> specified in this document", but doesn't this document only contain
> one
> (required) URI format?
>

Yes, that's left over from a previous revision, so I'll correct that.

> Section 7 should probably note that the kadmin protocol is not
> standardized and consumers must be aware of the server
> implementation.
> (If we're really excited, we could even include a field to indicate
> what
> the server implementation is, but that would run the risk of
> introducing
> IETF politics at IETF LC or IESG review.)
>
> I don't believe that the kitten list can be a designated expert (and
> it's
> unclear what exactly the document is saying will be done for expert
> review).  IIRC, the necessary things in this part are to give the
> IESG
> guidance for selecting Designated Expert(s) (e.g., well-known
> kerberos
> implementors, past or current krb-wg/kitten chairs, etc.), as well as
> instructions for what review/criteria the expert should apply when
> considering registration requests.  Requiring the expert to call for
> open
> discussion on the kitten list can be part of the instructions to the
> expert, but probably ought not be the entirety of those instructions.
> Also, it's my understanding that IANA likes things to be written in
> the
> form "IANA has done $X", though for drafts, people tend to write
> "IANA
> [will do|has done]" with literal brackets and pipe.
>

Ok, I'll work on revising this.

> We already covered the non-case-sensitivity of the flags, but as a
> nit,
> the reference field should be to a document that describes the
> details of
> the flag.  I don't see how the reference for the 'm' flag would not
> be
> "[this document]".
>
I'll update this reference. Also, after some further discussion about
the case-sensitivity and flag criticality issue, I think ultimately the
right thing to do for this version of the draft is to just specify that
the URI fields are case-sensitive and unknown flags must be ignored. A
registered transport can then maintain any case-sensitive elements
(such as the path extension for KKDCP) while the scheme, flags, and
transport names will be registered with their literal values so there
should not be any ambiguity on the case for those fields. 

If later on a critical flag needs to be added, then this would leave it
open to being a capital version of an existing flag or just a different
character altogether.

> The examples would be more useful if accompanied by prose description
> of
> what they mean.
>

Good point. 

Thanks again,
Matt

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten