Skip to main content

Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type
draft-ietf-kitten-gssapi-domain-based-names-06

Discuss


Yes

(Sam Hartman)

No Objection

(Bill Fenner)
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jon Peterson)
(Lars Eggert)
(Lisa Dusseault)
(Mark Townsley)
(Ross Callon)

Note: This ballot was opened for revision 06 and is now closed.

Ted Hardie Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2007-01-10) Unknown
draft-ietf-kitten-gssapi-domain-based-names says:

   An application protocol
   might use a simple DNS domainname, such as "example.com" for naming,
   while another it might use the DNS domainname of the SRV RRs it
   queries (e.g., "_tcp._foo.example.com"), and yet another may use
   something that does not resemble a DNS domainname. 

The example is wrong; it should be _foo._tcp.example.com to meet the SRV
syntax.

The same document gives the following as the syntax for domain based names:

 <service> '@' <domain> '@' <hostname>

It dos not cite the documents from which these are imported.  Given that the introduction
notes that the domain name is not necessarily an internet domain name, a clear
citation is critical.  Either this document or the cited document must make clear
whether characters outside the ASCII range will be processed according IDNA,
and that clarity should extend to both domain and hostname portions.  I assume
that both do, but the reader should not have to assume.

The document has RFC 4033 as a normative reference, but the single citation
appears to be informative.
Sam Hartman Former IESG member
(was Discuss, Yes, Discuss, Yes) Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2007-01-10) Unknown
Nothing to be said about internationalized names?
Chris Newman Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2007-01-11) Unknown
2. While you are updating the document for other reasons,
   consider writing

      domain-based-name :=

         <service> '@' <domain> '@' <hostname>

   in ABNF instead.

3. I agree with Ted that the spec needs to be clearer about
   what specific syntax is meant by <service> and by the
   other components. And i18n support or lack thereof
   should be explicitly mentioned.
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2007-01-08) Unknown
  draft-ietf-kitten-krb5-gssapi-domain-based-names-03:

  The security considerations say:
  >
  > See [I-D.ietf-kitten-gssapi-domain-based-names].
  >
  I would prefer an English sentence here.  Perhaps:
  >
  > This specification does not intoduce an security considerations
  > beyond those discussed on [REF].
  >
  This seems like a resonable way to go since
  draft-ietf-kitten-gssapi-domain-based-names is already
  a normative reference.