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
