Skip to main content

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

Yes

Erik Kline

No Objection

(Benjamin Kaduk)
(Magnus Westerlund)

Note: This ballot was opened for revision 05 and is now closed.

Erik Kline
Yes
Murray Kucherawy
No Objection
Comment (2020-08-10 for -05) Not sent
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?
Roman Danyliw
No Objection
Comment (2020-08-11 for -05) Sent
** 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/
Éric Vyncke
No Objection
Comment (2020-08-11 for -05) Sent
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
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2020-11-25 for -07) Sent
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.
Alvaro Retana Former IESG member
(was Discuss) No Objection
No Objection (2021-02-09) Sent for earlier
[Thank you for addressing my DISCUSS.]
Barry Leiba Former IESG member
No Objection
No Objection (2020-08-12 for -05) Not sent
I support the DISCUSS and comment positions from several of my fellow ADs, including Alissa, Álvaro, Deborah, and Murray.
Benjamin Kaduk Former IESG member
No Objection
No Objection (2021-02-17) Sent for earlier

                            
Deborah Brungard Former IESG member
(was Discuss) No Objection
No Objection (2020-09-07 for -06) Sent
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".
Magnus Westerlund Former IESG member
No Objection
No Objection () Not sent

                            
Martin Duke Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2020-08-11 for -05) Sent
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).
Robert Wilton Former IESG member
No Objection
No Objection (2020-08-12 for -05) Sent
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