I agree, Mirja; By default I’ll move the most comprehensive list to the normative section and from there will wait for Suresh to propose an update if he thinks a correction is needed.
Many thanks for your patience : ) Pascal De : Mirja Kuehlewind<mailto:[email protected]> Envoyé le :mercredi 21 août 2019 11:59 À : Pascal Thubert (pthubert)<mailto:[email protected]> Cc : Suresh Krishnan<mailto:[email protected]>; Shwetha Bhandari<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; The IESG<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet :Re: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT) Hi Pascal, Thanks for doing this pass. Please see below. > On 21. Aug 2019, at 11:34, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Hello again Mirja: > > I made the pass. On the one hand one could say that as expected the text is > readable as is, and that the references are complement of information on the > detailed howto. > I found exceptions that really need to be moved anyway per your description > of normative: > > > <?rfc include='reference.I-D.ietf-6tisch-minimal-security'?> > <?rfc include='reference.I-D.ietf-6lo-backbone-router'?> > <?rfc include='reference.I-D.ietf-roll-useofrplinfo'?> > <?rfc include='reference.I-D.ietf-roll-unaware-leaves'?> > > Another extreme view would say that the reading is only complete if some of > the drafts are read as well. Taking that other extreme view and adding it all > together I obtained the following list: > > <?rfc include='reference.I-D.ietf-detnet-architecture'?> > <?rfc include='reference.I-D.ietf-6tisch-minimal-security'?> > <?rfc include='reference.I-D.ietf-6lo-backbone-router'?> > <?rfc include='reference.I-D.ietf-6lo-fragment-recovery'?> > <?rfc include='reference.I-D.ietf-6lo-minimal-fragment'?> > <?rfc include='reference.I-D.ietf-6lo-ap-nd'?> > <?rfc include='reference.I-D.ietf-roll-useofrplinfo'?> > <?rfc include='reference.I-D.ietf-roll-unaware-leaves'?> > <?rfc include='reference.I-D.ietf-6tisch-enrollment-enhanced-beacon'?> > <?rfc include='reference.I-D.ietf-6tisch-msf'?> > > These are the document that really give a comprehensive picture of the RPL > network. I'm OK to move them in the normative reference section. That will > certainly delay the shipping of the RFC for the architecture, but that will > allow us to validate at the last minute that the architecture is still a > correct reflection of what those drafts specify. I personally think that having this ability to check at the end is a plus, however, as I’m not the expert here, so I will reply on Suresh making a final call. Mirja > > Please let me know if that matches the need that you identified, > > Pascal > >> -----Original Message----- >> From: Pascal Thubert (pthubert) >> Sent: mardi 20 août 2019 18:06 >> To: Mirja Kuehlewind <[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) >> >> 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
