5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
draft-allan-5g-fmc-encapsulation-08

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-allan-5g-fmc-encapsulation-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry is to be created called the PPP Over Ethernet Versions registry. The new registry will be located on the Point-to-Point (PPP) Protocol Field Assignments registry page located at:

https://www.iana.org/assignments/ppp-numbers/

The new registry will be managed via Specification Required as defined in RFC 8126. There are initial registrations in the new registry as follows:

Registry Name: PPP Over Ethernet Versions
Registration Procedure: Specification Required
References: [RFC2516] [ RFC-to-be ]

VER Description Reference
----- -------------------------------- ----------------
0 reserved [ RFC-to-be ]
1 PPPoE [RFC2516]
2 5G WWC User Plane Encapsulation [ RFC-to-be ]
3-15 unassigned [ RFC-to-be ]

Second, in the ETHER TYPES registry, on the IEEE 802 Numbers registry page located at:

https://www.iana.org/assignments/ieee-802-numbers/

the existing registration for 0x8864 will have [ RFC-to-be ] added to the reference. This registry is not assigned by IANA and in accordance with RFC 7042, this change will be coordinated with the registry expert(s).

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-05):

From: The IESG
To: IETF-Announce
CC: bs7652@att.com, draft-allan-5g-fmc-encapsulation@ietf.org, ek.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (5G Wireless Wireline Convergence User Plane Encapsulation (5WE)) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - '5G Wireless Wireline Convergence User Plane
Encapsulation (5WE)'
  as Informational RFC

