Re: [Int-dir] Review of draft-ietf-roll-routing-dispatch-01

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

Thanks a bunch Bernie !!!

I applied most of your recommendations as is, more below, and posted https://tools.ietf.org/html/draft-ietf-roll-routing-dispatch-02

Some of the odd characters come from the experimentation of using Kramdown. Kramdown made the writing easier but the maintenance more cumbersome, and I made these weird typos with # signs in them as after effects.

Take care,

Pascal

From: Bernie Volz (volz)
Sent: mercredi 19 octobre 2016 04:10
To: <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Review of draft-ietf-roll-routing-dispatch-01

Hi:

I am an assigned INT directorate reviewer for draft-ietf-roll-routing-dispatch-01. These comments were written primarily for the benefit of the Internet
Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

This document seems to have required reading many other documents about 6LoWPAN which sadly I did not have time to do. So, my comment may reflect a narrow understanding of the technology. Most of my comments are fairly minor in nature to clean up the document (which the RFC-Editor would no doubt do a far better job at then my limited comments).

I did NOT find anything that would be show stopper for this document.


1.      Please check the use of LOWPAN_IPHC and LoWPAN_IPHC. Probably they should all be the same case? And there is a mix of underscore and hyphen (LOWPAN-IPHC)? Should one format be used throughout? Also, in section 7 just "IPHC" is used.

[Pascal Thubert (pthubert)] done, all moved to LOWPAN_IPHC per RFC 6282 format. For 6LoRH we used hyphen. Should we go to underscore?


2.       Standardize the way in which RFC titles are referenced. Section 1 uses just the title, the title in square brackets and another part of the document uses single quotes around the name.
[Pascal Thubert (pthubert)] This can be tricks, e.g. when the RFC number is part of the quoted RFC title eg
When to use RFC 6553, RFC 6554 and IPv6-in-IPv6   [I-D.ietf-roll-useofrplinfo]. I'm adding "" around the quote title.




1.      Look at #RFC6554 - that likely was meant to be a reference to the RFC?

2.      In Figure 2, might be worth moving the "RPL SRH" text up below the "plus" instead of leaving a space between them? In Section 3.2.1, first paragraph, the opening parenthesis is never closed. And, might be best to add "described in" before the Section 3.1 reference?

1.      In section 3.2.2, there is a closing parenthesis in the first paragraph, but no matching opening parenthesis? In section 3.2.2, HbH is used but is not defined nor was it defined in the 3 RFCs referenced in the Terminology section. It is used twice in the document. Either define in terminology, add to first use, or just spell out "hop by hop"?

1.      In section 3.2.2, reference to Section 3.2.1 might be "(see Section 3.2.1)"? Similar issue for reference to section 5.3.

2.      In section 3.2.2, last paragraph, there is "it is REQUIRED that the in the"? This seems to be malformed? I think the "the" after that should be dropped?

3.      Section 4, the last paragraph should probably start with "For", not "for"? And, I think a comma should be a period (after "form of 6LoRH") and an extra that should be removed (that that)? Section 4.3, "that as a long" should probably be "that has a long"?

2.      Section 4.3, I think it should be compressed - "in order to reconstruct the compressed"?

3.      Section 4.3, cleanup reference to "section section 4.3.1".

4.      Section 4.3.2, "described in more details" should probably just be "described in more detail"?

[Pascal Thubert (pthubert)] done all, and you were correct : )

5.      Section 5.1, it might be useful to indicate here that "Hop1" ... are the (possibly) compressed addresses? This field is not really defined.
[Pascal Thubert (pthubert)]  proposed addition:

The fields following the 6LoRH Type are compressed addresses indicating the consecutive
hops, and are ordered from the first to the last hop.

6.      Section 5.1, "It results that" is a bit odd? Perhaps just say "This means that all"? Similar issue in Section 5.2.3, though I don't think the same fix would work there?

[Pascal Thubert (pthubert)]  proposed change:

All the addresses in a given SRH-6LoRH header MUST be compressed in an identical fashion, so the Length of the compressed for is the same for all.



7.      Section 5.4, remove that in "used as Compression Reference is that the address". And the rest of that sentence is also a bit odd; not really sure what it is trying to convey?

[Pascal Thubert (pthubert)]  added clarification:
      Else, meaning that the IP-in-IP compression specified in this document is used and the encapsulator is implicitly the root, the address of the root is the reference.

                    Section 5.5, adding a reference to Appendix A.3 would be really useful here; that example makes this much easier to understand (add to end of the section - "For an example, see Appendix A.3."?

[Pascal Thubert (pthubert)]  Done:


8.      Section 6, "whereas the RPI is usually (and quiet illegally) omitted". It seems odd to use "usually" and "illegally"? Was this supposed to be legally? And later in same paragraph, "To impact of placing"? I think this was supposed to be "To impact the placing"?


[Pascal Thubert (pthubert)]  reworded:

    Note: it was found that some implementations omit the RPI for packets going down the RPL graph in non-storing mode, even though RPL indicates that the RPI should be placed in the packet.

   <removed the other sentence, not quite useful>


9.      In section 9, 2nd paragraph, there is an opening parenthesis that is never closed.

10.   In section 10.2, the <- and -> and ## are a bit odd. Can these be changed into just normal text? Or is there a reason for these special markers?

[Pascal Thubert (pthubert)]  My bugs using Kramdown. Fixed!

That's it. The technical issues, as best I could understand them, seem to be in good shape.

[Huge thanks, Bernie, this really helped : )