On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
draft-ietf-6lo-minimal-fragment-15

Received changes through RFC Editor sync (created alias RFC 8930, changed title to 'On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network', changed abstract to 'This document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network.  Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs).', changed pages to 12, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-11-23, changed IESG state to RFC Published)

[Ballot comment]
Thank you for addressing my Discuss (and Comment) points!

In the security considerations, perhaps "fragment 1" would be
better as "first-fragment" to avoid questions of zero- vs. one-indexing.

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

— Section 2.2 —

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

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

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

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

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

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

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

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

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

— Section 2.3 —

  This specification uses the following terms:

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

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

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

— Section 4 —

  4. Limits of Per-Hop Fragmentation and Reassembly

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

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

— Section 5 —

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

Make it “refrains”.

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

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

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

— Section 7 —

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

Capitalize “This”.

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

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

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

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

— Section 9 —

  Also many thanks to Georgies Papadopoulos

I believe it’s “Georgios”.

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

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

+ + + + + + + + + + + + + + + + + + + +

The following are comments from Murray Kucherawy, incoming ART AD.  Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director.

- - - - - - - - - - - - - - - - - - - -

Section 2.2 does a great job of laying out the context for this work.

The only thing that came up for me reading this is the SHOULD NOT in Section 7, where I think they might consider adding a sentence or two about why an implementer might decide to deviate from that advice.

[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 comment]
Thank you for the work put into this document. It is very easy to read.

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

As I reviewed draft-ietf-6lo-fragment-recovery before this document, I put some COMMENTs in my review of draft-ietf-6lo-fragment-recovery that also apply to this document.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Is there a reason why this document uses "Link-Layer address" while the companion, draft-ietf-6lo-fragment-recovery, uses "MAC address" ? This is cosmetic of course but if the concept is the same, using the same wording could only improve the readability of the documents. Same applies for "datagram_tag" vs "Datagram_Tag" ;-)


-- Section 5 --
"Multiple fragments may progress in parallel" is not really correct as the rather travel "simultaneously" as they follow the same path but at different steps (i.e. not like using parallel links).

-- Section 6 --
The "no per-fragment routing" can also be seen as an advantage as it forces all fragments to be in order.

== NITS ==

Is the case in "Link-Layer" correct? I am a non native speaker but I would have used "link-layer".

[Ballot comment]
I agree with one of Ben's comments in that I'm not certain about the intended document status as PS. I think Informational might be more appropriate, as it rather describes an approach based on existing protocols than a normative protocol specification.

Thanks for quickly addressing the TSV-ART comments (and thanks Jörg for the TSV-ART review)!

[Ballot comment]
I agree with one of Ben's comments in that I'm not certain about the intended document status as PS. I think Informational might be more appropriate, as it rather describes an approach based on existing protocols than a normative protocol specification.

Thanks for quickly addressing the TSV-ART comments (and thanks Jörg for the TSV-ART review)

[Ballot discuss]
I think we need to be more explicit (whether inline or by reference)
about what "Secure joining and the Link-Layer security that it sets up"
(Section 7) entails in terms of ensuring that access to the LLN is only
available to authenticated and authorized entities.  It might be worth
doing so as explicit assumptions or an applicability statement early in
the document (e.g., the Introduction).

Also, 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.

[Ballot comment]
My initial reading of this document was that it was saying that we
literally forwarded fragments from the sending node, changing only the
tag and link-layer addresses; on the contrary, [LWIG-VRB] is preetty
clear that there may be a need to slice up fragments along the way and
carry a "tail" of a previous fragment that gets inserted into the
beginning of the next fragment.  I would suggest tweaking the
Introduction slightly to avoid the misreading that I fell into, perhaps
by s/whereby an intermediate node forwards a fragment as soon as it is
received if the next hop is a similar 6LoWPAN link/whereby an
intermediate node forwards a fragment (or the bulk thereof, MTU
permitting) as soon as it is received if the next hop is a similar
6LoWPAN link/.  It might also be possible to note in the definition of
"fragment_offset" that it applies only to a given hop/transmission, and
that the packet's fragmentation could be adjusted at each intermediate
node.  I'd also suggest expanding on the need for "a buffer for the
remainder of a previous fragment left to be sent" in Section 5.

The shepherd writeup indicates that, after Dave Thaler's review, there
was a perceived need to provide normative protocol specification in this
document for "how to do fragment forwarding"; Section 6 seems to be the
closest thing to that, but is not really such a specification.  Some
further clarity on subsequent evolution of the WG's goals and
whether/why such protocol specification is no longer needed in this
document would be appreciated.  In particular, it's not clear (anymore?)
why VRB is so privileged to get its own section, when there are
alternative approaches.

