Back from vacations : ) I think I see your point Mirja. What we tried to do here is build a self-sufficient document at the architecture level. The specs referenced (exception from DetNet and those which have both Architecture and specification content such as IPv6) are pointed because they implement the architecture, but reading them should not be necessary to understand the words in the architecture. I'll need a full pass to check if we did that right.
All the best, Pascal > -----Original Message----- > From: Mirja Kuehlewind <[email protected]> > Sent: jeudi 8 août 2019 18:16 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: Suresh Krishnan <[email protected]>; Shwetha Bhandari > <[email protected]>; [email protected]; [email protected]; The > IESG <[email protected]>; [email protected] > Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: > (with > DISCUSS and COMMENT) > > See below. > > > On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert) <[email protected]> > wrote: > > > > 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? > > Let me give you a simple example. An informational document that describes > operational practice for protocol X, needs to have the reference to the spec > describing protocol X as a normative reference because if you don’t know > anything about the protocol X, you will not be able to understand the > operational guidance given. > > This is an easy example and I know that there are many cases where this is > less > clear, however, it can definitely make sense to have normative references in > informational document because it solely indicated which other documents are > a MUST read in order to understand this document. > > Mirja > > > > > > 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]> a > écrit : > > > >> Hi Mirja, > >> > >> On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind <[email protected]> > wrote: > >> 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! > >> > >> 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
