Russ, thanks for your review. Authors, thanks for the document updates. I entered a DISCUSS ballot to chat about a couple of other points.
Alissa > On Jul 4, 2020, at 4:18 PM, Russ Housley <hous...@vigilsec.com> wrote: > > Two responses below. > > Russ > > >> On Jul 4, 2020, at 2:01 PM, David Allan I >> <david.i.allan=40ericsson....@dmarc.ietf.org> wrote: >> >> 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 <d3e...@gmail.com> >> Sent: Friday, July 3, 2020 8:07 PM >> To: Russ Housley <hous...@vigilsec.com> >> Cc: gen-art@ietf.org Review Team <gen-art@ietf.org>; last-c...@ietf.org; >> draft-allan-5g-fmc-encapsulation....@ietf.org >> Subject: Re: Genart last call review of draft-allan-5g-fmc-encapsulation-04 >> >> Hi Russ, >> >> Thanks for the review. See my responses as one co-author below. >> >> On Fri, Jul 3, 2020 at 12:33 PM Russ Housley via Datatracker >> <nore...@ietf.org> wrote: >>> >>> 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. >> >> 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.) >> >>> References: I think that [9] needs to be a normative reference >>> because the reader cannot understand the QFI field without it. >> >> OK with me. >> >>> 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://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. >>> >>> Please explain the UE in the Introduction so that it is understood by >>> 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. >> >>> 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-num >>> bers-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. > > 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. > >> >>> 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.xht >>> ml#ieee-802-numbers-1 >> >> Same comment here. > > Me too. > >> >>> 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. >> >> 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 d3e...@gmail.com >> -- >> last-call mailing list >> last-c...@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