Abstract

  This document introduces the capability to forward 6LoWPAN fragments.
  This method reduces the latency and increases end-to-end reliability
  in route-over forwarding.  It is the companion to using virtual
  reassembly buffers which is a pure implementation technique.

nit: I don't really see what sense of "companion" is supposed to apply,
here; perhaps a different word would work better?  (In my head, VRB is
an "incarnation" of the generic "fragment forwarding technique", which
would be a bit more churn than just swapping out one word here.)

Section 1

  This specification provides a generic overview of FF, discusses
  advantages and caveats, and introduces a particular 6LoWPAN Fragment
  Forwarding technique called Virtual Reassembly Buffer that can be
  used while conserving the message formats defined in [RFC4944].

nit: I'd double-check that "conserving" is the intended meaning; to my
ignorant eye "retaining" or "preserving" would be more appropriate.

Section 2.2

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

nit: I think "underneath the IP layer"?

Section 2.3

  6LoWPAN endpoints:  The 6LoWPAN endpoints are the first and last
      nodes in an unbroken string of 6LoWPAN nodes.  They are in charge
      of generating or expanding a 6LoWPAN header from/to a full IPv6
      packet.  They are also the points where the fragmentation and
      reassembly operations take place.

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.

  fragment_offset:  The offset of a fragment of a datagram in its
      Compressed Form.  The fragment_offset is expressed in a unit that
      depends on the MAC layer technology and is by default a byte.

(The same unit as the datagram_size, I trust.)

Section 3

  Node A starts by compacting the IPv6 packet using the header
  compression mechanism defined in [RFC6282].  If the resulting 6LoWPAN

The previous discussion implies that A at least sometimes is starting
from an existing 6LoWPAN compressed-form packet (as opposed to a fully
expanded IPv6 packet); would "(if needed)" be appropriate?  (Perhaps I'm
misreading this implication into things.)

Section 5

  the destination.  Upon a first fragment, a forwarding node (e.g. node
  B in a A->B->C sequence) that does fragment forwarding MUST attempt
  to create a state and forward the fragment.  This is an atomic

There seems to be a verb missing here ("Upon receiving"?).

  Consecutive fragments of a same datagram must be separated with an
  inter-frame gap that allows one fragment to progress before the next
  shows up.  This can be achieved by interleaving packets or fragments
  sent via different next-hop routers.

What's the tradeoff on making this "must be separated" vs. "MUST be
separated"?  (Do we want exactly a one-frame gap or a gap of at least
one frame?)

Section 6

Would it be appropriate to transition from the previous sentence by
saying that "VRB is a particular incarnation of a 6LoWPAN Fragment
Forwarding technique" as the second sentence of the first paragraph?

  The severity and occurrence of these caveats depends on the Link-
  Layer used.  Whether they are acceptable depends entirely on the
  requirements the application places on the network.

I wish we could give more guidance on how to make these decisions, but I
can't think of anything specific to say.

Section 7

I guess the [FRAG-ILE] discussion of reassembly errors at high data
rates are not applicable here, because "high data rate" and "low-power
and lossy network" do not go together?

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

Are we considering only Section 3.7 of [FRAG-ILE] for this discussion?
If so, a section-specific reference might help (but there are other
parts of [FRAG-ILE] that may be interesting/relevant, too.

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

[same comment as above regarding "underneath"]

  *  Overlapping fragment attacks are possible with 6LoWPAN fragments
      but there is no known firewall operation that would work on
      6LoWPAN fragments at the time of this writing, so the exposure is
      limited.  An implementation of a firewall SHOULD NOT forward
      fragments but recompose the IP packet, check it in the
      uncompressed form, and then forward it again as fragments if
      necessary.

This is implicit about how the checked version of the packet is the one
that gets refragmented and forwarded, but also does not say what the
firewall should do when it receives overlapping fragments, particularly
ones that disagree about the payload.  It seems worth remedying that.
Also, nit: s/but recompose/but instead should recompose/.

  *  Resource exhaustion attacks are certainly possible and a sensitive
      issue in a constrained network.  An attacker can perform a Denial-
      of-Service (DoS) attack on a node implementing VRB by generating a
      large number of bogus first fragments without sending subsequent
      fragments.  This causes the VRB table to fill up.  When hop-by-hop
      reassembly is used, the same attack can be more damaging if the
      node allocates a full datagram_size for each bogus first fragment.
      With the VRB, the attack can be performed remotely on all nodes
      along a path, but each node suffers a lesser hit.  This is because
      the VRB does not need to remember the full datagram as received so
      far but only possibly a few octets from the last fragment that
      could not fit in it.  An implementation MUST protect itself to
      keep the number of VRBs within capacity, and ensure that old VRBs
      are protected by a timer of a reasonable duration for the
      technology and destroyed upon timeout.

I think it would definitely be appropriate to mention that participants
in a 6LoWPAN network have authenticated to the network, and potentially
also the ability to blacklist misbehaving nodes.

  *  Attacks based on predictable fragment identification values are
      also possible but can be avoided.  The datagram_tag SHOULD be
      assigned pseudo-randomly in order to defeat such attacks.

I think it would be worth mentioning the size of the datagram_tag field
and the corresponding impact on the attacker's ability to succeed at
guessing it.

  *  Evasion of Network Intrusion Detection Systems (NIDS) leverages
      ambiguity in the reassembly of the fragment.  This is difficult
      and mostly useless in a 6LoWPAN network since the fragmentation is
      not end-to-end.

Perhaps add something about "and an NIDS is assumed to have sufficient
resources to be able to store and reassemble fragmented packets" and/or
"and NIDS are not often deployed within LLNs (as opposed to on an
adjacent backbone)" (though I have no hard data to support the latter
claim).

