Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Pascal,

Thanks for doing this pass. Please see below.

> On 21. Aug 2019, at 11:34, Pascal Thubert (pthubert) <[e-mail]> 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 <[e-mail]>
>> Cc: Suresh Krishnan <[e-mail]>; Shwetha Bhandari
>> <[e-mail]>; [e-mail]; [e-mail]; The
>> IESG <[e-mail]>; [e-mail]
>> 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 <[e-mail]>
>>> Sent: jeudi 8 août 2019 18:16
>>> To: Pascal Thubert (pthubert) <[e-mail]>
>>> Cc: Suresh Krishnan <[e-mail]>; Shwetha Bhandari
>>> <[e-mail]>; [e-mail]; [e-mail];
>>> The IESG <[e-mail]>; [e-mail]
>>> 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)
>>>> <[e-mail]>
>>> 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 <[e-mail]>
>>>> a
>>> écrit :
>>>> 
>>>>> Hi Mirja,
>>>>> 
>>>>> On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind <[e-mail]>
>>> wrote:
>>>>> Hi Pascal,
>>>>> 
>>>>> See below.
>>>>> 
>>>>>> On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert)
>>> <[e-mail]> 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
>