IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery
draft-ietf-6lo-fragment-recovery-21

[Ballot comment]
Thank you for addressing my comments!
Just a few minor notes from reading the diff from -13 to -16:

Section 1

  each hop, more in Section 6.  This specification encodes the
  Datagram_Tag in one byte, which will saturate if more than 256
  datagram transit in the fragmented form over a same hop at the same
  time.  This is not realistic at the time of this writing.  Should

Some grammar nit(s) here, maybe: "datagrams transit in fragmented form
over a single hop at the same time"

Section 4.3

  is out of scope.  In most cases, the expectation is that most
  datagrams will represent only a few fragments, and that only the last

Maybe s/represent/require/?

  fragment will be acknowledged.  A basic implementation of the
  fragmenting endpoint is NOT REQUIRED to variate the size of the

nit: s/variate/vary/

  the ECN signal or simply reset the window to 1 (see Appendix C for
  more) till the end of this datagram upon detecting a congestion.

nit: s/till/until/

Section 5

  This document specifies an alternate to the 6LoWPAN fragmentation

nit: s/alternate/alternative/

Section 5.1

It just occurred to me now that with the change in response to my
initial review of "never reuse a sequence number for a fragment with
different size", there may be special considerations for the initial
fragment (Sequence 0) that gets some special handling.  I suspect there
are not any real problems here, and in any case the datagram itself
could be re-sent, but mention it just in case there are some new
problems (e.g., we get stuck in a case where we have to send something
that gets treated as a reset even if we don't want it to).

Appendix C

  represented in Figure 4 in Section 5.2.  While the support of echoing
  the ECN at the reassembling endpoint in mandatory, this specification
  does not provide the flow control mechanism that react to the
  congestion at the fragmenting endpoint.  A minimalistic behaviour
  could be to reset the window to 1 so the fragments are sent and
  acknowledged one by one till the end of the datagram.

I think we may be suffering from a bit of skew here, since Section 1
specifies the "UseECN=yes" behavior (for this document) as "reset the
window to 1".

[Ballot comment]
Thank you for addressing my DISCUSS issue, clearing...

----


Thank you for a useful and interesting read -- I really enjoyed this document.

I do also support Benjamins "I think we should be more clear about whether a "FULL bitmap" always has 32 bits set to one, or if "merely" having as many bits as the sender sent fragments set to one also counts as "FULL". " comment, and had something very similar drafted...

[ Original DISCUSS Position for archeology purposes ]
[ Be ye not afraid - this should be easy to address.]
"datagram_size: The size of the datagram in its Compressed Form before it is fragmented. The datagram_size is expressed in a unit that depends on the MAC layer technology, by default a byte."
and:
"Fragment_Size:  10-bit unsigned integer; the size of this fragment in a unit that depends on the MAC layer technology.  Unless overridden by a more specific specification, that unit is the octet, which allows fragments up to 1024 bytes."

I spent quite a while going though the document, looking at the 13 places where you use 'byte' and 3 where you use 'octet', trying to figure out if there is a reason that different terms are used. Normally I'd just say "meh, these are synonyms" and ignore it, but in this particular specification (because of the "by default" / "Unless overridden") I think it is actually important....
Can you standardize on one of the other, or provide more explanatory text if there is a reason?

[Ballot discuss]
[ Be ye not afraid - this should be easy to address.]
"datagram_size: The size of the datagram in its Compressed Form before it is fragmented. The datagram_size is expressed in a unit that depends on the MAC layer technology, by default a byte."
and:
"Fragment_Size:  10-bit unsigned integer; the size of this fragment in a unit that depends on the MAC layer technology.  Unless overridden by a more specific specification, that unit is the octet, which allows fragments up to 1024 bytes."

I spent quite a while going though the document, looking at the 13 places where you use 'byte' and 3 where you use 'octet', trying to figure out if there is a reason that different terms are used. Normally I'd just say "meh, these are synonyms" and ignore it, but in this particular specification (because of the "by default" / "Unless overridden") I think it is actually important....
Can you standardize on one of the other, or provide more explanatory text if there is a reason?

[Ballot comment]
Thank you for a useful and interesting read -- I really enjoyed this document.

I do also support Benjamins "I think we should be more clear about whether a "FULL bitmap" always has 32 bits set to one, or if "merely" having as many bits as the sender sent fragments set to one also counts as "FULL". " comment, and had something very similar drafted...

[Ballot comment]
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.

[Ballot discuss]
Thanks for this well written document, however, I have a couple points below that need further clarification, all mostly related to congestion control. From an editorial point of view most of this is discussed either in the intro text of section 6, then some part in 7.1, and some in the appendix C. I would really recommend you to instead have a separate section that much clearer states what should be done by default (probably no dynamically window but a small fixed window with maybe size of 1) and what could be don as further optimisation, and also to discuss the parameter/variables there before the algorithms are discussed.

And a bit of a provoking question: wouldn't it be easier to just use a reliable transport protocol on top?
If this mechanism is intended to be used over a short path with a few hops only (in a local network), I think this should be stated more clearly at the beginning of the document.
In the appendix you state this:
" In addition, deploying such a mechanism requires
  that the end-to-end transport is aware of the delivery properties of
  the underlying LLN,..."
But I'm not sure what you mean...? Can you further explain?



1) Sec 6:
"Upon exhaustion of the retries the
  sender may either abort the transmission of the datagram or retry the
  datagram from the first fragment with an 'X' flag set in order to
  reestablish a path and discover which fragments were received over
  the old path in the acknowledgment bitmap. "
I'm not sure about this "or". Why should the first fragment be more successful than any other which requests an ACK? Also if you really want to keep this condition, you need to specify it better. How often do you retry? I guess you need to set the PTO again...?
Further the RTO should also implement an exponential back-off.

2) sec 6.3:
"Upon an acknowledgment with a NULL bitmap, the sender endpoint
  MUST abort the transmission of the fragmented datagram with one
  exception: In the particular case of the first fragment, it MAY
  decide to retry via an alternate next hop instead."
What's mean with "In the particular case of the first fragment"? And does this mean it should retry only with the first fragment or the whole transmission. However, if this signal is from the receiving endpoint why should that endpoint change it mind only if a different path is used? If the assumption is that this NULL bitmap is sent by an intermediate node? However, then it would make sense to  rather signal this information explicitly (e.g. using a flag).

3) Sec 7.1 (and to some extend sec 6)
"  OptWindowSize:  The OptWindowSize is the value for the Window_Size
      that the sender should use to start with.  It is greater than or
      equal to MinWindowSize.  It is less than or equal to
      MaxWindowSize.  The Window_Size should be maintained below the
      number of hops in the path of the fragment to avoid stacking
      fragments at the bottleneck on the path.  If an inter-frame gap is
      used to avoid interference between fragments then the Window_Size
      should be at most on the order of the estimation of the trip time
      divided by the inter-frame gap."
This needs normative language and more explanation. I recommend to even say that if no congestion control (as discussed in the appendix) is applied, the Window MUST be set to 1.
Further, the assumption that the window can or should be set to (at maximum) the number of hop does seem correctly to me. No matter how many hops there are packets are only queued at the bottleneck (the link where the current rate is smaller than the sending rate) and it depends on the sending rate of the bottleneck link how many packets need to be queued. This is completely independent of the number of hops. Further, even if that would be true, as long as this document does not discuss also away to estimate or know the number of hops, this advise would unfortunately be useless...
Further I don't think pointing to rfc6298 for RTT calculation is sufficient (as done in the appendix). rfc6298 assume frequent ACKs and a reasonably large window, which is both not the case here.
All in all, any window adjustments itself are not described at all. What should be done when a congestion marking is received? How does the window need to be adjusted based on an RTO? When should the window be increased again? And how much?

