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 protected]> > wrote: > > 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 protected]> > Sent: mardi 26 novembre 2019 18:41 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: [email protected] > 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 protected]> >> Sent: mercredi 4 mars 2020 13:41 >> To: Pascal Thubert (pthubert) <[email protected]> >> Cc: The IESG <[email protected]>; Benjamin Kaduk <[email protected]>; draft-ietf- >> [email protected]; Carles Gomez <[email protected]>; 6lo- >> [email protected]; [email protected] >> 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 >> >> >> >>> On 4. Mar 2020, at 13:25, Pascal Thubert (pthubert) <[email protected]> >> wrote: >>> >>> 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 > > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
