Subject: [Gen-art] Genart last call review of draft-allan-5g-fmc-encapsulation-04

From: Russ Housley via Datatracker <[email-masked]>
Date: Fri, 03 Jul 2020 09:33:33 -0700

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-allan-5g-fmc-encapsulation-04
Reviewer: Russ Housley
Review Date: 2020-07-03
IETF LC End Date: 2020-07-27
IESG Telechat date: Unknown

Summary: Almost Ready

Major Concerns:

Section 2 says:

   PPPoE data packet encapsulation is indicated in an IEEE 802[8] 
   Ethernet frame by an Ethertype of 0x8864.

This is very odd way to introduce this section.  IEEE Std 802-2001
covers the architecture for Project 802, not just Ethernet frames,
which are fully specified in IEEE 802.3.  However, the MAC frame,
MAC addresses, and Ethertypes are all described in this standard.
Second, you need to point to RFC 2516 to talk about PPPoE.  Third,
the Ethertype is not defined in IEEE Std 802-2001.  I suggest:

   The Ethernet payload [8] for PPPoE [3] is indicated by an
   Ethertype of 0x8864.

References:  I think that [9] needs to be a normative reference
because the reader cannot understand the QFI field without it.

Minor Concerns:

Introduction: You spell out the meaning of 5G, but not BBF.  Please
spell out BBF.  I note that 5G is on the RFC Editor "well known"
list (https://www.rfc-editor.org/materials/abbrev.expansion.txt), but
BBF is not, so it would be fine to not spell out 5G. Likewise, please
spell out p2p, PPPoE, IPoE, DSLAMs, and OLTs the first time the term
is used.

Please explain the UE in the Introduction so that it is understood by
the time it is used later.

Please use the exact wording from RFC 8174 in the boilerplate:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", and "OPTIONAL" in this document are to be interpreted as
   described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

I assume that it is okay to use "[1] [2]" instead of
"[RFC2119] [RFC8174]", but this is not the tradition.

Section 2: Please add a reference for the IANA registry.  I think
you are pointing to here:

  https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-2

Section 5: Please add pointers to the registry that is to be updated.
I think you are pointing here:

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

Nits:

Abstract: I suggest that the Abstract say what is provided instead of
the needs of 5G.  It is also shorter.  I suggest:

   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 snoop certain packet
   fields, carries 5G QoS information associated with the packet data,
   and provides efficient encoding.

Section 4: s/document"s/document's/

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 3 Jul 2020 23:06:54 -0400

Hi Russ,

Thanks for the review. See my responses as one co-author below.

>    The Ethernet payload [8] for PPPoE [3] is indicated by an

I'd be fine with that change. (I hope we don't refer to 802.3, last
time I looked that document was well over 20,000 pages everything of
relevance is in 802.)

> because the reader cannot understand the QFI field without it.

OK with me.

> the time it is used later.

I think most standards documents use too many acronyms and I do not
think the RFC Editor "well known" list authoritatively describes the
state of knowledge of every RFC reader. So I'm fine with spelling out
more things but would prefer not to drop any existing spelling outs.

>   https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-2

Is IANA's URL structure and URL embedded nomenclature guaranteed to be
constant? The draft gives the precise name of the IANA registries web
page referenced: "Point-to-Point (PPP) Protocol Field Assignments". I
see no need to include a URL. I put through a number of drafts and
IANA has never asked me to add a URL to an IANA web page or registry
to one of those drafts.

>   https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1

Same comment here.

>    and provides efficient encoding.

That looks OK to me.

> Section 4: s/document"s/document's/

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 [email-masked]

---

From: David Allan I <[email-masked]>
Date: Sat, 4 Jul 2020 18:01:40 +0000

Hi Russ:

FWIW I'll echo agreement with Donald here and also express thanks. I would share his concern about depending on a constant URL structure.

Cheers
D

-----Original Message-----
From: Donald Eastlake <[email-masked]> 
Sent: Friday, July 3, 2020 8:07 PM
To: Russ Housley <[email-masked]>
Cc: [email-masked] Review Team <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Genart last call review of draft-allan-5g-fmc-encapsulation-04

Hi Russ,

