PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
draft-bberry-rfc4938bis-00

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: 
         draft-bberry-rfc4938bis-00.txt 

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

Ballot Text

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.

RFC Editor Note