4) Sec 7.1.: Inline with the TSV-ART review (Thanks Collin!), the parameters need more guidance.
Especially for he number of retries it should be possible to recommend a default value (e.g. 3) and it would be good to also give an upper limits (MUST NOT be larger than X).
Similar for the window size: there should be also at least a default value (see comment above).
And further the RTO needs further explanation about how to find a reasonable value. If the RTO is configured (and not estimated dynamically) e.g. it could be set to 3x the maximum expected RTT in the respective network. And it would be even better to provide a minimum default (initial) value. Not that TCP is also designed to work on a large variety of timescales and a minimum initial value of 1s is seen as safe for all Internet scenarios. It's really important to also provide some recommendations like this here.

5) Sec 7.2:
"The management system should monitor the number of retries and of ECN
  settings that can be observed from the perspective of both the sender
  and the receiver, and may tune the optimum size of Fragment_Size and
  of Window_Size, OptFragmentSize, and OptWindowSize, respectively, at
  the sender."
This does not see seem correct, as OptFragmentSize and OptWindowSize are the initial values which are configured and therefore should not be changed dynamically. Only Fragment_Size and Window_Size are changes. Further the network should also normatively state somewhere that Fragment_Size and Window_Size MUST not grow above the configured max value. That seems obvious but it's better to be explicit and use normative language respectively.

6) Further sec 7.2 says:
"The inter-frame gap is another tool that can be
  used to increase the spacing between fragments of the same datagram
  and reduce the ratio of time when a particular intermediate node
  holds a fragment of that datagram."
However, inter-frame gap is a configuration parameter and this is the first time that adapting it dynamically is mentioned here. If you want to adapt it dynamically you need to add more information.

[Ballot comment]
1) side comment regarding section 2.2: Note that there is also a working group draft defining PMTUD for datagram transports: draft-ietf-tsvwg-datagram-plpmtud

2) Sec 6:
"Note that acknowledgments might consume precious resources so the use
of unsolicited acknowledgments should be configurable and not enabled
  by default."
Maybe SHOULD?

3) Sec 6: Maybe use normative language here?
OLD
"Fragments are sent in a round-robin fashion: the sender sends all the
  fragments for a first time before it retries any lost fragment; lost
  fragments are retried in sequence, oldest first.  This mechanism
  enables the receiver to acknowledge fragments that were delayed in
  the network before they are retried."
NEW
"Fragments MUST be sent in a round-robin fashion: the sender MUST send all the
  fragments for a first time before it retries any lost fragment; lost
  fragments MUST be retried in sequence, oldest first.  This mechanism
  enables the receiver to acknowledge fragments that were delayed in
  the network before they are retried."

4) Sec 6:
"When a single frequency is used by contiguous hops, the sender should
  insert a delay between the frames (e.g., carrying fragments) that are
  sent to the same next hop.
Maybe SHOULD?

5) sec 6.3:
"Until the timer
  elapses, fragments of that datagram may still be received, e.g. if
  the RFRAG-ACK was lost on the way back and the source retried the
  last fragment.  In that case, the router forwards the fragment
  according to the state in the VRB."
Why should a router forward the segment, rather than re-sending/re-generating the full ACK knowing that all segments have been successfully received?

6) sec 8:
As currently described an off-path attacker could abort the transmission if the datagram_tag is known. I think it should be mention somewhere that a null bitmap should only be accepted and forwarded if received on the right interface. Further it might make sense to not erase state immediately but wait to see if any further fragments are received from the sender. In any case this attack should at least be mentioned in section 8.

7) Appendix B:
"The recovery mechanism must support highly
      fragmented packets, with a maximum of 32 fragments per packet."
Where does the 32 come from and shouldn't this be stated normatively in body of the document?

Nit: you use both "time out" and "time-out". I recommend to change the two occasions of "time out" to "time-out".

[Ballot comment]
Pascal, thank you for the work put into this document.  The idea is simple and smart, I like the fact that all fragments follow the same path, so they should be delivered in the right order.

Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

A generic question is whether RFC 7112 "Implications of Oversized IPv6 Header Chains" is applicable ?

-- Section 4.2 and Section 7.1 --
Should default values for the inter-frame gap be given ?

-- Section 5.1 --
With 8 bits in the Datagram_Tag, this means that a node can only transmit/forward 256 packets over a link. While this seems suffisant, did the author make some investigation on this limit? The text should also state what to do when the 8 bits are not enough.

-- Section 5.2 --
I suggest to mention that the use of the Datagram_Tag field will be described in section 6.


-- Section 6 --
I find it weird to read in the same paragraph "The RFRAG Acknowledgment can optionally carry an ECN" and later "MUST echo that information by setting the 'E'". I am not a native English speaker but may I suggest to replace the first part with "The RFRAG Acknowledgment has a ECN"

-- Section 6.1.2 --
"An implementation may receive overlapping fragments as the result of retries after an MTU change." Is this a security risk (RFC 8200 forbids overlapping fragments but this is a different layers) ? I also suggest to make it a normative "MAY" or "MUST accept".

-- Section 7.2 --
Should the network observation installs global states or per destination states ? E.g., typical IP implementations maintain a per destination Path MTU cache.

== NITS ==

-- Section 7 --
Is it "Kbps" or "kbps" ?

The expert approved the registrations, but wrote, "One slight concern is that it registers not 1 or 2 codes, but 4. However, rfc8025 was created precisely because of this problem, as these registrations are limited to page 0 only."

[Ballot discuss]
In Section 2.3 we refer to the datagram_tag plus layer-2 sender
address as being "a globally unique identifier for the datagram", but I
think this can only hold within some time-bounded window (e.g., the
lifetime of the packet), since the tag space is finite and reuse
somewhat inevitable.  [The simplest way to resolve this is probably to
just remove the definition from this document and refer to
draft-ietf-6lo-minimal-fragment for definitions.]

I think we should be more clear about whether a "FULL bitmap" always has
32 bits set to one, or if "merely" having as many bits as the sender
sent fragments set to one also counts as "FULL".  The current text seems
to invite different interpretations by implementations.  (If FULL does
mean all 32 bits, then the semantics of the other case seem unclear to
me.)

What's the transition/backwards-compatibility story?  That is, how does
a sender know that all nodes on the path support the RFRAG dispatch
types, and what happens if they are sent anyway and get to a node that
doesn't implement them?

I have grave misgivings about allowing a packet (as identified by sender
and tag) to be refragmented by the sender so that a single fragment
sequence number is used for fragments of different lengths.  We do not
seem to provide a mechanism to distinguish which variant of that
fragment is being ack'd, which could lead to disagreement between sender
and receiver as to whether a full packet is reconstructed.
Brainstorming, it might be possible to allow such refragmenting at the
sender by using a Fragment_Size of zero to indicate "this fragment is
superseded" and allocating new sequence number for all its components.
(I didn't attempt to do an exhaustive check on whether that proposal is
flawed and Fragment_Size of zero already has some existing semantics
that would be in conflict.)

[Ballot comment]
It might be worth mentioning that whereas the RFC 4944 fragmentation
procedures uses different dispatch types for the first fragment and
subsequent fragments, we have no need to do so (the first fragment is
identified by sequence number zero).