[Ballot comment]
Thank you for this easy to read document and the work to produce it.

Concur with Barry that [FRAG-ILE] and [LWIG-VRB] should be normative.

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

— Section 2.2 —

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

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

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

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

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

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

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

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

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

— Section 2.3 —

  This specification uses the following terms:

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

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

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

— Section 4 —

  4. Limits of Per-Hop Fragmentation and Reassembly

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

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

— Section 5 —

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

Make it “refrains”.

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

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

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

— Section 7 —

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

Capitalize “This”.

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

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

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

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

— Section 9 —

  Also many thanks to Georgies Papadopoulos

I believe it’s “Georgios”.

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

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

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6lo-minimal-fragment-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

(END IANA COMMENTS)

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

From: The IESG
To: IETF-Announce
CC: 6lo-chairs@ietf.org, draft-ietf-6lo-minimal-fragment@ietf.org, suresh@kaloom.com, 6lo@ietf.org, carlesgo@entel.upc.edu, Carles Gomez
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network) 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: - 'On
Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network'
  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-31. 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 document introduces the capability to forward 6LoWPAN fragments.
  This method reduces the latency and increases end-to-end reliability
  in route-over forwarding.  It is the companion to using virtual
  reassembly buffers which is a pure implementation technique.




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

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


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-lwig-6lowpan-virtual-reassembly: Virtual reassembly buffers in 6LoWPAN (None - IETF stream)

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.
This is the proper type of RFC because the document mandates protocol behavior for a fragment forwarding technique that avoids per-hop reassembly in 6LoWPAN multihop networks. (In addition, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks.) 

(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 introduces the capability to forward 6LoWPAN fragments.
  This method reduces the latency and increases end-to-end reliability
  in route-over forwarding.  It is the companion to using virtual
  reassembly buffers which is a pure implementation technique.

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:

The topic of fragmentation attracted increased interest from participants at the 6lo working group 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. The present document is the second one. This decision had good consensus, and the present document was created and has progressed with no controversy. Only after the review of -04 by the INTDIR assigned reviewer (Dave Thaler), and subsequent discussion with the authors, it has become clear that some content of the document had to mandate protocol behavior, thus the Intended Status of Proposed Standard.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
There exist implementations of the fragment forwarding technique that avoids per-hop reassembly.


  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:
Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel carried out deep reviews. The last two were carried out during WGLC, and the comments were addressed in draft-ietf-6lo-minimal-fragment-02. Dave Thaler reviewed -04, on behalf of the INTDIR, and subsequent discussion with the authors led to adding normative text to the document and changing its intended status from Informational to Proposed Standard.

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:
The shepherd initially reviewed revision -02 of the document. A few suggestions were made and the document was updated in -03 (e.g. using “6LoWPAN” instead of “LLN”, use of the term “minimal” was removed from the text, etc.). Subsequently, a WG participant made questions that led to -04, and the INTDIR review led to revisions -05 and -06. A further shepherd comment led to -07 (on the need to include a reference to RFC 2119, and a related section). In the shepherd’s 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), Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel carried out comprehensive reviews of the draft. These reviewers have a background in 6TiSCH, where the topic of the document is of interest.



