Hi Pascal, See below.
> On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Hello Mirja > > It certainly does not hurt to have a second look at how the split was done > and why. > > With one exception - the DetNet Architecture - the references fall in the > category of solutions which is a level below this spec in the design cascade. > > They explain how things are done when this spec tries to limit at what gets > done and tries to be complete at it. We can point on the solution specs > because we only publish once the work is mostly done as opposed to a as a > preamble to the work like in the case of DetNet. Then again that was a > conscious decision be the group which is more of an integrator than a creator. > > From that perspective only the DetNet Architecture would be normative, the > other specs playing at a different level and not needed for understanding > things at Architecture level. > > OTOH it would be grand for this spec to reference RFCs as opposed to drafts. > That would help the reader. But then there are many solution draft and we > could keep building new ones forever. > > I’m unsure what you mean by strongly wrt the fragment drafts. They have a > purpose and the Architecture describes that purpose. Since it has an > Architecture impact with per packet l’avales and stuff we had to explain it. > Did we go too far into explaining the solution? Yes, I had the feeling that is went too much into details a couple of times. However, as I said, I didn’t read the document in depth and therefore can’t give strong advise. @Suresh: Can you maybe have another look at the reference. If you are okay with the current approach, I’m happy to clear my discuss. Mainly wanted to double-check! Mirja > > Regards, > > Pascal > >> Le 7 août 2019 à 19:04, Mirja Kuehlewind <[email protected]> a écrit : >> >> Hi Pascal, >> >> The document status (informational) and the kind of references used are >> completely independent of each other. A normative reference is a reference >> that need to be considered in order to fully understand the document (or >> fully implement a spec in case of PS). For me it seems that many drafts that >> are currently listed as informative fall into that category. >> >> If you have a normative reference to a draft that also means that this >> document will be published together with that draft and therefore will >> “wait” for this draft in the RFC editor queue. That also gives the authors >> the chance to double-check these dependencies before final publication (to >> make sure the referenced draft content still fits to the content in your >> document). >> >> If you have an informative reference to a draft, that reference will always >> point to the draft version indicated. That can be fine as well but then >> there should be no dependencies to the detailed content of final version of >> the referenced draft. >> >> As I said I’m not the person to make a final judgement call here, but your >> reply below indicates to me that the concept of informative vs. normative >> was not considered correctly and needs to be double-checked. >> >> Mirja >> >> >>> On 7. Aug 2019, at 18:50, Pascal Thubert (pthubert) <[email protected]> >>> wrote: >>> >>> Hello Mirja >>> >>> Your time is appreciated, many thanks for considering this draft. >>> >>> The 6TiSCH Architecture has been a WIZp throughout the lifespan of the WG. >>> It may be seen as its main product, most of the needed components being >>> requested from other WGs. >>> >>> This may be unusual but that was the plan from the start: produce a rather >>> generic iot stack out of IETF components, which when we started were full >>> of gaps and overlaps. >>> >>> 5 years later we have open source implementations that went through >>> multiple interop tests, all under the group’s monitoring. >>> >>> So the Architecture is not there to tell us what to do next but rather how >>> what we (many iot relater WGs) built and how it works together. >>> >>> The decision to go for informational is not mine. But what’s the point to >>> have normative References in an informational draft? >>> >>> Again, many thanks. >>> >>> Pascal >>> >>>> Le 7 août 2019 à 17:48, Mirja Kühlewind via Datatracker <[email protected]> >>>> a écrit : >>>> >>>> Mirja Kühlewind has entered the following ballot position for >>>> draft-ietf-6tisch-architecture-24: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> I only had a quick read of this document, however, it seems to me that >>>> there >>>> are strong dependencies on a whole bunch of drafts, that are only listed as >>>> informational. I don't have a deep enough understanding to make a final >>>> judgement of which draft would need to be listed as normative references, >>>> however, I wanted to raise this point on the discuss level in order to >>>> ensure >>>> that this is considered before publication. >>>> >>>> To give an example: Section 4.6.3 goes quite seep into details of what's >>>> described in [I-D.ietf-6lo-fragment-recovery]. However as long as >>>> [I-D.ietf-6lo-fragment-recovery] is not published yet, the 6tisch arch >>>> should >>>> probably not rely on the content of this draft that strongly. Putting >>>> [I-D.ietf-6lo-fragment-recovery] as a normative reference ensures that this >>>> draft will not be published before [I-D.ietf-6lo-fragment-recovery]. >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> As I said, I only had a rather brief read, however, I had a bit of >>>> problems to >>>> follow exactly which parts of the architecture rely on existing protocols >>>> and >>>> mechanisms and where 6tsch actually needs to define new approaches. Maybe a >>>> short, even higher-level overview than section 3, could address this and >>>> help >>>> the reader. >>>> >>>> >> _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