I have a question about the "stickiness" of per-fragment ECN markings.
That is, suppose that fragment 1 is marked as having experienced
congestion when it arrives at the recipient.  The sender requests an ACK
after fragment 4, and the recipient duly sets the E bit in the ack.
Suppose that fragments 5 through 9 then arrive with no congestion
indicated, and fragment 9 requests and ACK.  Does this new ACK still
have to set the E bit since, as discussed in Section 5.2, "at least one
of the acknowledged fragments was received with an Explicit Congestion
Notification"?  My (very very non-expert) recollection is that we tend
to say that any given ECN marking should produce at most one "congestion
present" response on the return path.

Section 1

  LLNs.  One critical issue with this original design is that routing
  an IPv6 [RFC8200] packet across a route-over mesh requires
  reassembling the full packet at each hop, which may cause latency
  along a path and an overall buffer bloat in the network.  The "6TiSCH

I think I encountered at least one good reference for this statement
during my reading this week (posibly just -minimal-fragment, but maybe
something referenced from there?); it might be nice to help with
cross-linking.

  That problem is exacerbated when forwarding fragments over multiple
  hops since a loss at an intermediate hop will not be discovered by
  either the source or the destination, and the source will keep on
  sending fragments, wasting even more resources in the network and
  possibly contributing to the condition that caused the loss to no
  avail since the datagram cannot arrive in its entirety.  [...]

nit: I'm not sure that "to no avail" is placed properly.

Section 2.2

  "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
  introduces the generic concept of a Virtual Reassembly Buffer (VRB)

It's perhaps debatable whether -minimal-fragment vs. lwig-vrb really
"introduces" the concept -- draft-ietf-6lo-minimal-fragment-12 doesn't
really say very much about it, to me.

  and specifies behaviours and caveats that are common to a large
  family of FF techniques including this, which fully inherits from
  that specification.

nit: I'd suggest rewording "including this" for clarity, perhaps
"including the mechanism specified by this document".

Section 2.3

  6LoWPAN endpoints:  The LLN 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.

[-minimal-fragment also defines this, and many of the other terms we
define here, with minimal-but-nonzero variation.  Given that we already
have a normative dependency on that document, perhaps we should pull
definitions from it as well, instead of repeating them?  If not, I note
that on -minimal-fragment, I commented:
nit: I think they are only "the [only] points" where
fragmentation/reassembly happen if the entire newtork is using fragment
forwarding; in other cases some intermediate nodes will also reassemble
and (re)fragment.]

Section 4.1

  This specification cannot allow this operation since fragments are
  recovered end-to-end based on a sequence number.  This means that the

I suggest s/this operation/such a refragmentation operation/.

  fragments that contain a 6LoWPAN-compressed header MUST have enough
  slack to enable a less efficient compression in the next hops that
  still fits in one MAC frame.  For instance, if the IID of the source

(This assumes a homogeneous MAC mesh, an assumption that might be worth
making explicit.

  IPv6 address is elided by the originator, then it MUST compute the
  Fragment_Size as if the MTU was 8 bytes less.  This way, the next hop
  can restore the source IID to the first fragment without impacting
  the second fragment.

Is it worth noting that this to large extent obviates the benefits of
header compression?

Section 4.2

  This specification introduces a concept of an inter-frame gap, which
  is a configurable interval of time between transmissions to the same

I think draft-ietf-6lo-minimal-fragment also talks about an "inter-frame
gap", though in less detail.

Section 4.3

  The compression of the Hop Limit, of the source and destination
  addresses in the IPv6 Header, and of the Routing Header may change en
  route in a Route-Over mesh LLN.  If the size of the first fragment is
  modified, then the intermediate node MUST adapt the Datagram_Size to
  reflect that difference.

Hmm, if this really only affects the first fragment, then maybe Section
4.1 could be more clear that the need for extra "slack" in practice only
applies to the first fragment, as well.

  The intermediate node MUST also save the difference of Datagram_Size
  of the first fragment in the VRB and add it to the Datagram_Size and
  to the Fragment_Offset of all the subsequent fragments for that
  datagram.

The RFRAG header does not carry the Datagram_Size, so I think this needs
rewording (we do, however, need to store the updated size to detect the
final fragment).

Section 5

  This specification provides a technique that is derived from MPLS to
  forward individual fragments across a 6LoWPAN route-over mesh without
  reassembly at each hop.  The Datagram_Tag is used as a label; it is
  locally unique to the node that owns the source MAC address of the
  fragment, so together the MAC address and the label can identify the
  fragment globally.  A node may build the Datagram_Tag in its own

(More "globally unique" with implied "lifetime of the packet".)

  locally-significant way, as long as the chosen Datagram_Tag stays
  unique to the particular datagram for the lifetime of that datagram.

[okay, less implied and more explicit here than it was above :) ]

Section 5.1

We discuss the header format, but I don't think we actually say that
"you put the fragment payload after the header" :)

                            1                  2                  3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |1 1 1 0 1 0 0|E|  Datagram_Tag |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |X| Sequence|  Fragment_Size  |      Fragment_Offset        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I strongly suggest a stronger indicator that the field marked
"Fragment_Offset" is also used to carry the Datagram_Size (for sequence
number zero).

  The format of the fragment header is shown in Figure 1.  It is the
  same for all fragments.  The format has a length and an offset, as

(Similarly, this could mention the slight exception to "all fragments".)

  order in which the fragments are received.  This enables out-of-
  sequence subfragmenting, e.g., a fragment seq. 5 that is retried end-
  to-end as smaller fragments seq. 5, 13 and 14 due to a change of MTU
  along the path between the 6LoWPAN endpoints.

Per the Discuss, reusing a sequence number to mean a different fragment
(here, a smaller one) seems pretty risky.  I recall that one of the big
advantages of QUIC over TCP is that we don't reuse sequence numbers for
retransmissions in QUIC, to get better clarity about what exactly is
lost vs. ack'd; reusing a sequence number to mean something with a
different *size* seems qualitatively worse (riskier) to me.

  There is no requirement on the receiver to check for contiguity of
  the received fragments.  The sender knows that the datagram is fully
  received when the acknowledged fragments cover the whole datagram.

But what if there's ambiguity about which version of a fragment
(identified by sequence number) is ack'd?
Also, I'm confused by "no requirement" to check for contiguity;
presumably the receiver also is going to check that it has all the data
in the datagram somehow...

  The first fragment is recognized by a Sequence of 0; it carries its
  Fragment_Size and the Datagram_Size of the compressed packet before
  it is fragmented, whereas the other fragments carry their
  Fragment_Size and Fragment_Offset.  The last fragment for a datagram
  is recognized when its Fragment_Offset and its Fragment_Size add up
  to the Datagram_Size.

I suggest "add up to the stored Datagram_Size of the packet identified
by the sender and Datagram_Tag".

  E:  1 bit; Explicit Congestion Notification; the "E" flag is reset by
      the source of the fragment and set by intermediate routers to
      signal that this fragment experienced congestion along its path.

nit: I suggest s/reset/cleared/.

  Datagram_Tag:  8 bits; an identifier of the datagram that is locally
      unique to the sender.

RFC 4944 had a 16-bit tag field; I would expect some discussion of why
the shorter tag is acceptable now.  I guess that's in the security
considerations, which is okay (albeit not where I would have first
looked).

  Sequence:  5-bit unsigned integer; the sequence number of the
      fragment in the acknowledgement bitmap.  Fragments are numbered
      [0..N] where N is in [0..31].  A Sequence of 0 indicates the first

