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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 08:48:00 -0700

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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Aug 2019 16:50:34 +0000

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 <[email-masked]> a écrit :
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Aug 2019 19:03:41 +0200

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) <[email-masked]> wrote:
> 
> Hello Mirja
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Aug 2019 18:31:39 +0000

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?

Regards,

Pascal

> Le 7 août 2019 à 19:04, Mirja Kuehlewind <[email-masked]> a écrit :
> 
> Hi Pascal,
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 8 Aug 2019 12:29:08 +0200

Hi Pascal,

See below.

> On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Mirja
> 

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 8 Aug 2019 10:00:49 -0400

Hi Mirja,

On Thu, Aug 8, 2019, 6:29 AM Mirja Kuehlewind <[email-masked]> wrote:

> > 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Aug 2019 16:05:18 +0000

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 <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Mirja,

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

See below.

> On 7. Aug 2019, at 20:31, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hello Mirja
>

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 8 Aug 2019 18:16:04 +0200

See below.

> On 8. Aug 2019, at 18:05, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Suresh and Mirja 
> 

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

> Le 8 août 2019 à 16:01, Suresh Krishnan <[email-masked]> a écrit :
> 
>> Hi Mirja, 
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 Aug 2019 16:06:13 +0000

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-masked]>
> Sent: jeudi 8 août 2019 18:16
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Suresh Krishnan <[email-masked]>; Shwetha Bhandari
> <[email-masked]>; [email-masked]; [email-masked]; The
> IESG <[email-masked]>; [email-masked]
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with
> DISCUSS and COMMENT)
> 
> See below.
> 
> > 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
> >
> >> > 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.
> >> >
> the other specs playing at a different level and not needed for understanding
> things at Architecture level.
> >> >
> drafts. That would help the reader. But then there are many solution draft and
> we could keep building new ones forever.
> >> >
> 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.
> >>
> >> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 21 Aug 2019 09:34:32 +0000

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.

Please let me know if that matches the need that you identified,

Pascal

> From: Pascal Thubert (pthubert)
> Sent: mardi 20 août 2019 18:06
> To: Mirja Kuehlewind <[email-masked]>
> Subject: RE: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with
> DISCUSS and COMMENT)
> 
> Back from vacations : )
> 
> 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
> 
> > <[email-masked]>; [email-masked]; [email-masked];
> > The IESG <[email-masked]>; [email-masked]
> > 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-masked]>
> > wrote:
> > >
> > > Hello Suresh and Mirja
> > >
> > 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
> >
> >
> > >
> > 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-masked]>
> > > a
> > écrit :
> > >
> > >> Hi Mirja,
> > >>
> > >> > It certainly does not hurt to have a second look at how the split
> > >> > was done
> > and why.
> > >> >
> > 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.
> > >> >
> > drafts. That would help the reader. But then there are many solution
> > draft and we could keep building new ones forever.
> > >> >
> > Architecture impact with per packet l’avales and stuff we had to
> > explain it. Did we go too far into explaining the solution?
> > >>
> > However, as I said, I didn’t read the document in depth and therefore
> > can’t give strong advise.
> > >>
> > with the current approach, I’m happy to clear my discuss. Mainly
> > wanted to double-check!
> > >>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 21 Aug 2019 11:59:31 +0200

Hi Pascal,

Thanks for doing this pass. Please see below.

> On 21. Aug 2019, at 11:34, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello again Mirja:
> 

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 21 Aug 2019 10:11:13 +0000

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-masked]>
Envoyé le :mercredi 21 août 2019 11:59
À : Pascal Thubert (pthubert)<mailto:[email-masked]>
Cc : Suresh Krishnan<mailto:[email-masked]>; Shwetha Bhandari<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet :Re: Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

Hi Pascal,

Mirja