Early Review of draft-ietf-mpls-1stnibble-02
review-ietf-mpls-1stnibble-02-rtgdir-early-halpern-2023-12-27-00
Request | Review of | draft-ietf-mpls-1stnibble-02 |
---|---|---|
Requested revision | 02 (document currently at 12) | |
Type | Early Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2024-01-09 | |
Requested | 2023-12-18 | |
Requested by | Adrian Farrel | |
Authors | Kireeti Kompella , Stewart Bryant , Matthew Bocci , Greg Mirsky , Loa Andersson , Jie Dong | |
I-D last updated | 2023-12-27 | |
Completed reviews |
Rtgdir Early review of -02
by Joel M. Halpern
(diff)
Secdir Last Call review of -11 by Daniel Migault (diff) Opsdir Last Call review of -10 by Qin Wu (diff) Genart Last Call review of -10 by Joel M. Halpern (diff) |
|
Comments |
In preparation for WG last call, we would like a Routing Directorate review to determine whether this document i appropriate and in a good enough state to proceed. Ideally a reviewer will have MPLS knowledge and an understanding of how IANA works. Pseudowire and BIER understanding would help. |
|
Assignment | Reviewer | Joel M. Halpern |
State | Completed | |
Request | Early review on draft-ietf-mpls-1stnibble by Routing Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/2nAIn1oJd2WF2wuVOjhaQHmnSqs | |
Reviewed revision | 02 (document currently at 12) | |
Result | Not ready | |
Completed | 2023-12-27 |
review-ietf-mpls-1stnibble-02-rtgdir-early-halpern-2023-12-27-00
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir This is a requested early Routing Directorate review, and as such is intended to help the Working Group and Document Editors with the subject document. Document: draft-ietf-mpls-1stnibble-02 Reviewer: Joel Halpern Review Date: 27-Dec-2023 IETF LC End Date: N/A Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved. Major: Minor: The parantheticl about IP packets in the "embedded packet" definition is worded to imply that one would only put IP into MPLS for traffic engineering or VPN purposes. This seems misleading to me, and I strongly suggest removing the parenthetical. Bullet 3 in section 2.1.1 on Load Balancing asserts that guessing the content type is always better than not doing so for load balancing purposes. If one guesses wrong, that may well not be true. I would suggest adding to the bullet a forward reference to the text below to caveat "even better". Section 2.1.3 is titled "recommendation" and starts with a "SHOULD", but then has a "MUST NOT" which does not seem to be qualified by the "SHOULD" It is unclear whether this is a flat requirement (belonging in the previous section) or is intended for when the "SHOULD" is being obeyed. Nits: The reference in the introduction to the MPLS Open Design team should be edited to refer to the MPLS Working group, since there is no longer an MPLS Open Design Team. Should "LSE" be expanded on first use? (And included in the list of abbreviations?) The paragraph at the end of the introduction needs to be resolved. I would suggest removing it. As far as I can tell, the WG has evinced little desire to make the change described there. Paragraph 2 of section 2.1.3 on "recommendation" referes to "recommendation 2". But the recommendations (and requirements) are not numbered. So what is the referent? From I-D Nits ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC4928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list.