This implies that a one-fragment packet is allowed (N of 0).  Wouldn't
you just not use the fragmentation framing for the case where the packet
fits in a single frame?

      *  if a VRB already exists and is not broken, the fragment is to
        be forwarded along the associated Label Switched Path (LSP) as
        described in Section 6.1.2, but regardless of the value of the
        Sequence field;

I'm not sure I'm parsing "but regardless of the value of the Sequence
field" properly; if the intent is to say that it is forwarded without
checking the value of the Sequence field, I would remove the "but".
Also, we seem to be intending "is not broken" to match up with "the next
hop is still reachable" in the preceding paragraph; I'd suggest
harmonizing the wording between the two instances.

      *  else, if the Sequence is 0, then the fragment is to be routed
        as described in Section 6.1.1, but no state is conserved
        afterwards.  In that case, the session if it exists is aborted
        and the packet is also forwarded in an attempt to clean up the
        next hops along the path indicated by the IPv6 header (possibly
        including a routing header).

Do we want an "*  else (the Sequence is nonzero and either no VRB exists
or the next hop is unavailable), the fragment is discarded and an abort
RFRAG-ACK is sent back [...]" to replace the last paragraph of the
section?

Section 5.2

  This specification also defines a 4-octet RFRAG Acknowledgment bitmap
  that is used by the reassembling endpoint to confirm selectively the
  reception of individual fragments.  A given offset in the bitmap maps
  one-to-one with a given sequence number and indicates which fragment
  is acknowledged as follows:

[Except it *doesn't* indicate that, since the sequence number is not a
unique fragment identifier if the fragment size can change!]

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |1 1 1 0 1 0 1|E|  Datagram_Tag |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          RFRAG Acknowledgment Bitmap (32 bits)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think we need to explicitly say here that the Datagram_Tag, in a
reversal of the previous usage, is scoped to the link-layer *recipient*
of the RFRAG_ACK frame.

Section 6

  that was the originator of the fragments.  To achieve this, each hop
  that performed an MPLS-like operation on fragments reverses that
  operation for the RFRAG_ACK by sending a frame from the next hop to
  the previous hop as known by its MAC address in the VRB.  The

I'm not 100% sure that the previous work in this space (e.g.,
draft-ietf-6lo-minimal-fragment) framed things such that there was a
requirement to be able to perform this "reverse lookup".  It might be
worth calling this out as an additional requirement over the prevoius
fragment-forwarding methodologies...
(We do seem to do so in Section 6.1.1, though I am not sure if it merits
an earlier mention in the document.)

  limiting the number of outstanding fragments, which are the fragments
  that have been sent but for which reception or loss was not
  positively confirmed by the reassembling endpoint.  The maximum

(Do we have a way for *loss* to be "positively confirmed"?  Appendix C
notes that we infer loss from timeout without acknowledgment.)

  The Ack-Request ('X') set in an RFRAG marks the end of a window.
  This flag MUST be set on the last fragment if the sender wishes to
  protect the datagram, and it MAY be set in any intermediate fragment
  for the purpose of flow control.

Is this usage of "protect" conventional or should it get clarified
somewhere?

  This automatic repeat request (ARQ) process MUST be protected by a
  Retransmission Time Out (RTO) timer, and the fragment that carries

nit: I'm not sure that "this" is appropriate yet, since we haven't
really talked about "repeat"ing or retransmission yet.  (Perhaps also
give a bit more discussion about what this ARQ process specifically
entails, too.)

  of times (see Section 7.1).  Upon exhaustion of the retries the
  sender may either abort the transmission of the datagram or retry the
  datagram from the first fragment with an 'X' flag set in order to
  reestablish a path and discover which fragments were received over
  the old path in the acknowledgment bitmap.  When the sender of the

I'm not sure I'm understanding properly what's meant by "retry the
datagram from the first fragment with an 'X' flag set".  My best guess
is that it's saying "re-send the fragment with sequence number 0, and
set the 'X' flag in this new transmission", in which case I'd suggest
s/from the first fragment with an 'X' flag set/from the first fragment,
setting the 'X' flag in the retransmitted fragment,/.

  The receiver MAY issue unsolicited acknowledgments.  An unsolicited
  acknowledgment signals to the sender endpoint that it can resume
  sending if it had reached its maximum number of outstanding
  fragments.  Another use is to inform the sender that the reassembling

How would the sender get into a situation where it has saturated its
transmit window but not requested an ACK?  Is this just the case where
the fragment requesting an ACK gets lost and thus we have to rely on
some timeout (whether at the sender or the receiver) to recover?  It
seems like we may need to define a symbolic constant for the
"unsolicited ACK" timer after no fragments are received, and give some
guidance on how to determine it.

  The RFRAG Acknowledgment can optionally carry an ECN indication for
  flow control (see Appendix C).  The receiver of a fragment with the
  'E' (ECN) flag set MUST echo that information by setting the 'E'
  (ECN) flag in the next RFRAG Acknowledgment.

I'm not sure I'd use the word "optionally" here -- IIUC the idea is to
make it mandatory to implement the ECN behavior, and the ECN indication
is only "optional" in that it is sometimes set, but when it is set and
when it is not set are mandatory parts of the protocol, not subject to
implementation discretion.  If that's correct, then I'd just say "The
RFRAG Acknowledgment carries and ECN indication for flow control".

  round-trip delay in the network.  As the timer runs, the receiving
  endpoint absorbs the fragments that were still in flight for that
  datagram without creating a new state.  The receiving endpoint aborts
  the communication if it keeps going on beyond the duration of the
  timer.

(This "absorbs" the behavior is to catch retransmissions, right?  Might
be worth saying so, though also might not.)
I'd suggest expanding "if it keeps going", perhaps as "if fragments with
matching source and tag continue to be received after the timer
expires".

  Fragments are sent in a round-robin fashion: the sender sends all the
  fragments for a first time before it retries any lost fragment; lost
  fragments are retried in sequence, oldest first.  This mechanism
  enables the receiver to acknowledge fragments that were delayed in
  the network before they are retried.

Is this round-robin within a given "window" or within the entire packet?

  When a single frequency is used by contiguous hops, the sender should

nit: "radio frequency"?  Retransmissions have a frequency, too (though
several orders of magnitude different!).

Section 6.1

  label, which is swapped in each hop.  All fragments follow the same
  path and fragments are delivered in the order in which they are sent.

Where do we make a normative requirement for intermediate nodes to
retain order in transmitting fragments?

Section 6.1.1

  In Route-Over mode, the source and destination MAC addresses in a

It feels surprising to mention Route-Over mode and not have a
corresponding mention of Mesh-Under.

  (and unique) for that source MAC address.  Upon receiving the first
  fragment (i.e., with a Sequence of zero), an intermediate router
  creates a VRB and the associated LSP state for the tuple (source MAC
  address, Datagram_Tag) and the fragment is forwarded along the IPv6
  route that matches the destination IPv6 address in the IPv6 header as
  prescribed by [I-D.ietf-6lo-minimal-fragment], where the receiving
  endpoint allocates a reassembly buffer.