This requests the start of a 2nd IETF Last Call with the intent of expressly calling
attention to the IPR claim associated with this document
(https://datatracker.ietf.org/ipr/3663/).

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  As part of providing wireline access to the 5G Core (5GC), deployed
  wireline networks carry user data between 5G residential gateways
  and the 5G Access Gateway Function (AGF). The encapsulation method
  specified in this document supports the multiplexing of traffic for
  multiple PDU sessions within a VLAN delineated access circuit,
  permits legacy equipment in the data path to inspect certain packet
  fields, carries 5G QoS information associated with the packet data,
  and provides efficient encoding. It achieves this by specific points
  of similarity with the RFC 2516 PPPoE data packet encapsulation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-allan-5g-fmc-encapsulation/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3663/

This requests the start of a 2nd IETF Last Call with the intent of expressly calling attention to the IPR claim associated with this document (https://datatracker.ietf.org/ipr/3663/).

[Ballot comment]
I cleared my DISCUSS. I would have liked to have seen an explicit call for feedback given the IPR declaration, but given how much time has passed with no concerns raised, it need not hold up the document.

Thanks for updating the IANA registration policy.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Informational, as indicated on the title page. This is the proper
  type because this it extends the protocol in Informational RFC 2516
  and the specification was originated outside the IETF, in the
  Broadband Forum (BBF).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  As part of providing wireline access to the 5G Core, deployed
  wireline networks carry user data between 5G residential gateways
  and the 5G Access Gateway Function. The encapsulation used
  needs to meet a variety of requirements including being able to
  multiplex the traffic of multiple user data sessions within a VLAN
  delineated access circuit, to permit legacy equipment in the data
  path to snoop certain packet fields, to carry 5G QoS information
  associated with the data, and to be efficiently encoded. This memo
  specifies an encapsulation that meets these requirements.

  A liaison statement from the BBF was received noting a
  "strong desire to see it progress through the IETF process":

      https://datatracker.ietf.org/liaison/1694/

  The document currently has an IPR claim registered:

      https://datatracker.ietf.org/ipr/3663/

Working Group Summary

  This document is an Individual Submission that was developed in the
  Broadband Forum.  A liaison statement from the BBF was received
  noting "a strong desire to see it progress through the IETF process":

      https://datatracker.ietf.org/liaison/1694/

Document Quality

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

    There are no known implementations at this point. A number of vendors
    (Juniper, Nokia, Huawei, ZTE, Intel) have indicated interest in the
    specification in the BBF.

Personnel

Document Shepherd: Erik Kline
Responsible Area Director: Erik Kline

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

  Reviewed -03, gave feedback resulting in -04. Sought feedback from
  fellow INT AD, intarea wg chairs, and Barbara Stark (for her BBF
  expertise).  No concerns raised; general support received.

  Feedback included:

      """
      This draft represents a strong-consensus technical solution that has
      undergone many iterations (and looking at various other alternatives)
      in Broadband Forum. All the major router vendors and ISPs wanting to
      do 5G wireline have been involved and are on board...
      """

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No special review needed.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the interested
community has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why.

  Authors confirm all appropriate disclosures have been made.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any discussion and conclusion regarding the IPR
disclosures.

  Yes, see https://datatracker.ietf.org/ipr/3663/

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

  This document has been evolved and extensively discussed in the
  Broadband Forum WWC (Wireless Wireline Convergence) Work Area and
  has consensus there.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No major issues for -04.

  Document date is a month behind, but that is the AD/shepherd's fault
  for not being sufficiently proactive.

  I-D nits tool does flag 2119/8174/2516 as references that need not
  be, given the Informational status.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
8126).

  Everything seems in order.

  This document request the creation of an IANA registry called
  "PPP Over Ethernet Versions", specifies the contents of same from
  this and RFC 2516, and requests that Expert Review be the mechanism
  for future registrations.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  Yes, this document creates an Expert Review IANA Registry for PPP
  over Ethernet version numbers. Any expert(s) appointed for this
  registry should be knowledgeable in PPP and Ethernet. Donald
  Eastlake has volunteered to be an Expert.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, YANG modules, etc.

  None of this document is in a formal language.

(20) If the document contains a YANG module, has the module been
checked with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

  This document does not contain any YANG modules.

[Ballot comment]
Thanks for the BBF Liaison confirming their interest, I’ve cleared my Discuss.

Please consider the following comment.

While Eric V. suggested "'inspect for traffic engineering' rather than 'snoop'", I would strongly prefer
simply "inspect" as this is not traffic engineering. I also agree with Eric, there is no need to change the
current registration to "classic".

[Ballot discuss]
Similar to Alvaro, I am concerned if the intention is for this document to be published in the IETF stream.
I agree with Alvaro's concern on consensus and meeting RFC8789 guidelines. Even more of a concern for
me is that it does not follow the guidelines of RFC4775 (BCP125) if the intention is in support of BBF's work.

RFC4775 recommends when there is a formal liaison in place with another SDO, the liaison channel should be
used. On this work, there has been no formal liaison communicating this document meets their needs? The document
acknowledges "This memo is a result of comprehensive discussions by the Broadband Forum's Wireline Wireless
Convergence Work Area." The Shepherd writeup cites informal verification of support for the document. List discussion
indicates the same. But there has been no formal communication confirming these statements.

While this document's supporters may be correct in their affirmation of BBF's consensus on this document,
RFC4774 was done to ensure IETF and another SDO do communicate directly. RFC4774 has been valuable
in setting the guidelines for other SDOs over these last years. It would be a bad precedent to ignore it here.

Considering IETF has a formal liaison relationship with BBF, I don't think it will introduce too much of a delay
to obtain confirmation on this solution meeting their needs. I would recommend also sending a note to our
IETF-IEEE coordination group.

[Ballot comment]
While Eric V. suggested "'inspect for traffic engineering' rather than 'snoop'", I would strongly prefer
simply "inspect" as this is not traffic engineering. I also agree with Eric, there is no need to change the
current registration to "classic".

[Ballot discuss]
(1) Related to Alvaro's DISCUSS, given that this document is AD-sponsored and it has an IPR declaration that implies a possible royalty/fee, I think we need to see specific support in the community for advancing this draft in light of the IPR declaration (as would normally be done in a WG for a WG document). I realize there have been expressions of support on the last-call list since the IESG started balloting, but they didn't speak to the IPR question.

(2) If I understand the vision for the IANA registry here, I think it needs to have a specification required policy rather than expert review. It seems like a large part of the value would be having documented specs for other versions (just as for this version), and given that the version space is small I assume we're not expecting a flood of registration requests without documentation.

[Ballot comment]
Thanks for this document.

A couple of minor comments:

The document defines acronyms that refers to terminology, but doesn't really state where that terminology is defined.  As a reader I think I would probably have found it helpful to know where I could look up particular terms (e.g. Reflective QoS Indicator).

      IGMP. This may be for the purpose of enhanced QoS, policing of
      identifiers and other applications. Some deployments are
      dependent upon this snooping. Such devices are able to do this
      for PPPoE or IP over ethernet (IPoE) packet encodings but would
      be unable to do so if a new encapsulation, or an existing
      encapsulation using a new Ethertype, were used.
     
Arguably what is being defined here is a new encapsulation.  Hence possibly worth changing from "new encapsulation" to "completely new encapsulation"?

Regards,
Rob

[Ballot comment]
Thanks for this document.

A couple of minor comments:

The document defines acronyms that refers to terminology, but doesn't really state where that terminology is defined.  As a reader I think I would probably have found it helpful to know where I could look up particular terms (e.g. Reflective QoS Indicator).

      IGMP. This may be for the purpose of enhanced QoS, policing of
      identifiers and other applications. Some deployments are
      dependent upon this snooping. Such devices are able to do this
      for PPPoE or IP over ethernet (IPoE) packet encodings but would
      be unable to do so if a new encapsulation, or an existing
      encapsulation using a new Ethertype, were used.
     
Arguably what is being defined here is a new encapsulation.  Hence possibly worth changing from "new encapsulation" to "completely new encapsulation"?

[Ballot comment]
** As already noted by Alvaro, please provide a reference to "5G NAS procedures" in Section 4.

** Section 4.  s/man in the middle attacks/on-path attackers/

[Ballot comment]
Thanks for clarifying the 6 vs. 8 byte question in Martin D's ballot
thread; I had the same question...

Section 1

  -  Identify that the mode of operation for packets encapsulated in
    such a fashion uses non-access stratum (NAS, a logical control
    interface between user equipment (UE) and 5GC as specified by
    3GPP) based 5G WWC session establishment and life cycle
    maintenance procedures as documented in [TS23502][TS23716] instead
    of legacy PPP/PPPoE session establishment procedures (i.e. PADI
    discipline, LCP, NCP etc.).

I suggest including "discovery" in the list of legacy PPP/PPPoE
procedures that are replaced, to leave another clue that the
only-6-byte-header case is not used.

Section 4

We should probably reiterate that the actual PPP frames that are
conveyed do not have any cryptographic protection.

Section 6.2

The BBF document [TR101] available at
https://www.broadband-forum.org/download/TR-101_Issue-2.pdf spells its
title with "Migration", not "Migrating" as is listed here.

If you need to use the [TS23502] and [TS23716] procedures in order to
establish a PPPoE-version-2 session, that seems like it qualifies them
as normative references.

RFC 4937 is not referenced from anywhere in the text.

[Ballot comment]
I support Alvaro's Discuss.

In section 1, it says "Fixed access is very sensitive to the complexity of residential
    gateways, therefore encapsulation overhead and efficiency is an
    important consideration."

Overhead and efficiency aren't really answers for "complexity". I suggest a different word here.

Section 2. Please clarify that the inclusion of the protocol octets is consistent with the first two payload bytes for ethertype 0x8864. It is confusing to say it's a 8B header in RFC 2516 when that source clearly defines a 6B header and a payload which has its own 2B header. (Thanks for answering my original discuss on this point).

[Ballot discuss]
Section 1 states "The 8 byte RFC 2516 data packet header..."

Isn't this a 6-byte header?  Will this cause problems for devices that are not inspecting the version field assuming the payload follows after 6 bytes?

[Ballot comment]
I support Alvaro's Discuss.

In section 1, it says "Fixed access is very sensitive to the complexity of residential
    gateways, therefore encapsulation overhead and efficiency is an
    important consideration."

Overhead and efficiency aren't really answers for "complexity". I suggest a different word here.

[Ballot comment]
In section 1, it says "Fixed access is very sensitive to the complexity of residential
    gateways, therefore encapsulation overhead and efficiency is an
    important consideration."

Overhead and efficiency aren't really answers for "complexity". I suggest a different word here.

[Ballot discuss]
Is this an IETF consensus document?  [This point is for the IESG to discuss.]

rfc8789 (IETF Stream Documents Require IETF Rough Consensus) reads: "The IETF MUST NOT publish RFCs on the IETF Stream without establishing IETF rough consensus for publication."

I know that as an AD-sponsored document, it went through IETF LC, but it received no comments at all except for directorate reviews.  Does that establish rough consensus?  IMO, it just proves that no one objected, but also doesn't support that anyone is in favor.

The Shepherd writeup says that the "document is an Individual Submission that was developed in the Broadband Forum."  And also adds this opinion:

  This draft represents a strong-consensus technical solution that has
  undergone many iterations (and looking at various other alternatives)
  in Broadband Forum. All the major router vendors and ISPs wanting to
  do 5G wireline have been involved and are on board...

It points to consensus -- but in the BBF.


My conclusion is that this is not an IETF consensus document and should not be published in the IETF Stream, according to rfc8789.  The ISE seems like a better publication path.

[Ballot comment]
(1) The title of the document should reflect the contents—suggestion: "BBF's 5WE" (expanded, of course).


(2) The text talks about modifying or repurposing rfc2516, but what is specified is a new version of the protocol.  The text should be clear about that, and about the fact that the procedures from rfc2516 don't apply.


(3) §2: How is the R bit set?  Is there a reference to where the RQI is defined?


(4) §2: Does the SESSION_ID have the same limitation as the field defined in rfc2516: "A value of 0xffff is reserved for future use and MUST NOT be used"?


(5) §2: "PROTOCOL ID...The following values are valid in this field for 5G WWC use..."  What should a receiver do if the ID is not valid?


(6) The Security Considerations section seems to say: don't worry, this is better than before.  I would like to see a reference to "5G NAS procedures".


(7) Even if the encapsulation is expected to be used only with specific applicability, it may be used in other network environments despite the text in the Introduction.  It is important to mention what the risks may be in those other cases.


(8) Nits:

s/Identifier[TS38415]/Identifier [TS38415]

s/P-bits[IEEE802]/P-bits [IEEE802]

[Ballot comment]
Thank you for the work put into this document. While the abstract is quite convoluted, the rest of the document is easy to read.

Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
I strongly suggest to use 'inspect for traffic engineering' rather than 'snoop'. Same applies in section 1.

Should the abstract mention that this specification re-uses the PPPoE framing?

-- Section 2 --
Re-using RFC 2516 fields requires that both termination points are collaborating. Should this be mentioned in the text? Or should the consequence be analyzed when one termination point is PPPoE only, i.e., how to react when receiving a frame with VER = 0x01 ?

Minor, as RFC 2516 uses hexadecimal constants for VER and TYPE, I suggest to also use 0x2 and 0x1 for this document (cosmetic).

-- Section 5 --
I would prefer to use 'PPPoE' rather than 'Classic PPPoE' in the IANA registry.

== NITS ==

I-D nits output:
== Unused Reference: 'RFC4937' is defined on line 296, but no explicit
    reference was found in the text

[Ballot comment]
Section 1 talks about snooping.  Should anything about that be mentioned in Section 4?  Could it be abused in any way?

Section 5 creates an IANA registry with an Expert Review policy, but provides no guidance to the designated expert regarding how that person should review applications.  (See BCP 26, https://tools.ietf.org/html/rfc8126#section-4.5.)  Are none appropriate here?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-allan-5g-fmc-encapsulation-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry is to be created called the PPP Over Ethernet Versions registry. The new registry will be located on the Point-to-Point (PPP) Protocol Field Assignments registry page located at:

https://www.iana.org/assignments/ppp-numbers/

The new registry will be managed via expert review as defined in RFC8126. The reference for the new registry will be [RFC2516] and [ RFC-to-be ].

There are initial registrations in the new registry as follows:

Version Description Reference
--------+-----------------------------------------+------------------
0 Reserved [ RFC-to-be ]
1 Classic PPPoE [RFC2516]
2 5G WWC User Plane Encapsulation [ RFC-to-be ]
3-15 Unassigned

Second, in the ETHER TYPES registry on the IEEE 802 Numbers registry page located at:

https://www.iana.org/assignments/ieee-802-numbers/

The existing registration for Ethertype 0x8864: PPP over Ethernet (PPPoE) Session Stage will have [ RFC-to-be ] added to its reference.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-07-27):

From: The IESG
To: IETF-Announce
CC: ek.ietf@gmail.com, draft-allan-5g-fmc-encapsulation@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (5G Wireless Wireline Convergence User Plane Encapsulation (5WE)) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - '5G Wireless Wireline Convergence User Plane
Encapsulation (5WE)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-07-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  As part of providing wireline access to the 5G Core (5GC), deployed
  wireline networks carry user data between 5G residential gateways
  and the 5G Access Gateway Function (AGF). The encapsulation used
  needs to meet a variety of requirements including being able to
  multiplex the traffic of multiple PDU sessions within a VLAN
  delineated access circuit, to permit legacy equipment in the data
  path to snoop certain packet fields, to carry 5G QoS information
  associated with the data, and to be efficiently encoded. This memo
  specifies an encapsulation that meets these requirements.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-allan-5g-fmc-encapsulation/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3663/

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Informational, as indicated on the title page. This is the proper
  type because this it extends the protocol in Informational RFC 2516
  and the specification was originated outside the IETF, in the
  Broadband Forum (BBF).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  As part of providing wireline access to the 5G Core, deployed
  wireline networks carry user data between 5G residential gateways
  and the 5G Access Gateway Function. The encapsulation used
  needs to meet a variety of requirements including being able to
  multiplex the traffic of multiple user data sessions within a VLAN
  delineated access circuit, to permit legacy equipment in the data
  path to snoop certain packet fields, to carry 5G QoS information
  associated with the data, and to be efficiently encoded. This memo
  specifies an encapsulation that meets these requirements.

Working Group Summary

  This document is an Individual Submission that was developed in the
  Broadband Forum.

Document Quality

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

    There are no known implementations at this point. A number of vendors
    (Juniper, Nokia, Huawei, ZTE, Intel) have indicated interest in the
    specification in the BBF.

Personnel

Document Shepherd: Erik Kline
Responsible Area Director: Erik Kline

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.

  Reviewed -03, gave feedback resulting in -04. Sought feedback from
  fellow INT AD, intarea wg chairs, and Barbara Stark (for her BBF
  expertise).  No concerns raised; general support received.

  Feedback included:

      """
      This draft represents a strong-consensus technical solution that has
      undergone many iterations (and looking at various other alternatives)
      in Broadband Forum. All the major router vendors and ISPs wanting to
      do 5G wireline have been involved and are on board...
      """

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No special review needed.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the interested
community has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why.

  Authors confirm all appropriate disclosures have been made.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any discussion and conclusion regarding the IPR
disclosures.

  Yes, see https://datatracker.ietf.org/ipr/3663/

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

  This document has been evolved and extensively discussed in the
  Broadband Forum WWC (Wireless Wireline Convergence) Work Area and
  has consensus there.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  No major issues for -04.

  Document date is a month behind, but that is the AD/shepherd's fault
  for not being sufficiently proactive.

  I-D nits tool does flag 2119/8174/2516 as references that need not
  be, given the Informational status.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No formal review required.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs?

  No.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
8126).

  Everything seems in order.

  This document request the creation of an IANA registry called
  "PPP Over Ethernet Versions", specifies the contents of same from
  this and RFC 2516, and requests that Expert Review be the mechanism
  for future registrations.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  Yes, this document creates an Expert Review IANA Registry for PPP
  over Ethernet version numbers. Any expert(s) appointed for this
  registry should be knowledgeable in PPP and Ethernet. Donald
  Eastlake has volunteered to be an Expert.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, YANG modules, etc.

  None of this document is in a formal language.

(20) If the document contains a YANG module, has the module been
checked with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings,
what is the justification for not fixing them at this time? Does the
YANG module comply with the Network Management Datastore Architecture
(NMDA) as specified in RFC8342?

  This document does not contain any YANG.