The Network Access Identifier
RFC 4282

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

(David Kessens; former steering group member) Yes

Yes ( for -)
No email
send info

(Sam Hartman; former steering group member) Yes

Yes ( for -)
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Allison Mankin; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Bill Fenner; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection (2005-02-03 for -)
No email
send info
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.

(Jon Peterson; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Scott Hollenbeck; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Ted Hardie; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Thomas Narten; former steering group member) No Objection

No Objection (2005-02-07 for -)
No email
send info
Curtesy of Henrik Levkowetz <henrik@levkowetz.com>

--------

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