nit: please check the comma usage here (the last one looks misplaced, to
my eye).

  Datagram_Tag.  This reverse LSP state also points at the VRB and
  enables matching the (next MAC address, swapped_Datagram_Tag) found
  in an RFRAG Acknowledgment to the tuple (previous MAC address,

nit(?): doesn't this "reverse lookup" only depend on the
swapped_Datagram_Tag?  I don't think "next MAC address" is needed.

  The first fragment may be received a second time, indicating that it
  did not reach the destination and was retried.  In that case, it
  SHOULD follow the same path as the first occurrence.  It is up to
  sending endpoint to determine whether to abort a transmission and
  then retry it from scratch, which may build an entirely new path.

This seems to be alluding to the text in Section 6 about "or retry the
datagram from the first fragment with an 'X' flag set in order to
reestablish a path", however, my reading of that text is that the same
datagram tag value is used in the retry, in which case the
retransmission of the first fragment seems like it would be
indistinguishable from any other retransmission, to the intermediate
node.  If a new tag was to be allocated, then we would not be able to
get information about fragments received over the old path as Section 6
discusses.  So it seems like this recommendation here ("use the same
path") is at odds with the implied recommendation in the earlier text
("use a potentially different path"), and it would be worth some
discussion to resolve the apparent disparity.

Section 6.1.2

  [I-D.ietf-6lo-minimal-fragment] indicates that the receiving endpoint
  stores "the actual packet data from the fragments received so far, in
  a form that makes it possible to detect when the whole packet has
  been received and can be processed or forwarded".  How this is
  computed is implementation specific but relies on receiving all the
  bytes up to the Datagram_Size indicated in the first fragment.  An
  implementation may receive overlapping fragments as the result of
  retries after an MTU change.

This text leaves me feeling unsatisfied, for a couple reasons:
(1) I have to think to infer that "receiving endpoint" means "the
intermediate router receiving the fragments" and not the ultimate (IPv6)
destination
(2) overlapping fragments that contain different data can be a security
risk, and we don't discuss that here (whether directly or by reference).

Section 6.2

  Upon receipt of an RFRAG-ACK, the router looks up a reverse LSP
  indexed by the tuple (MAC address, Datagram_Tag), which are

(As above, is the MAC address needed here?)

  Either way, if the RFRAG-ACK indicates that the fragment was entirely
  received (FULL bitmap), it arms a short timer, and upon timeout, the
  VRB and all the associated state are destroyed.  Until the timer

Is there anything that could cancel this timer (e.g., an RFRAG-ACK that
with non-FULL bitmap)?

  This specification does not provide a method to discover the number
  of hops or the minimal value of MTU along those hops.  But should the
  minimal MTU decrease, it is possible to retry a long fragment (say
  Sequence of 5) with first a shorter fragment of the same Sequence (5
  again) and then one or more other fragments with a Sequence that was
  not used before (e.g., 13 and 14).  Note that Path MTU Discovery is
  out of scope for this document.

[another mention of sequence number reuse]

Section 6.3

  A reset is signaled on the forward path with a pseudo fragment that
  has the Fragment_Offset, Sequence, and Fragment_Size all set to 0,
  and no data.

The text in Section 5.1 indicates that an abort is characterized by
Fragment_Offset of zero.  I don't think that it has a requirement to set
the other fields to zero in order to be considered an abort.

  When the sender or a router on the way decides that a packet should

nit: I don't think we've used "on the way" previously in this sense (and
do use "on the path").  Though, it looks like we do use "on the way"
again a few paragraphs later.

  The other way around, the receiver might need to abort the process of
  a fragmented packet for internal reasons, for instance if it is out
  of reassembly buffers, already uses all 256 possible values of the
  Datagram_Tag, or if it keeps receiving fragments beyond a reasonable
  time while it considers that this packet is already fully reassembled
  and was passed to the upper layer.  In that case, the receiver SHOULD

nit: s/process/processing/?

Section 7

We can probably inherit discussion of integrity and confidentiality
(non-)protection from -minimal-fragment, assuming my recommended changes
there are made.  It remains the case, though, that intermediate nodes
can always modify the payload and disrupt/deny service, and I, for one,
would not turn down another reminder of that.

  This specification extends "On Forwarding 6LoWPAN Fragments over a
  Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] and requires
  the same parameters in the receiver and on intermediate nodes.  There
  is no new parameter as echoing ECN is always on.  These parameters
  typically include the reassembly time-out at the receiver and an
  inactivity clean-up timer on the intermediate nodes, and the number
  of messages that can be processed in parallel in all nodes.

Do we have a new parameter for the "timer for a receiver node to send an
unsolicited ack if no additional fragments are received"?

  The configuration settings introduced by this specification only
  apply to the sender, which is in full control of the transmission.

(Similarly, this is "full control" modulo acks.)

Section 7.1

  OptWindowSize:  The OptWindowSize is the value for the Window_Size
      that the sender should use to start with.  It is greater than or
      equal to MinWindowSize.  It is less than or equal to
      MaxWindowSize.  The Window_Size should be maintained below the
      number of hops in the path of the fragment to avoid stacking
      fragments at the bottleneck on the path.  If an inter-frame gap is
      used to avoid interference between fragments then the Window_Size
      should be at most on the order of the estimation of the trip time
      divided by the inter-frame gap.

Let's do some dimensional analysis here: the window size is measured in
number of frames, the trip time is measured in time, and the inter-frame
gap is discussed above as an "amount of time" (though whether this is an
absolute time value or a count of transmit windows is perhaps subject to
interpretation).  The ratio of trip time deivided by inter-frame gap,
then, is dimensionless, which we then try to interpret as a number of
frames.  That's probably okay, though mathematics pedants might want
some additional clarifying discussion.

  An implementation may be capable of performing flow control based on
  ECN; see in Appendix C.  This is controlled by the following
  parameter:

  UseECN:  Indicates whether the sender should react to ECN.  The
      sender may react to ECN by varying the Window_Size between
      MinWindowSize and MaxWindowSize, varying the Fragment_Size between
      MinFragmentSize and MaxFragmentSize, and/or by increasing the
      inter-frame gap.

Please forgive the naivite, but shouldn't this parameter merely control
*how* an implementation responds to ECN markings, not *whether or not it
should respond at all* (since obviously it should respond in some
fashion)?

Section 11

I'm not seeing why RFC 6554 (as referenced in one location only) is a
normative reference.

Section 12

Given that "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]", RFC 4919 seems like it is more properly categorized
as Normative.  Similarly for RFC 6606.

I don't have strong feelings about RFC 8200's status, though I suppose
one could argue that one needs to parse the network header in order to
route the initial fragment.

Appendix A

  Considering that RFC 4944 defines an MTU is 1280 bytes and that in
  most incarnations (but 802.15.4g) a IEEE Std. 802.15.4 frame can
  limit the MAC payload to as few as 74 bytes, a packet might be

I'm not sure I'm parsing this properly, but I think "except" is more
approriate than "but" in the parenthetical.

Appendix C

  From the standpoint of a source 6LoWPAN endpoint, an outstanding
  fragment is a fragment that was sent but for which no explicit
  acknowledgment was received yet.  This means that the fragment might

Is there also a timer that has to have not expired yet?

[Ballot comment]
I am uncertain if there is security risk that is poorly noted. I don't think it is significant as an intermediate node will in many other ways be able to interfere with the transmission of the fragments. However, it appears to me that the below formulation potentially allow a fragment sender to go into an interesting state by acknowledging fragments prior to even have received them, causing the sender to abort the transmission prematurely?

  When all the fragments are received, the receiving endpoint
  reconstructs the packet, passes it to the upper layer, sends an RFRAG
  Acknowledgment on the reverse path with a FULL bitmap, and arms a
  short timer, e.g., in the order of an average round-trip delay in the
  network.  As the timer runs, the receiving endpoint absorbs the
  fragments that were still in flight for that datagram without
  creating a new state.  The receiving endpoint abort the communication
  if it keeps going on beyond the duration of the timer.

Could the author please comment on this aspect of what would occur in the fragment sender if it receives an RFRAG-ACK will full bitmap prior to having send all fragments, and also what would happen if this is received very shortly after having sent the last fragment?

[Ballot comment]
Thank you for this easy to read document.

** Section 5.1.  Per “There is no requirement on the receiver to check for contiguity of the received fragments, and the sender MUST ensure that when all fragments are acknowledged, then the datagram is fully received.”, the second clause doesn’t parse for me.  What must the sender ensure when all of the fragments are acknowledged?

** Section 5.1.  Fragment_Size.  If this is a 10-bit unsigned integer and the unit is an octet, shouldn’t fragments up to 1024-1 bytes be possible (not 512)?

** Editorial

-- Section 5.2.  Editorial. 
s/A NULL bitmap that indicates that the …/
A NULL bitmap indicates that the …/
s/A FULL bitmap that indicates that the …/
A FULL bitmap indicates that the …/

-- Section 6.1.  Recommend replacing colloquial language – “It inherits … using a timer to clean the VRB when the traffic _dries up_”

-- Section 10.  Typo. s/ot this/to this/

[Ballot comment]
** Section 5.1.  Per “There is no requirement on the receiver to check for contiguity of the received fragments, and the sender MUST ensure that when all fragments are acknowledged, then the datagram is fully received.”, the second clause doesn’t parse for me.  What must the sender ensure when all of the fragments are acknowledged?

** Section 5.1.  Fragment_Size.  If this is a 10-bit unsigned integer and the unit is an octet, shouldn’t fragments up to 1024-1 bytes be possible (not 512)?

** Editorial

-- Section 5.2.  Editorial. 
s/A NULL bitmap that indicates that the …/
A NULL bitmap indicates that the …/
s/A FULL bitmap that indicates that the …/
A FULL bitmap indicates that the …/

-- Section 6.1.  Recommend replacing colloquial language – “It inherits … using a timer to clean the VRB when the traffic _dries up_”

-- Section 10.  Typo. s/ot this/to this/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6lo-fragment-recovery-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Dispatch Type Field registry on the IPv6 Low Power Personal Area Network Parameters registry page located at:

https://www.iana.org/assignments/_6lowpan-parameters/

two values are to be registered in Page 0 for recoverable fragments as follows:

Bit Pattern: 11 10100x
Page: 0
Header Type: RFRAG - Recoverable Fragment
Reference: [ RFC-to-be ]

Bit Pattern: 11 10101x
Page: 0
Header Type: RFRAG-ACK - RFRAG Acknowledgment
Reference: [ RFC-to-be ]

IANA Question --> Section 9 of the current draft says: "This document allocates 4 values in Page 0 for recoverable fragments from the "Dispatch Type Field" registry. . ." However, Table 1 only provides two values. Are there two other values that should be registered?

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-01-30):

