The Network Access Identifier
draft-ietf-radext-rfc2486bis-06

[Ballot comment]
Curtesy of Henrik Levkowetz

--------

On the 2486bis draft itself, I have two separate comments (nits):

1)

In Section 2.1 it says:

>    char        =  c
>    char        =/ "\" x

[...]

>    c          =/ %x80-ff ; UTF-8            allowed (not in RFC 2486)
>                ; c must also satisfy rules in Section 2.4
>    x          =  %x00-FF ; all 128 ASCII characters, no exception;
>                          ; as well as all UTF-8 characters (this
>                          ; was not allowed in RFC 2486)

With good will and positive thinking, it is possible to work out that
the indication "UTF-8" means any component octet in an utf-8 encoded
character; however it is not correct in either of the above ABNF rules
that 0x80-ff is a UTF-8 character, nor that an arbitrary UTF-8 character
can be represented as %x80-FF. 

So maybe replace this with:

    c          =/ %x80-FF ; UTF-8-octet      allowed (not in RFC 2486)
                            ; where UTF-8-octet is any octet in the
                            ; multi-octet UTF-8 representation of a
                            ; unicode codepoint above %x7F.
                ; c must also satisfy rules in Section 2.4
    x          =  %x00-FF ; all 128 ASCII characters, no exception;
                            ; as well as all UTF-8-octets as defined
                            ; above (this was not allowed in RFC 2486)

--------

2)

RFC2234 defines

        num-val        =  "%" (bin-val / dec-val / hex-val)
        hex-val        =  "x" 1*HEXDIG
                          [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
        HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"


2486bis uses both the lower-case form (e.g, %xff) and the upper-case form
(e.g., %xFF); the former is not according to RFC2234 (which doesn't really
bother me that much), but mixing the lower-case form and the upper-case form
makes me wonder whether there is some significance in the use of lower-case
vs. upper-case.


Henrik

[Ballot comment]
Reviewed by John Loughney, Gen-ART

His review:

I sent in a review on the RADext WG during WGLC on this draft.  All of my points
were addressed there.  I don't think it necessary to re-review it for IETF LC.

This document, IMO, is ready for publication.

[Ballot discuss]
Extremely minor ABNF error:

label      =  let-dig * (ldh-str)

No spaces are allowed between a repeat and an element, so this should be *(ldh-str) or just *ldh-str .
(*ldh-str is a slightly weird production since ldh-str itself is variable length, so this might be better to just be "let-dig ldh-str".)

[Ballot discuss]
I'm concerned about the way the documents formal syntax attempts to bring in the SASLprep
work; it seems likely that an implementor might believe that only the mapping and normalization
steps of saslprep are required, where I believe the intent is to prohibit characters which are not
legal output characters according to SASLprep.  The document says this:

c          =/ %x80-ff ; UTF-8            allowed (not in RFC 2486)
              ; c must also satisfy rules in Section 2.4
  x          =  %x00-FF ; all 128 ASCII characters, no exception;
                          ; as well as all UTF-8 characters (this
                          ; was not allowed in RFC 2486)


Section 2.4, in turn, says:

  In order to ensure a canonical representation, characters of the
  username portion in an NAI MUST fulfill the requirements specified in
  [I-D.ietf-sasl-saslprep].  In addition, the use of certain special
  characters (see grammar rule c) are prohibited as well in order to
  retain compatibility with the previous version of this RFC.


SASLprep has multiple aspects; mapping, normalization, and prohibited
output.  If the authors mean to disallow the prohibited output set of
characters from SASLprep, I believe the statement in the formal syntax
should reference the prohibited set.  Other mechanisms which make
clear whether the prohibited output set is or is not allowed in a username
side would be fine as well.

[Ballot discuss]
Minor ABNF error in section 2.1: s/label = let-dig * (ldh-str)/label = let-dig *(ldh-str)/
Fix: Remove the blank between "*" and "(ldh-str)".  RFC Editor note?