Subject: [Roll] re-organizing use-of-rplinfo document: worth the typing?

From: Michael Richardson <[email-masked]>
Date: Wed, 10 May 2017 12:24:52 -0400

It has been suggested that in draft-ietf-roll-useofrplinfo-14 that we change
the presentation of the use cases.  That instead of having 12 storing and
then 12 non-storing cases, that we instead have 12 cases, and within each
discuss the non-storing and storing subcases.

Doing this involves moving a lot of text around, so before we do this, we'd
like to get some rough consensus that this would be a better presentation.

Do we need to do the run-through of the Berlin IETF96 slides again at the
Prague meeting?
       https://docs.google.com/presentation/d/1zdjzlLo-gWa1DEug3zQ7aMqWJ3PDM4Hajt-uAOexynA/edit?usp=sharing
       https://docs.google.com/presentation/d/1zdjzlLo-gWa1DEug3zQ7aMqWJ3PDM4Hajt-uAOexynA/pub?start=false&loop=false&delayms=60000
       http://www.sandelman.ca/SSW/ietf/roll/useofrplinfo/ietf96-slides-v1.pdf

Given that 2460bis has not given us the desired collapse of the HbH option
type as we thought would happen,  upon the advice of reviewers and Area
Director(s), useofrplinfo will be revised to update RFC6553 to change the HbH
type code.  Let us get that text ready, and so the WG can react better.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Don Sturek <[email-masked]>
Date: Wed, 10 May 2017 09:38:27 -0700

Hi Michael,

I think implementers will use either one of storing or non-storing.  At
least for me, having a dedicated section describing the specific method of
operation is useful (versus having to read through and skip over the MOP
not in use).

Plus it saves you having to edit the current draft!

Don Sturek

On 5/10/17, 9:24 AM, "Roll on behalf of Michael Richardson"
<[email-masked] on behalf of [email-masked]> wrote:

>https://docs.google.com/presentation/d/1zdjzlLo-gWa1DEug3zQ7aMqWJ3PDM4Hajt
>-uAOexynA/pub?start=false&loop=false&delayms=60000
>       
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Thu, 11 May 2017 09:52:14 +0200

Hi Michael,

I got the clear impression that the draft needs thorough re-writing 
anyway.
That being the case and noticing that reviewers have problems to get to 
the end of the document, I wanted to suggest the following re-ordering.
One use-case which describes the longest trajectory from outside, to 
inside, and outside the RPL LAN, decomposed in parts, say, a,b,c,d
All the other use cases just tables with their composition of parts in 
the wanted order.

If you want to separate in storing and non-storing is less a concern to 
me.

If that does not augment readability (size) and significantly increases 
the rewrite, then don't bother.

Peter

Don Sturek schreef op 2017-05-10 18:38:
>> -uAOexynA/edit?usp=sharing
>> 
>> Director(s), useofrplinfo will be revised to update RFC6553 to change 
>> the
>> HbH

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 May 2017 08:31:52 -0400

> I think implementers will use either one of storing or non-storing.  At

Yes, that's true.
I'm more concerned for reviewers in some ways.

    > least for me, having a dedicated section describing the specific method
    > of operation is useful (versus having to read through and skip over the
    > MOP not in use).

    > Plus it saves you having to edit the current draft!

Agreed.

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 12 May 2017 11:48:04 +0530

As someone who had previously reviewed the draft, I can say it is not an easy going with reviewing the draft. But i didn't had any suggestions on improving the readability then.

The proposal to modify it to put 12 cases with storing, non storing section in each case sounds good to me... It will also reduce some repeatative text put in context to explaining the scenario of the case. Also the tabular view for header changes is also repeatative in some case (raf to root flow for e.g.). Not sure if the table view for header manipulation for storing, non storing be merged easily for all cases with good readability.

Regards,
Rahul

> On 11-May-2017, at 6:01 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Ines Robles <[email-masked]>
Date: Fri, 12 May 2017 09:08:35 -0300

Thank you very much for all your comments,

We are working  to improve the readability.

Cheers,

Ines.

2017-05-12 3:18 GMT-03:00 Rahul Jadhav <[email-masked]>:

>
> As someone who had previously reviewed the draft, I can say it is not an
> easy going with reviewing the draft. But i didn't had any suggestions on
> improving the readability then.
>
> The proposal to modify it to put 12 cases with storing, non storing
> section in each case sounds good to me... It will also reduce some
> repeatative text put in context to explaining the scenario of the case.
> Also the tabular view for header changes is also repeatative in some case
> (raf to root flow for e.g.). Not sure if the table view for header
> manipulation for storing, non storing be merged easily for all cases with
> good readability.
>
> Regards,
> Rahul
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 May 2017 09:21:21 -0400

Rahul Jadhav <[email-masked]> wrote:
    > case. Also the tabular view for header changes is also repeatative in
    > some case (raf to root flow for e.g.). Not sure if the table view for
    > header manipulation for storing, non storing be merged easily for all
    > cases with good readability.

The tables are hard to maintain/update.
Should we even keep them?
on the other hand, they are already done.