From: The IESG
To: IETF-Announce
CC: 6lo-chairs@ietf.org, suresh@kaloom.com, 6lo@ietf.org, draft-ietf-6lo-fragment-recovery@ietf.org, carlesgo@entel.upc.edu, Carles Gomez
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (6LoWPAN Selective Fragment Recovery) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document: -
'6LoWPAN Selective Fragment Recovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-01-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This draft updates RFC 4944 with a simple protocol to recover
  individual fragments across a route-over mesh network, with a minimal
  flow control to protect the network against bloat.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
SHEPHERD RESPONSE:  Proposed Standard (the title page header shows the “Standards Track” label).
This is the proper type of RFC because the document updates RFC 4944 (a Standards Track RFC that defines the original 6LoWPAN fragmentation functionality) with a protocol for recovering individual fragments in a route-over mesh network, and a minimal flow control.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

SHEPHERD RESPONSE:
Technical Summary

  This document updates RFC 4944 with a simple protocol to recover
  individual fragments across a route-over mesh network, with a minimal
  flow control to protect the network against bloat.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

SHEPHERD RESPONSE:

Older versions of a precursor of this document existed as an individual submission discussed in the 6lowpan working group between 2008 and 2010, and were discussed again during the initial stages of the 6lo working group lifetime (e.g. at IETF 88). Some concerns were expressed at the time, such as potential interactions across layers. The topic of fragmentation attracted increased interest from participants at the 6lo working group again in 2016-2017, with dedicated fragmentation discussion slots in 6lo at IETF 98 and IETF 99. As a result, a fragmentation Design Team was formed. It was decided that two 6lo wg documents and one lwig wg document would be created, more specifically: a) a document defining a fragment recovery protocol (i.e. the document that is the object of this writeup), b) an informational document giving an overview of minimal fragment forwarding, and c) a document describing the implementation technique that avoids per-hop packet fragmentation and reassembly. This decision had good WG consensus, and no controversy has occurred since then regarding any of the three mentioned documents.



Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
One WG participant expressed on the mailing list that he was working on an implementation. His feedback contributed to improving the document.


  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

SHEPHERD RESPONSE:
Michel Veillette carried out a thorough review of the document before it became a 6lo wg document.
Laurent Toutain and Carles Gomez, both with a background in fragmentation in constrained node networks, did comprehensive reviews of recent versions of the document, based on revisions -02 and -03, which led to revisions -03 and -04.  As a result of the shepherd (Carles Gomez) review, the document was again updated, leading to versions -05 and -06). Another WG participant provided comments in parallel, leading to the current version as of the writing (i.e. -07).

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

SHEPHERD RESPONSE: N/A

Personnel

Document Shepherd: Carles Gomez
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
SHEPHERD RESPONSE:
I first reviewed revision -03 of the document. My comments were addressed in version -04. As the shepherd, I reviewed again the document, and found few other issues more related with the shepherd write-up, which were addressed in -05 and -06. In my opinion, the document is now (-07) ready  for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
SHEPHERD RESPONSE: No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
SHEPHERD RESPONSE: As mentioned in the response to question (2), Laurent Toutain and Carles Gomez performed comprehensive reviews of recent versions of the draft. Both reviewers have a background in fragmentation in constrained node networks. No other particular reviews were needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
SHEPHERD RESPONSE: No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
SHEPHERD RESPONSE: The document author has confirmed that he is unaware of IPR on this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
SHEPHERD RESPONSE: No IPRs found.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
SHEPHERD RESPONSE: as mentioned in the response to question (2), the consensus behind this document is solid, with the WG as a whole understanding and agreeing with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
SHEPHERD RESPONSE: No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
SHEPHERD RESPONSE: One downref “error” has been identified (see the answer to question (15)). There are also comments from the idnits tool. The relevant details from the idnits tool output follow:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
-- The document date (April 2020) is 175 days in the future.  Is this
    intentional?
** Downref: Normative reference to an Informational draft:
    draft-ietf-6lo-minimal-fragment (ref. 'I-D.ietf-6lo-minimal-fragment')

    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
SHEPHERD RESPONSE: N/A.