(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: All document authors have confirmed that they are unaware of any IPR that applies to 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: There is one "error" (the VRB informational draft, which is normative for this document) and one comment indicated by the idnits tool. The relevant details from the idnits tool output follow:

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.
  ** Downref: Normative reference to an Informational draft:
    draft-ietf-lwig-6lowpan-virtual-reassembly (ref. 'LWIG-VRB')
    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

(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: the two normative references that are not yet published as RFCs (draft-ietf-lwig-6lowpan-virtual-reassembly-01 and draft-ietf-6lo-fragment-
              recovery-07) are ready for advancement.

(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, draft-ietf-lwig-6lowpan-virtual-reassembly-01 is an informational document that is included in this document as a normative reference.

(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 does not change the status of any existing RFC.


(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 contains no IANA requests.

(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.
This is the proper type of RFC because the document mandates protocol behavior for a fragment forwarding technique that avoids per-hop reassembly in 6LoWPAN multihop networks. (In addition, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks.) 

(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 gives an overview of LLN Minimal Fragment Forwarding.
  When employing adaptation layer fragmentation in 6LoWPAN, it may be
  beneficial for a forwarder not to have to reassemble each packet in
  its entirety before forwarding it. This has always been possible
  with the original fragmentation design of RFC4944. This document is
  a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly],
  which details the virtual Reassembly Buffer (VRB) implementation
  technique which reduces the latency and increases end-to-end
  reliability in route-over forwarding.

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:

The topic of fragmentation attracted increased interest from participants at the 6lo working group 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. The present document is the second one. This decision had good consensus, and the present document was created and has progressed with no controversy. Only after the review of -04 by the INTDIR assigned reviewer (Dave Thaler), and subsequent discussion with the authors, it has become clear that some content of the document had to mandate protocol behavior, thus the Intended Status of Proposed Standard.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
There exist implementations of the fragment forwarding technique that avoids per-hop reassembly.


  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:
Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel carried out deep reviews. The last two were carried out during WGLC, and the comments were addressed in draft-ietf-6lo-minimal-fragment-02. Dave Thaler reviewed -04, on behalf of the INTDIR, and subsequent discussion with the authors led to adding normative text to the document and changing its intended status from Informational to Proposed Standard.

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:
The shepherd reviewed revision -02 of the document. A few suggestions were made and the document was updated in -03 (e.g. using “6LoWPAN” instead of “LLN”, use of the term “minimal” was removed from the text, etc.). Subsequently, a WG participant made questions that led to -04, and the INTDIR review led to revisions -05 and -06. In the shepherd’s 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), Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel carried out comprehensive reviews of the draft. These reviewers have a background in 6TiSCH, where the topic of the document is of interest.



(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: All document authors have confirmed that they are unaware of any IPR that applies to 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: There are no errors or flaws. There are minor warnings and comments from the idnits tool. The relevant details from the idnits tool output follow:

  -- The document date (August 30, 2019) is 55 days in the past.  Is this
    intentional?
  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.
  == Outdated reference: A later version (-07) exists of
    draft-ietf-6lo-fragment-recovery-05

    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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.
(In fact, all references are categorized as “Informative references”.)

(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: There are no downward normative 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 does not change the status of any existing RFC.


(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 contains no IANA requests.

(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:  Informational.
This is the proper type of RFC because the document does not define new protocol behavior. Rather, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks. 

(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 gives an overview of LLN Minimal Fragment Forwarding.
  When employing adaptation layer fragmentation in 6LoWPAN, it may be
  beneficial for a forwarder not to have to reassemble each packet in
  its entirety before forwarding it. This has always been possible
  with the original fragmentation design of RFC4944. This document is
  a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly],
  which details the virtual Reassembly Buffer (VRB) implementation
  technique which reduces the latency and increases end-to-end
  reliability in route-over forwarding.

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:

The topic of fragmentation attracted increased interest from participants at the 6lo working group 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. The present document is the second one. This decision had good consensus, and the present document was created and has progressed with no controversy.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
The document does not actually specify a protocol. Rather, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks.


  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:
Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel carried out deep reviews. The last two were carried out during WGLC, and the comments were addressed in draft-ietf-6lo-minimal-fragment-02.

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:
The shepherd reviewed revision -02 of the document. A few suggestions were made and the document was updated in -03 (e.g. using “6LoWPAN” instead of “LLN”, use of the term “minimal” was removed from the text, etc.). Subsequently, a WG participant made questions that led to -04. In the shepherd’s 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), Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel performed comprehensive reviews of recent versions of the draft. These reviewers have a background in 6TiSCH, where the topic of the document is of interest.



(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: All document authors have confirmed that they are unaware of any IPR that applies to 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: There are no errors or flaws. There are minor warnings and comments from the idnits tool. The relevant details from the idnits tool output follow:

  -- The document date (August 30, 2019) is 55 days in the past.  Is this
    intentional?
  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.
  == Outdated reference: A later version (-07) exists of
    draft-ietf-6lo-fragment-recovery-05

    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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.
(In fact, all references are categorized as “Informative references”.)

(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: There are no downward normative 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 does not change the status of any existing RFC.


(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 contains no IANA requests.

(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:  Informational.
This is the proper type of RFC because the document does not define new protocol behavior. Rather, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks. 

(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 gives an overview of LLN Minimal Fragment Forwarding.
  When employing adaptation layer fragmentation in 6LoWPAN, it may be
  beneficial for a forwarder not to have to reassemble each packet in
  its entirety before forwarding it. This has always been possible
  with the original fragmentation design of RFC4944. This document is
  a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly],
  which details the virtual Reassembly Buffer (VRB) implementation
  technique which reduces the latency and increases end-to-end
  reliability in route-over forwarding.

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:

The topic of fragmentation attracted increased interest from participants at the 6lo working group 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. The present document is the second one. This decision had good consensus, and the present document was created and has progressed with no controversy.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
The document does not actually specify a protocol. Rather, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks.


  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:
Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel carried out deep reviews. The last two were carried out during WGLC, and the comments were addressed in draft-ietf-6lo-minimal-fragment-02.

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:
The shepherd reviewed revision -02 of the document. A few suggestions were made and the document was updated in -03 (e.g. using “6LoWPAN” instead of “LLN”, use of the term “minimal” was removed from the text, etc.). Subsequently, a WG participant made questions that led to -04. In the shepherd’s 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), Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel performed comprehensive reviews of recent versions of the draft. These reviewers have a background in 6TiSCH, where the topic of the document is of interest.



(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: All document authors have confirmed that they are unaware of any IPR that applies to 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: There are no errors or flaws. There are minor warnings and comments from the idnits tool. The relevant details from the idnits tool output follow:

  -- The document date (August 30, 2019) is 55 days in the past.  Is this
    intentional?
  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.
  == Outdated reference: A later version (-07) exists of
    draft-ietf-6lo-fragment-recovery-05

    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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.
(In fact, all references are categorized as “Informative references”.)

(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: There are no downward normative 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 does not change the status of any existing RFC.


(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 contains no IANA requests.

(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:  Informational.
This is the proper type of RFC because the document does not define new protocol behavior. Rather, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks. 

(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 gives an overview of LLN Minimal Fragment Forwarding.
  When employing adaptation layer fragmentation in 6LoWPAN, it may be
  beneficial for a forwarder not to have to reassemble each packet in
  its entirety before forwarding it. This has always been possible
  with the original fragmentation design of RFC4944. This document is
  a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly],
  which details the virtual Reassembly Buffer (VRB) implementation
  technique which reduces the latency and increases end-to-end
  reliability in route-over forwarding.

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:

The topic of fragmentation attracted increased interest from participants at the 6lo working group 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. The present document is the second one. This decision had good consensus, and the present document was created and has progressed with no controversy.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
SHEPHERD RESPONSE:
The document does not actually specify a protocol. Rather, it provides an overview of the benefits and limitations of two approaches for fragment forwarding in 6LoWPAN multihop networks.


  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:
Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel carried out deep reviews. The last two were carried out during WGLC, and the comments were addressed in draft-ietf-6lo-minimal-fragment-02.

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:
The shepherd reviewed revision -02 of the document. A few suggestions were made and the document was updated in -03 (e.g. using “6LoWPAN” instead of “LLN”, use of the term “minimal” was removed from the text, etc.). Subsequently, a WG participant made questions that led to -04. In the shepherd’s 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), Yasuyuki Tanaka, Georgios Papadopoulos and Dominique Barthel performed comprehensive reviews of recent versions of the draft. These reviewers have a background in 6TiSCH, where the topic of the document is of interest.



(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: All document authors have confirmed that they are unaware of any IPR that applies to 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: There are no errors or flaws. There are minor warnings and comments from the idnits tool. The relevant details from the idnits tool output follow:

  -- The document date (August 30, 2019) is 55 days in the past.  Is this
    intentional?
  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.
  == Outdated reference: A later version (-07) exists of
    draft-ietf-6lo-fragment-recovery-05

    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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.
(In fact, all references are categorized as “Informative references”.)

(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: There are no downward normative 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 does not change the status of any existing RFC.


(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 contains no IANA requests.

(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.




(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?

(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:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

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?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? 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? 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?

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

(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.

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



(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.

(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.

(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.

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

(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? 

(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.)

(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.

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

(13) Have all references within this document been identified as
either normative or informative?

(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?

(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.

(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.


(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 8126).

(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.

(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.