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

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?

** 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/

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

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.

[Thank you for addressing my DISCUSS.]

I support the DISCUSS and comment positions from several of my fellow ADs, including Alissa, Álvaro, Deborah, and Murray.

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

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

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