(13) Have all references within this document been identified as
either normative or informative?
SHEPHERD RESPONSE: Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
SHEPHERD RESPONSE: No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
SHEPHERD RESPONSE: Yes, there is 1 downward normative reference, which is draft-ietf-6lo-minimal-fragment. This reference is an informational document located in the normative references subsection. In fact, this reference qualifies as a document that “must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work” (https://www.ietf.org/blog/iesg-statement-normative-and-informative-references).

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
SHEPHERD RESPONSE: this document updates RFC 4944, as listed on the title page header, mentioned in the Abstract and explained in the Introduction (although the verb “update” is not used in the latter). Section 3 is entitled “Updating RFC 4944”.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
SHEPHERD RESPONSE:
The document defines 2 new 6LoWPAN Dispatch types (and allocates 4 values) in Page 0 from the "Dispatch Type Field" registry (RFC 4944, RFC 8025). Section 9 of the document, entitled "IANA considerations", details the IANA actions needed. The actions requested from IANA are appropriate from the point of view of the shepherd.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
SHEPHERD RESPONSE: N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
SHEPHERD RESPONSE: Not applicable as there are no formal language constructs in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
SHEPHERD RESPONSE:  Proposed Standard (the title page header shows the “Standards Track” label).
This is the proper type of RFC because the document updates RFC 4944 (a Standards Track RFC that defines the original 6LoWPAN fragmentation functionality) with a protocol for recovering individual fragments in a route-over mesh network, and a minimal flow control.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

SHEPHERD RESPONSE:
Technical Summary

  This document updates RFC 4944 with a simple protocol to recover
  individual fragments across a route-over mesh network, with a minimal
  flow control to protect the network against bloat.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

SHEPHERD RESPONSE:

Older versions of a precursor of this document existed as an individual submission discussed in the 6lowpan working group between 2008 and 2010, and were discussed again during the initial stages of the 6lo working group lifetime (e.g. at IETF 88). Some concerns were expressed at the time, such as potential interactions across layers. The topic of fragmentation attracted increased interest from participants at the 6lo working group again in 2016-2017, with dedicated fragmentation discussion slots in 6lo at IETF 98 and IETF 99. As a result, a fragmentation Design Team was formed. It was decided that two 6lo wg documents and one lwig wg document would be created, more specifically: a) a document defining a fragment recovery protocol (i.e. the document that is the object of this writeup), b) an informational document giving an overview of minimal fragment forwarding, and c) a document describing the implementation technique that avoids per-hop packet fragmentation and reassembly. This decision had good WG consensus, and no controversy has occurred since then regarding any of the three mentioned documents.



Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
One WG participant expressed on the mailing list that he was working on an implementation. His feedback contributed to improving the document.


  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

SHEPHERD RESPONSE:
Michel Veillette carried out a thorough review of the document before it became a 6lo wg document.
Laurent Toutain and Carles Gomez, both with a background in fragmentation in constrained node networks, did comprehensive reviews of recent versions of the document, based on revisions -02 and -03, which led to revisions -03 and -04.  As a result of the shepherd (Carles Gomez) review, the document was again updated, leading to versions -05 and -06). Another WG participant provided comments in parallel, leading to the current version as of the writing (i.e. -07).

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

SHEPHERD RESPONSE: N/A

Personnel

Document Shepherd: Carles Gomez
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
SHEPHERD RESPONSE:
I first reviewed revision -03 of the document. My comments were addressed in version -04. As the shepherd, I reviewed again the document, and found few other issues more related with the shepherd write-up, which were addressed in -05 and -06. In my opinion, the document is now (-07) ready  for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
SHEPHERD RESPONSE: No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
SHEPHERD RESPONSE: As mentioned in the response to question (2), Laurent Toutain and Carles Gomez performed comprehensive reviews of recent versions of the draft. Both reviewers have a background in fragmentation in constrained node networks. No other particular reviews were needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
SHEPHERD RESPONSE: No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
SHEPHERD RESPONSE: The document author has confirmed that he is unaware of IPR on this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
SHEPHERD RESPONSE: No IPRs found.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
SHEPHERD RESPONSE: as mentioned in the response to question (2), the consensus behind this document is solid, with the WG as a whole understanding and agreeing with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
SHEPHERD RESPONSE: No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
SHEPHERD RESPONSE: One downref “error” has been identified (see the answer to question (15)). There are also comments from the idnits tool. The relevant details from the idnits tool output follow:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
-- The document date (April 2020) is 175 days in the future.  Is this
    intentional?
** Downref: Normative reference to an Informational draft:
    draft-ietf-6lo-minimal-fragment (ref. 'I-D.ietf-6lo-minimal-fragment')

    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
SHEPHERD RESPONSE: N/A.

(13) Have all references within this document been identified as
either normative or informative?
SHEPHERD RESPONSE: Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
SHEPHERD RESPONSE: No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
SHEPHERD RESPONSE: Yes, there is 1 downward normative reference, which is draft-ietf-6lo-minimal-fragment. This reference is an informational document located in the normative references subsection. In fact, this reference qualifies as a document that “must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work” (https://www.ietf.org/blog/iesg-statement-normative-and-informative-references).

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
SHEPHERD RESPONSE: this document updates RFC 4944, as listed on the title page header, mentioned in the Abstract and explained in the Introduction (although the verb “update” is not used in the latter). Section 3 is entitled “Updating RFC 4944”.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
SHEPHERD RESPONSE:
The document defines 2 new 6LoWPAN Dispatch types (and allocates 4 values) in Page 0 from the "Dispatch Type Field" registry (RFC 4944, RFC 8025). Section 9 of the document, entitled "IANA considerations", details the IANA actions needed. The actions requested from IANA are appropriate from the point of view of the shepherd.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
SHEPHERD RESPONSE: N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
SHEPHERD RESPONSE: Not applicable as there are no formal language constructs in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
SHEPHERD RESPONSE:  Proposed Standard (the title page header shows the “Standards Track” label).
This is the proper type of RFC because the document updates RFC 4944 (a Standards Track RFC that defines the original 6LoWPAN fragmentation functionality) with a protocol for recovering individual fragments in a route-over mesh network, and a minimal flow control.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

SHEPHERD RESPONSE:
Technical Summary

  This document updates RFC 4944 with a simple protocol to recover
  individual fragments across a route-over mesh network, with a minimal
  flow control to protect the network against bloat.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

SHEPHERD RESPONSE:

Older versions of a precursor of this document existed as an individual submission discussed in the 6lowpan working group between 2008 and 2010, and were discussed again in the initial stages of the 6lo working group lifetime (e.g. at IETF 88). Some concerns were expressed at the time, such as potential interactions across layers. The topic of fragmentation attracted increased interest from participants at the 6lo working group again in 2016-2017, with dedicated fragmentation discussion slots in 6lo at IETF 98 and IETF 99. As a result, a fragmentation Design Team was formed. It was decided that two 6lo wg documents and one lwig wg document would be created, more specifically: a) a document defining a fragment recovery protocol (i.e. the document that is the object of this writeup), b) an informational document giving an overview of minimal fragment forwarding, and c) a document describing the implementation technique that avoids per-hop packet fragmentation and reassembly. This decision had good WG consensus, and no controversy has occurred since then regarding any of the three mentioned documents.



Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
One WG participant expressed on the mailing list that he was working on an implementation. His feedback contributed to improving the document.


  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

SHEPHERD RESPONSE:
Michel Veillette carried out a thorough review of the document before it became a 6lo wg document.
Laurent Toutain and Carles Gomez, both with a background in fragmentation in constrained node networks, did comprehensive reviews of recent versions of the document, based on revisions -02 and -03, which led to revisions -03 and -04.  As a result of the shepherd (Carles Gomez) review, the document was again updated, leading to the current version as of the writing (i.e. -05).

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

