Subject: Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-minimal-fragment-12: (with COMMENT)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Mar 2020 12:25:06 +0000

Dear Mirja (and Ben),

Many thanks for reviewing this document!
 
> ----------------------------------------------------------------------
> 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.

This was long debated and went back and forth. We finally settled for STD track after the review by Dave Thaler.
There's actually generic normative text in this document, in the forwarding fragments section. 
Any spec that provides a fragment forwarding technique should normatively refer this and abide by that text.

As an example, but there's more:
"
  Since the datagram_tag is uniquely associated to the source Link-
   Layer address of the fragment, the forwarding node MUST assign a new
   datagram_tag from its own namespace for the next hop and rewrite the
   fragment header of each fragment with that datagram_tag.

   When a forwarding node receives a fragment other than a first
   fragment, it MUST look up state based on the source Link-Layer
   address and the datagram_tag in the received fragment.  If no such
   state is found, the fragment MUST be dropped; otherwise the fragment
   MUST be forwarded using the information in the state found.
"

This is why we ended up with STD track. You found reviewing https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery that there's already a std track with a normative reference to this.

Many thanks again!

Pascal

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 4 Mar 2020 13:40:57 +0100

Hi Pascal,

Informational documents can also have normative text. If that was the criteria the decision was made on, the decisions should be re-evaluated.

Mirja

> On 4. Mar 2020, at 13:25, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Dear Mirja (and Ben),
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Mar 2020 12:56:21 +0000

Hello again Mirja

The decision was made in Singapore at the 6lo working group with Suresh.

The minutes are at https://datatracker.ietf.org/doc/minutes-106-6lo/ 
I extracted the below for you:

"
[13:42]
  INTDIR review of 6LoWPAN fragment forwarding                       Pascal
  Thubert                  10 min
    https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-04
https://datatracker.ietf.org/meeting/106/materials/slides-106-6lo-6lo-fragmentation-00
  minimal-fragment and fragment-recovery drafts. Passed WG LC.
  Pascal goes over Dave Thaler's review. Discussion about is the draft
  normative.
   Text introduces behaviour with uppercase that is generic to any FF solution,
   be it VRB or recovereable fragments. Also discusses pitfalls such as found
   with Rahul's experiments. No more a simple description of the Virtual
   Reassembly Buffer technique.
  Suresh: I think its normative.
  Pascal: will add BCP14 text.
  Another comment is hitting Hop Limit while fragmented, how is it reported to
  the source, which source? If send ICMP packet to origin source with
  reconstructed packet, loose all info on cause for the problem (if pb occurred
  with fragments). Should 6lo, independent from this work, document ICMP
  handling behaviour in hc scenarios? Discussion on what proper response should
  be to the situation described.

"
All in all the main point was that it is not an article on VRB but a specification on a "mpls like" forwarding technique.

Also please find below the message that triggered the change:

"

All the best

Pascal

-----Original Message-----
From: Carles Gomez Montenegro <[email-masked]> 
Sent: mardi 26 novembre 2019 18:41
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Re: minimal fragments

Dear Pascal,

Yes, based on Suresh's comments during the 6lo session in Singapore, it is our understanding that the Intended Status for the "minimal" draft needs to be "Standards Track".

Thanks for your hard work!

Shwetha and Carles

> Dear chairs
>
> I think we concluded that with the changes I made for Dave Thaler's 
> review the doc should now be std track.
> I published the changes in question in 05, together with a new 
> security section based on Ines' IOT-DIR review; please let me know if 
> I should move the track to std as well.
>
> All the best
>
> Pascal

"

That's all the history that I could find. Having been through that change and again, I'm not inclined to reopen.
But I'm willing to learn. Where exactly do you place the bar?

All the best

Pascal

> -----Original Message-----
> From: Mirja Kuehlewind <[email-masked]>
> Sent: mercredi 4 mars 2020 13:41
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: The IESG <[email-masked]>; Benjamin Kaduk <[email-masked]>; draft-ietf-
> [email-masked]; Carles Gomez <[email-masked]>; 6lo-
> [email-masked]; [email-masked]
> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-6lo-minimal-
> fragment-12: (with COMMENT)
> 
> Hi Pascal,
> 
> Informational documents can also have normative text. If that was the criteria
> the decision was made on, the decisions should be re-evaluated.
> 
> Mirja
> 
> 
> 
> >> 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.
> >
> > This is why we ended up with STD track. You found reviewing
> https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery that there's
> already a std track with a normative reference to this.
> >
> > Many thanks again!
> >
> > Pascal

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 4 Mar 2020 14:03:27 +0100

Hi Pascal,

Again, yes, you can have normative text in information documents. In the minutes below the group concluded correctly, as also mentioned by Suresh, that the respective text should be normative. However, that does not automatically mean that this document has to be PS.

In any case this is a decision for Suresh to make and I just provided my input.

Mirja

> On 4. Mar 2020, at 13:56, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello again Mirja
>