Subject: Re: AD review comments for the GSS-API domain name specs

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Nov 2006 17:54:58 -0500

I haven't seen any discussion of my comments.

If a new draft addressing these issues were reviewed and submitted
early next week, then these could be approved on the next IESG
telechat.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Nov 2006 17:11:30 -0600

> I haven't seen any discussion of my comments.

Sorry, replies will be sent soon.

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Nov 2006 00:05:22 -0600

On Fri, Oct 20, 2006 at 08:39:14AM -0400, Sam Hartman wrote:
> These AD comments need to be fixed.  However they are rather minor so
> I'm going to last call the comments in parallel.
> 
> draft-ietf-kitten-gssapi-domain-based-names :
> 
> * There is no IANA considerations section yet actions (allocation of
>   an oid) are requested of IANA

Actually, the IANA may have no role to play and my note in the I-D may
have been incorrect.

I cannot find an IANA registry for the 1.3.6.1.5.6 sub-tree.  RFC2743
establishes an IANA registry of _service names_ but not of name types.

So I wouldn't quite know how to write instructions to IANA about this
short of actually writing instructions for establishing the missing
registry.  We have a separate I-D on IANA registries for the GSS-API,
but I don't want this I-D to block on that one.  And since the existing
name type OIDs have been allocated by Standards Track RFCs I believe the
right thing to do is to remove my note about the allocation of this OID.

> * Do we really want to recommend _foo._tcp.example.tld instead of just
>   example.tld?

I don't think I care one way or the other.

> draft-ietf-kitten-krb5-gssapi-domain-based-names
> 
> What does the following text mean:
> 
>    o  the realm of the resulting principal name is that which
>       corresponds to the domain name, treated as a hostname.
>          
> I think you may mean something like: As with host-based service names,
> implementations need to choose the appropriate realm for the Kerberos
> principal corresponding to the domain-based name.  This realm is the
> Kerberos realm that is authoritative for the domain portion of the
> name, not the host portion of the name.  Typically Kerberos
> implementations have a facility that can map a host name to a realm;
> implementations MAY use the realm that results from providing the
> domain portion of the name as an input into this facility.

Yes.

Do you have better text suggestions?  How about:

    o  the realm of the resulting principal name SHALL be that which
       would be used for a hostname whose name is the same as the domain
       name component of the domain-based service name.

Thanks,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 07 Nov 2006 10:43:45 -0800

> right thing to do is to remove my note about the allocation of this OID.

I believe the OID should be allocated by standards action.   The IANA
allocation reference should be removed.

> I don't think I care one way or the other.

There is a typo in the draft in that it uses _tcp._foo.example.tld.
I would replace this with _service._protocol.example.tld.   The DNS SRV
record specification indicates that it should use service and protocol
as specified in the standards document defining the service protocol.
Our documents should not be conflicting with that advice.

>        name component of the domain-based service name.

I think this proposed text is fine.

Jeffrey Altman
(speaking as an individual)

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Nov 2006 14:03:59 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Yes.

    Nicolas> Do you have better text suggestions?  How about:

    Nicolas>     o the realm of the resulting principal name SHALL be
    Nicolas> that which would be used for a hostname whose name is the
    Nicolas> same as the domain name component of the domain-based
    Nicolas> service name.

Works for me.