[6lo] Barry Leiba's No Objection on draft-ietf-6lo-minimal-fragment-10: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-6lo-minimal-fragment-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for an interesting and well-written document.  Just a batch of editorial
comments:

— Section 2.2 —

   poor network behavior and, occasionally, trouble at application
   layer.  That experience led to the definition of "Path MTU discovery"
   [RFC8201] (PMTUD) protocol that limits fragmentation over the
   Internet.

This is missing two definite articles (“the”), one after “trouble at” and one
after “definition of”.

   "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
   threats that are linked to using IP fragmentation.  The 6LoWPAN
   fragmentation takes place underneath, but some issues described there
   may still apply to 6LoWPAN fragments.

I think this makes FRAG-ILE a normative reference (necessary security issues). 
It would also be useful to have a “see Section 7” forward pointer here, so it’s
clear that the specific issues are discussed later in this document.

   Readers are expected to be familiar with all the terms and concepts
   that are discussed in "IPv6 over Low-Power Wireless Personal Area
   Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
   Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4
   Networks" [RFC4944].

I think this makes 4919 a normative reference (necessary terminology and
concepts).

   Quoting the "Multiprotocol Label Switching (MPLS) Architecture"
   [RFC3031]: with MPLS, 'packets are "labeled" before they are
   forwarded'.  At subsequent hops, there is no further analysis of the
   packet's network layer header.  Rather, the label is used as an index
   into a table which specifies the next hop, and a new label".

There’s a quote mismatch here: you should not end the quote after
“forwarded”... but there should be a paragraph break after “forwarded.”, which
makes the quoting awkward.  I suggest handling the quote differently and
eliminating the need for awkward cross-paragraph quotation.  So it would look
like this:

NEW
   "Multiprotocol Label Switching (MPLS) Architecture" [RFC3031]
   says that with MPLS, 'packets are "labeled" before they are
   forwarded.'  It goes on to say, “At subsequent hops, there is no
   further analysis of the packet's network layer header.  Rather, the
   label is used as an index into a table which specifies the next hop,
   and a new label".
END

— Section 2.3 —

   This specification uses the following terms:

I would say it “defines” these terms, no?

   6LoWPAN endpoints:  The nodes in charge of generating or expanding a
      6LoWPAN header from/to a full IPv6 packet.  The 6LoWPAN endpoints
      are the points where fragmentation and reassembly take place.

I gather that the usual case is that the 6LoWPAN endpoints are the first and
last nodes in an unbroken string of 6LoWPAN nodes, yes?  If that’s correct, I
think it would add to easy understanding if you said that.  (And if it’s not
correct, we might want to figure out why I got that impression.)

— Section 4 —

   4. Limits of Per-Hop Fragmentation and Reassembly

   There are at least 2 limits to doing per-hop fragmentation and
   reassembly.  See [ARTICLE] for detailed simulation results on both
   limits.

Should this be “limitations”, rather than “limits”?  It seems so.  Also
throughout Section 6.

— Section 5 —

   error and refrain from creating a state or attempting to forward.

Make it “refrains”.

— Section 6 —
(Change “limits” to “limitations” throughout the section.)
Doesn’t this section need LWIG-VRB to be a normative reference?

      because the IP header is required to route the
      fragment and is only present in the first fragment.

This sounds as if the IP header has to do some routing.  If you say “is
required in order to route...”, that ambiguity goes away.

— Section 7 —

      along a path, but each node suffers a lesser hit. this is because

Capitalize “This”.

      An implementation MUST protect itself to
      keep the number of VRBs within capacity, and that old VRBs are

You need another word before “that”: maybe “ensure”?

      This sounds
      difficult and mostly useless in a 6LoWPAN network since the
      fragmentation is not end-to-end.

“Sounds”?  “Is”, I should think; no?

— Section 9 —

   Also many thanks to Georgies Papadopoulos

I believe it’s “Georgios”.

   and Francesca Palombini For their constructive
   reviews through the IESG process.

Lower-case “for”.  And did Sarah, Joerg, and Francesca really review this
through the IESG process, when the IESG process is just now starting?