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

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:
> 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"
> <roll-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:
> 
>> 
>> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll