Hello Suresh and Mirja I’m happy to get recommendations on that topic. I understand Mirja’s recommendation on how to use normative refs; it makes sense, more so for std track. For informational, I’m still puzzled: Why call something normative in a document that is not establishing a standard?
On the topic of refinement section 4 goes clearly deeper down than section 3. This is by design. We did not want to split and have to maintain and keep in sync 2 documents. Also we got hints from you guys that overloading the IESG with many small documents was not the right way. Regards, Pascal Le 8 août 2019 à 16:01, Suresh Krishnan <[email protected]<mailto:[email protected]>> a écrit : Hi Mirja, On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind <[email protected]<mailto:[email protected]>> wrote: Hi Pascal, See below. > On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert) > <[email protected]<mailto:[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! I was fine with the current approach to references but I do see your point. I will try to see if I can propose something to simplify this. Thanks Suresh
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
