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
