Skip to main content

The Network Access Identifier
RFC 4282

Yes

(David Kessens)
(Sam Hartman)

No Objection

(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(Jon Peterson)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)
(Ted Hardie)

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

(David Kessens; former steering group member) Yes

Yes ()

                            

(Sam Hartman; former steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) No Objection

No Objection ()

                            

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

No Objection ()

                            

(Harald Alvestrand; former steering group member) No Objection

No Objection (2005-02-03)
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 ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

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

No Objection ()

                            

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

No Objection ()

                            

(Thomas Narten; former steering group member) No Objection

No Objection (2005-02-07)
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