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

[Ballot discuss]
Carrying forward Ted's DISCUSS:

---
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:

'@'  '@'

It does 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.
---

Revision -04 appears to address the first issue.  It also improves the
second issue (by making the discussion of domain earlier in the
document precise), but does not make the actual syntax in section 4
clear. What are the valid characters for ?  Is there a
registry for ?  Is the syntax for  and
the same?  Is it ACE-encoded or UTF-8 encoded (or are both permitted
based on the API used)?

[Ballot discuss]
I'm holding a discuss because issues surrounding internationalization
raised by Ted Hardie have not been dealt with.  His issues can be
found in the comment log in the tracker in his discuss comment.  His
discuss is no longer on the ballot page because he is no longer on the
IESG.

[Ballot discuss]
Carrying forward Ted's DISCUSS:

---
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:

'@'  '@'

It does 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.
---

[Ballot comment]
2. While you are updating the document for other reasons,
  consider writing

      domain-based-name :=

          '@'  '@'

  in ABNF instead.

3. I agree with Ted that the spec needs to be clearer about
  what specific syntax is meant by  and by the
  other components. And i18n support or lack thereof
  should be explicitly mentioned.

[Ballot discuss]
1. The examples in both documents use the example.tld domain
  name which is NOT listed as a legal, reserved name
  in RFC 2606. (Even if it happens to be used in RFC 3375.)

[Ballot discuss]
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:

  '@'  '@'

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.

[Ballot comment]
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.

[Ballot discuss]
Just after issuing the ballot and while  making one last check that there were no iana actions before adding an iana note, I found the following text in the base domain based names draft:

      [NOTE: OID assignment to be made with IANA.]

      {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
      domain-based(5)}

The working group needs to coordinate with IANA and figure out what
the assignment policy is for the nametypes arc.  I'm not entirely sure
that this will end up holding up this document; I suspect that there
is no registry, the existing entries under that arc have been assigned
by standards action and the GSS-API IANA registry document would be a
better place to fix the mess than this document.  Still we need to
decide what we're doing and the bracketed note definitely needs to go.

1.a) Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

I have reviewed this document and believe it is ready for publication.

1.b) Has the document had adequate review from both key WG members
    and key non-WG members?  Do you have any concerns about the
    depth or breadth of the reviews that have been performed?

This document has been reviewed by key members of the Kitten Working
Group including Nico Williams, Jeffrey Hutzelman, Alexey Melnikov,
Martin Rex, Jeffrey Altman, and Sam Hartman.  The reviewers also have
extensive experience with both Kerberos and SASL.  I have no concerns
regarding the depth or breadth of the reviews that were performed.

1.c) Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

I do not believe this draft requires additional review.


1.d) Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of?  For
    example, perhaps you are uncomfortable with certain parts of the
    document, or have concerns whether there really is a need for
    it.  In any event, if your issues have been discussed in the WG
    and the WG has indicated it that it still wishes to advance the
    document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

The only active members of the working group that did not comment
are Larry Zhu, Ken Raeburn and Tom Yu.

The consensus on domain-based names is solid.  A large number of
tangents were taken during the discussion by Martin Rex related
to problem spaces that are not addressed by domain-based names.
I do not believe that Martin Rex is going to attempt to block this
document.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email to the Responsible Area Director.

There is no threat of appeal.

1.g) Have the chairs verified that the document adheres to all of the
    ID nits? (see http://www.ietf.org/ID-Checklist.html).

idnits 1.114 has no complaints.

1.h) Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

Yes.

1.i) For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following
    sections:


Technical Summary:

This document domain-based service principal names and
the corresponding name type for the Generic Security Service
Application Programming Interface (GSS-API).

Domain-based service names are similar to host-based service names,
but using a domain name (not necessarily an Internet domain name) in
addition to a hostname.  The primary purpose of domain-based names is
to provide a measure of protection to applications that utilize
insecure service discovery protocols.  This is achieved by providing
a way to name clustered services after the "domain" which they
service, thereby allowing their clients to authorize the service's
servers based on authentication of their service names.


Working Group Summary:

The Kitten Working Group has achieved consensus that
this document should be published as a Proposed Standard.  Two weeks
of discussion of the document and how applications would need to
be modified to make use if its specification were extended by an
additional week in order to reach consensus on additional examples.

Protocol Quality:

This draft specifies a a new GSS-API name type,
GSS_C_NT_DOMAINBASED_SERVICE as well as
application protocol examples (NFSv4 domain-wide root server discovery
and LDAP server discovery.)

The Security Considerations section describes additional verifications
that applications must perform if fallback to host-based names is
attempted.


There are no IANA Considerations for this draft as the GSS-API name
type repository has not yet been given to IANA for management by the
Kitten working group.