RADIUS Extensions for Dual-Stack Lite
RFC 6519

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

(Jari Arkko) Yes

(Ralph Droms) Yes

Comment (2011-08-05 for -)
No email
send info
Notes from the dns-directorate review:

o In the introduction, AFTR should be expanded once, before first use

o I'm not too familiar with RADIUS folklore, so this might be obvious
  to others, but section 4 does not clearly state which format is used
  for DS-Lite-Tunnel-Name.  Section 5 later states that "The data type
  of DS-Lite-Tunnel-Name is a string", but earlier it is suggested
  that DS-Lite-Tunnel-Name be fed with the data obtained through DHCP
  in OPTION_AFTR_NAME, which is clearly in DNS wire format.  If this
  option uses text (presentation) format instead, it would need to say
  whether it's all ASCII (A-Label) or not (where it is unlikely
  anybody intended to use U-Labels).  The picture at the top of page
  9 suggests the DS-Lite-Tunnel-Name has a fixed length (of 6 octets,
  for that matter), so a more open ended graph as used in the RADIUS
  RFCs might be advised.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

Comment (2011-08-07 for -)
No email
send info

The PROTO writeup says this draft "passes nits". However, running the ID nits tool on the draft yields an error related to a dowref. Adrian has already a discuss on it because the downref did not seem to be called out during the IETF LC. That discuss needs to be resolved before moving this draft forward.

Also, acronyms need to be expanded on their first use.

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-08-07)
No email
send info
There are a number of acronyms in the Abstract. It would help the reader if you expanded them on first occurrence.

(David Harrington) (was Discuss) No Objection

Comment (2011-10-11)
No email
send info
4) in 4.1, "The Change-of-Authorization (CoA) message [RFC5176] can be used to modify the current established DS-Lite tunnel." Should this be MUST be used, to ensure interoperability? or maybe RECOMMENDED, with mention of possible alternative approaches?

(Russ Housley) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection