The IESG has no problem with the publication of 'PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics' <draft-bberry-rfc4938bis-00.txt> as an Informational RFC. The IESG would also like the IRSG or RFC-Editor to review the comments in the datatracker (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17216&rfc_flag=0) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bberry-rfc4938bis-00.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This is an update of RFC 4938. Working Group Summary This is an RFC Editor submission. Document Quality Significant discussion occurred at the publication of the earlier document. There is an implementation. Personnel Jari Arkko is the responsible Area Director, previously this was shepherded by Mark Townsley. RFC Editor Note Response #2 from Section 3 of RFC 3932 applies: The IESG thinks that this work is related to IETF work done in PPPEXT WG, but this does not prevent publishing. We understand that the proposed RFC is an update to RFC 4938; as such, it should be possible to be published. The update does not appear to change the reasons for the original note in RFC 4938, so the IESG note should stay as is. In addition, the following changes are necessary to ensure that the IANA instructions are clear: Change in Section 7: OLD: IANA has assigned the following PPPoE TLV Values as noted in [3]: NEW: IANA has assigned the following PPPoE TLV Values for which this RFC should from now on serve as the reference: Change in Section 7: OLD: IANA has assigned the following PPPoE Code fields as noted in [3]: NEW: IANA has assigned the following PPPoE Code fields for which this RFC should from now on serve as the reference: In addition, reviewers from the IESG suggested the following optional changes in the RFC text. Please consider these suggestions together with the authors as you edit the final RFC. Add to the end of Section 3.1.1: NEW: These fields are transmitted in network byte order. The same byte order is used throughout the document in other structures as well. Section 3.2.1, 1st Discovery PADR packet diagram: s/Metric TLV/TLV/ Section 3.2.1, 2nd Discovery PADR packet diagram: the LENGTH should, I think, be 0x0E Section 3.2.2, 2nd Discovery PADS packet diagram: the LENGTH should be 0x14 Section 3.2.4, 2nd para: s/Credit Tag TLV/Credit TLV/ IESG Note Please use the RFC 4938 note intact even in the new RFC: The PPP Extensions Working Group (PPPEXT) has reservations about the desirability of the feature described in this document. In particular, it solves a general problem at an inappropriate layer and it may have unpredictable interactions with higher and lower level protocols. The techniques described in this document are intended for use with a particular deployment technique that uses a PPP termination separated from a radio termination by an Ethernet, and that has radio-side flow control for a slower PPP-only link to remote nodes. Implementors are better advised to avoid split termination with inter-media protocol translation, and use standard Internet Protocol routing instead. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce