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

[Mirja Kuehlewind <[e-mail]>]

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!

Mirja



> 
> Regards,
> 
> Pascal
> 
>> Le 7 août 2019 à 19:04, Mirja Kuehlewind <[e-mail]> a écrit :
>> 
>> Hi Pascal,
>> 
>> The document status (informational) and the kind of references used are completely independent of each other. A normative reference is a reference that need to be considered in order to fully understand the document (or fully implement a spec in case of PS). For me it seems that many drafts that are currently listed as informative fall into that category. 
>> 
>> If you have a normative reference to a draft that also means that this document will be published together with that draft and therefore will “wait” for this draft in the RFC editor queue. That also gives the authors the chance to double-check these dependencies before final publication (to make sure the referenced draft content still fits to the content in your document).
>> 
>> If you have an informative reference to a draft, that reference will always point to the draft version indicated. That can be fine as well but then there should be no dependencies to the detailed content of final version of the referenced draft.
>> 
>> As I said I’m not the person to make a final judgement call here, but your reply below indicates to me that the concept of informative vs. normative was not considered correctly and needs to be double-checked.
>> 
>> Mirja
>> 
>> 
>>> On 7. Aug 2019, at 18:50, Pascal Thubert (pthubert) <[e-mail]> wrote:
>>> 
>>> 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 <[e-mail]> 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.
>>>> 
>>>> 
>>