Generic Security Service Application Programming Interface (GSS-API) Naming Extensions
draft-ietf-kitten-gssapi-naming-exts-15

I have no objection to the publication of this document, and just
three minor nits you may want to look at.

Section 2

   This document proposes concrete GSS-API
   extensions.

Should feel free to be more positive! s/proposes/defines/

---

Section 3

I suspect the RFC editor will ask you to expand "iff"
              
---

Please consider replacing the reference text used here for 
[OASIS.saml-core-2.0-os] with the text used in RFC 6595 to include the
stable URL.

In section 5:

   Another aspect of context is encoding of the attribute information.
   An attribute containing an ASCII or UTF-8 version of an e-mail
   address could not be interpreted the same as a ASN.1 Distinguished
   Encoding Rules e-mail address in a certificate.

   All of these contextual aspects of a name attribute affect whether
   two attributes can be treated the same by an application and thus
   whether they should be considered the same name attribute.  In the
   GSS-API naming extensions, attributes that have different contexts
   MUST have different names so they can be distinguished by
   applications.  As an unfortunate consequence of this requirement,
   multiple attribute names will exist for the same basic information.
   That is, there is no single attribute name for the e-mail address of
   an initiator.

I don't have the expertise to evaluate this document thorougly, but something in the above seems weird, if not incorrect. It is certainly the case that an email address encoded in ASCII or UTF-8 cannot be byte-for-byte compared to the same email address encoded as an ASN.1 Distinguished Encoding Rules e-mail address. But the words "could not be interpreted the same as" strike me as incorrect. You *can* interpret the two e-mail address as the same if, after doing the decoding, you compare the addresses to eachother. And it would, indeed, be very unfortunate for something that happens to use a different encoding to get a different name for each encoding and therefore have multiple non-comparable occurances of the item. It seems like you would want only one occurance of each item, marked with the encoding, and implementations would be responsible for the decoding.

Maybe this is just a language issue. But something seems wrong about the above.

  Please consider the editorial comments from the Gen-ART Review by
  Pete McCann on 24-Apr-2012.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07387.html

Only nits:

s2: r/(eg an X509/(e.g., an X.509 
s3/s5/s7.5/s7.6: r/iff/if  X3
s5: Consider Kerberos PKINIT (RFC 4556).  Isn't this an informative reference? so: Consider Kerberos PKINIT [RFC4556].
s5: r/certificate authority/certification authority X2
s5: references for ASCII/UTF-8/ASN.1?