SHEPHERD RESPONSE: N/A

Personnel

Document Shepherd: Carles Gomez
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
SHEPHERD RESPONSE:
I first reviewed revision -03 of the document. My comments were addressed in version -04. As the shepherd, I reviewed again the document, and found few other issues more related with the shepherd write-up, which were addressed in -05. In my opinion, the document is now ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
SHEPHERD RESPONSE: No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
SHEPHERD RESPONSE: As mentioned in the response to question (2), Laurent Toutain and Carles Gomez performed comprehensive reviews of recent versions of the draft. Both reviewers have a background in fragmentation in constrained node networks. No other particular reviews were needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
SHEPHERD RESPONSE: No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
SHEPHERD RESPONSE: The document author has confirmed that he is unaware of IPR on this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
SHEPHERD RESPONSE: No IPRs found.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
SHEPHERD RESPONSE: as mentioned in the response to question (2), the consensus behind this document is solid, with the WG as a whole understanding and agreeing with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
SHEPHERD RESPONSE: No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
SHEPHERD RESPONSE: Two downref “errors” have been identified (see the answer to question (15)). There are also warnings and comments from the idnits tool. The relevant details from the idnits tool output follow:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
  -- The document date (July 22, 2019) is 90 days in the past.  Is this
    intentional?
  == Outdated reference: A later version (-04) exists of
    draft-ietf-6lo-minimal-fragment-02
  ** Downref: Normative reference to an Informational draft:
    draft-ietf-6lo-minimal-fragment (ref. 'I-D.ietf-6lo-minimal-fragment')
  ** Downref: Normative reference to an Informational draft:
    draft-ietf-lwig-6lowpan-virtual-reassembly (ref.
    'I-D.ietf-lwig-6lowpan-virtual-reassembly')
  == Outdated reference: A later version (-27) exists of
    draft-ietf-6tisch-architecture-24
  == Outdated reference: A later version (-17) exists of
    draft-ietf-intarea-frag-fragile-15

    Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
SHEPHERD RESPONSE: N/A.

(13) Have all references within this document been identified as
either normative or informative?
SHEPHERD RESPONSE: Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
SHEPHERD RESPONSE: No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
SHEPHERD RESPONSE: Yes, there are 2 downward normative references, which are draft-ietf-6lo-minimal-fragment and draft-ietf-lwig-6lowpan-virtual-reassembly. These references are informational documents that are located in the normative references subsection. In fact, these references qualify as documents that “must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work” (https://www.ietf.org/blog/iesg-statement-normative-and-informative-references).

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
SHEPHERD RESPONSE: this document updates RFC 4944, as listed on the title page header, mentioned in the Abstract and explained in the Introduction (although the verb “update” is not used in the latter). Section 3 is entitled “Updating RFC 4944”.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
SHEPHERD RESPONSE:
The document defines 2 new 6LoWPAN Dispatch types (and allocates 4 values) in Page 0 from the "Dispatch Type Field" registry (RFC 4944, RFC 8025). Section 9 of the document, entitled "IANA considerations", details the IANA actions needed. The actions requested from IANA are appropriate from the point of view of the shepherd.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
SHEPHERD RESPONSE: N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
SHEPHERD RESPONSE: Not applicable as there are no formal language constructs in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Shepherd response:  Proposed Standard (the title page header reads “Standards Track”).
This is the proper type of RFC because the document updates RFC 4944 (which defines the original 6LoWPAN fragmentation functionality) with a protocol for recovering individual fragments in a route-over mesh network, and a minimal flow control.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

  This document updates RFC 4944 with a simple protocol to recover
  individual fragments across a route-over mesh network, with a minimal
  flow control to protect the network against bloat.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:

Older versions of a precursor of this document existed as an individual submission discussed in the 6lowpan working group between 2008 and 2010, and were discussed again in the initial stages of the 6lo working group lifetime (e.g. at IETF 88). Some concerns were expressed at the time, such as potential interactions across layers. The topic of fragmentation attracted increased interest from participants at the 6lo working group again in 2016-2017, with dedicated fragmentation discussion slots in 6lo at IETF 98 and IETF 99. As a result, a fragmentation Design Team was formed. It was decided that two 6lo wg documents and one lwig wg document would be created, more specifically: a) a document defining a fragment recovery protocol (i.e. the document that is the object of this writeup), b) an informational document giving an overview of minimal fragment forwarding, and c) a document describing the implementation technique that avoids per-hop packet fragmentation and reassembly. This decision had good consensus, and no controversy has occurred since then regarding any of the three mentioned documents.



Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response:
One WG participant expressed on the mailing list that he was working on an implementation. His feedback contributed to improving the document.


  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Shepherd response:
Michel Veillette carried out a thorough review of the document before it became a 6lo wg document.
Laurent Toutain and Carles Gomez, both with a background in fragmentation in constrained node networks, did comprehensive reviews of recent versions of the document, based on revisions -02 and -03, which led to the updated revisions -03 and -04. 

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Shepherd response: N/A

Personnel

Document Shepherd: Carles Gomez
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I reviewed revision -03 of the document. My comments are addressed in version    -04. In my opinion, the document is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response: No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response: As mentioned in the response to question (2), Laurent Toutain and Carles Gomez performed comprehensive reviews of recent versions of the draft. Both reviewers have a background in fragmentation in constrained node networks. No other particular reviews were needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: The document author has confirmed that he is unaware of IPR on this document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: No IPRs found.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: as mentioned in the response to question (2), the consensus behind this document is solid, with the WG as a whole understanding and agreeing with it.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: One downref “error” has been identified (see the answer to question (15)). There are also warnings and comments from the idnits tool. The relevant details from the idnits tool output follow:
  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)
  -- The document date (June 11, 2019) is 36 days in the past.  Is this
    intentional?
  == Outdated reference: A later version (-02) exists of
    draft-ietf-6lo-minimal-fragment-01
  ** Downref: Normative reference to an Informational draft:
    draft-ietf-6lo-minimal-fragment (ref. 'I-D.ietf-6lo-minimal-fragment')
  == Outdated reference: A later version (-24) exists of
    draft-ietf-6tisch-architecture-20
  Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: N/A.

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: Yes, there is one downward normative reference, which is draft-ietf-6lo-minimal-fragment. This reference is an informational document that is located in the normative references subsection. In fact, this reference qualifies as a document that “must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work” (https://www.ietf.org/blog/iesg-statement-normative-and-informative-references).

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: this document updates RFC 4944, as listed on the title page header, mentioned in the Abstract and explained (although the verb “update” is not used) in the Introduction. Section 3 is entitled “Updating RFC 4944”.
On the other hand, Section 4 is entitled “Updating draft-ietf-6lo-minimal-fragment”. The draft-ietf-6lo-minimal-fragment document is not currently an RFC, although it is currently being processed in parallel with the fragment recovery draft that is the object of this writeup. Note that draft-ietf-6lo-minimal-fragment is not listed on the title page header, and not mentioned in the abstract or the introduction. However, it is mentioned in Section 2.4 and in Section 4.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response:
The document defines 2 new 6LoWPAN Dispatch types from Page 0 (RFC 8025). The  details for IANA actions needed are clearly presented in Section 5, whereas the “IANA considerations” section only mentions that extensions are needed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: N/A.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Not applicable as there are no formal language constructs in the document.