Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-17

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.

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.)

  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.

#1) I support Alexey's discuss position on TLS.

   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

----------