[RTG-DIR] Rtgdir early review of draft-ietf-mpls-1stnibble-02

[Joel Halpern via Datatracker <[e-mail]>]

Reviewer: Joel Halpern
Review result: Not Ready

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.