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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> a écrit :

Hi Mirja,

On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:
Hi Pascal,

See below.

> On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert) <[e-mail]<mailto:[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