On Fri, Jul 3, 2020 at 12:33 PM Russ Housley via Datatracker <[email-masked]> wrote:
> Review Team (Gen-ART) reviews all IETF documents being processed by 
> the IESG for the IETF Chair.  Please treat these comments just like 
> any other last call comments.
>
> which are fully specified in IEEE 802.3.  However, the MAC frame, MAC 
> addresses, and Ethertypes are all described in this standard.
> Second, you need to point to RFC 2516 to talk about PPPoE.  Third, the 
> Ethertype is not defined in IEEE Std 802-2001.  I suggest:
>

I'd be fine with that change. (I hope we don't refer to 802.3, last time I looked that document was well over 20,000 pages everything of relevance is in 802.)

OK with me.

> list 
> (https://protect2.fireeye.com/v1/url?k=c7043a1d-99a4f858-c7047a86-86b5
> 68293eb5-c84fc54a0ea60a7c&q=1&e=3bf3375d-077c-4030-87f7-c12d7d44797e&u
> =https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2Fabbrev.expansion.txt), but BBF is not, so it would be fine to not spell out 5G. Likewise, please spell out p2p, PPPoE, IPoE, DSLAMs, and OLTs the first time the term is used.
>

I think most standards documents use too many acronyms and I do not think the RFC Editor "well known" list authoritatively describes the state of knowledge of every RFC reader. So I'm fine with spelling out more things but would prefer not to drop any existing spelling outs.

> I assume that it is okay to use "[1] [2]" instead of "[RFC2119] 
> [RFC8174]", but this is not the tradition.
>
> Section 2: Please add a reference for the IANA registry.  I think you 
> are pointing to here:
>
>   

Is IANA's URL structure and URL embedded nomenclature guaranteed to be constant? The draft gives the precise name of the IANA registries web page referenced: "Point-to-Point (PPP) Protocol Field Assignments". I see no need to include a URL. I put through a number of drafts and IANA has never asked me to add a URL to an IANA web page or registry to one of those drafts.

Same comment here.

That looks OK to me.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA  [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Sat, 4 Jul 2020 16:18:35 -0400

Two responses below.

Russ

> On Jul 4, 2020, at 2:01 PM, David Allan I <david.i.allan=[email-masked]> wrote:
> 
> Hi Russ:
> 

You can do it in such a way that the RFC Editor drops the pointer from the final document, but the URL makes it absolutely clear to IANA which registry is being updated.

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

Me too.

> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Jul 2020 23:00:58 +0200

On 2020-07-04, at 05:06, Donald Eastlake <[email-masked]> wrote:
> constant?

I count 1264 references of this kind in 727 RFCs.
(This is not a guarantee, but a kind of insurance :-)

(For my own RFCs, I use the automatically generated references of the kind, e.g., in RFC 8798:

   [IANA.SENML]
              IANA, "Sensor Measurement Lists (SenML)",
              <https://www.iana.org/assignments/senml>.

— but there is no way to dig into registry pages that way, so I do that in prose.)

Grüße, Carsten

---

From: David Allan I <[email-masked]>
Date: Sat, 4 Jul 2020 21:06:49 +0000

Got it!, makes sense...

Dave

-----Original Message-----
From: Russ Housley <[email-masked]> 
Sent: Saturday, July 4, 2020 1:19 PM
To: David Allan I <[email-masked]>; Donald Eastlake <[email-masked]>
Cc: [email-masked]; IETF Gen-ART <[email-masked]>; [email-masked]
Subject: Re: [Last-Call] Genart last call review of draft-allan-5g-fmc-encapsulation-04

Two responses below.

Russ

> Cc: [email-masked] Review Team <[email-masked]>; 
> [email-masked]; [email-masked]
>> https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-nu
>> m
>> bers-2
> 

>> https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xh
>> t
>> ml#ieee-802-numbers-1
> 
> Same comment here.

Me too.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Jul 2020 23:13:04 +0200

> "[RFC2119] [RFC8174]", but this is not the tradition.

Oh.  Numeric references are not good style in RFCs (neither are they current style, e.g., compare RFC 7322 — while section 4.8.6 is silent about that fact, it does say

   References will generally appear in alphanumeric order by citation
   tag.  […]

...and of course RFC 7322 uses the current style itself).

So you do want to say (kramdown syntax):

pi:
  symrefs: 'yes'
  sortrefs: 'yes’

Or, in RFCXMLv3 vernacular:

<rfc ... sortRefs="true" symRefs="true” 

(Symrefs is true by default in RFCXMLv3, but sortrefs is not.  Go figure.)

Grüße, Carsten