Protocol for Access Node Control Mechanism in Broadband Networks
RFC 6320

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

(Ralph Droms; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2011-03-14)
No email
send info
5.1.1.  Control Context (Informative)

   Aside from its use in ANCP signalling, access line identification is
   also used in DHCP transactions involving hosts served by DSL.  Either
   the AN or the NAS can serve as a DHCP relay node.  [TR-101] requires
   the AN or NAS in this role to add access line identification in
   Option 82 (Information) to each DHCP request it forwards to the DHCP
   server.  It is desirable for efficiency that the identification used
   in this signalling should be the same as the identification used in
   ANCP messages.

An informative reference to DHCP is needed here.

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection (2011-05-16)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) (was Discuss) No Objection

No Objection (2011-04-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) (was Discuss) No Objection

No Objection (2011-03-16)
No email
send info
I found the "must" convention distracting, and am skeptical of it's effectiveness as a way to communicate requirements to another SDO (which is what I understand its purpose to be based on the author's response to the genart review). If this remains in the document, please follow up and ensure it had the desired effect before trying the convention again.

Section 3.6.1.6 speaks of incrementing transaction IDs linearly when I think it's really trying to say "by one". (If there's ever a chance of an intermediary being introduced in the path of these messages, it would help to say something now about whether recipients should care about gaps in the sequence they receive.)

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2011-03-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The Gen-ART Review by Ben Campbell on 9-Mar-2011 raised a few minor
  points.  Tom Taylor responded; he seems to agree with some of them.  
  However, the document has not been updated yet.  Please do so before
  approval.

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2011-03-17)
No email
send info
#1) I support Alexey's discuss position on TLS.

(Stewart Bryant; former steering group member) No Objection

No Objection (2011-03-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
   RFC EDITOR'S NOTE: please change the value of sub-version in the
   above paragraph to 2 (respectively a version field value of 0x32) in
   the published specification.  For an explanation see the Introduction
   above.

I understand the need to rev this field, but not why it is done via an embedded Editors note

----------