Subject: [6lo] I-D.ietf-6lo-6lobac-01 review

From: james woodyatt <[email-masked]>
Date: Wed, 17 Jun 2015 15:47:19 -0700

Everyone—

This is my review of I-D.ietf-6lo-6lobac-01.

— Section 1, page 1 [editorial] Recommend rewriting the last sentence of the first paragraph as follows: “The general approach is to adapt elements of the 6LoWPAN specifications [RFC 4944, RFC 6282 and RFC 6775] to constrained wired networks.”

— Section 1, page 2 [technical] Recommend appending after the final paragraph in the section: “This document specifies that MS/TP devices with global scope addresses are REQUIRED to use IPv6 Neighbor Discovery Compression [RFC 6775] to register opaque 64-bit IIDs with their local routers."

— Section 3, page 5 [editorial] How does this specification assume that “a unique IPv6 subnet prefix is assigned to each MS/TP segment?” Assuming this means “other than the link-local prefix fe80::/10.” I don’t see where this assumption is correct. It looks to me like it will work fine if fe80::/10 is the only subnet assigned to the link. Indeed the use of the MAY keyword in paragraph about global scope addresses in section 6 seems to support my observation. Recommend removing the relevant sentence noting this assumption.

— Section 3, page 6 [technical] As Peter van der Stok notes, IPv6 multicast should not be REQUIRED to use link-layer broadcast. It should suffice to relax that to RECOMMENDED or OPTIONAL.

— Section 5, page 6 [editorial] RFC 6282 does not “deprecate” the LOWPAN_HC1. It merely provides LOWPAN_IPHC as a more widely applicable alternative. Recommend rewriting these sentences as follows: “LoBAC is a subset of the LoWPAN encapsulation defined in RFC 4944 and extended in RFC 6282, therefore the use of “LOWPAN” in the literals below is intentional. The principle difference between LoBAC and LoWPAN are the omission of the Fragmentation, Mesh, Broadcast and LOWPAN_HC1 headers.

— Section 5, page 6 [editorial] RFC 6282 redefines the Escape header, reserving a new dispatch code for its eventual replacement, and this has been the subject of some debate in 6LO recently. In light of this, the language in this draft about “all protocol datagrams (…) SHALL be preceded by one of the valid LoBAC encapsulation headers” should be clarified. Is the dispatch value reserved for the Escape replacement, which might be used for RPL artifacts in forthcoming documents, a valid LoBAC encapsulation header? (See further remarks below.)

— Section 5, page 6 [technical] “SHALL” is not a RFC 2119 keyword. Recommend replacing with MUST.

— Section 5, page 7 [technical] The pattern “01 000000” used for the ESC code should be described as “reserved by RFC 6282 for defining a mechanism to allow for more than 64 dispatch values,” c.f. recent discussion on the 6LO working group list regarding the erratum reported here: <http://www.rfc-editor.org/errata_search.php?rfc=4944&eid=4359>. As an aside, inclusion of the ESC code in the set of valid Dispatch values above along with the previously stated requirement that all protocol datagrams MUST be preceded by one of the valid LoBAC encapsulation headers opens the question of whether the ESC header is an encapsulation header. Are protocol datagrams allowed to be encapsulated below whatever the ESC header is defined to carry in the future, e.g. the RPL artifacts? I don’t think this draft should try to imply otherwise, but it might help to call out what the ESC header is actually doing in LoBAC. I’m not sure I know, so I leave it to the authors to explain.

— Section 6, page 9 [editorial] the phrases “IPv6 Interface Identifier,” “Interface Identifier” and “IID" in the first four paragraphs of section 6 should be replaced with “Link-local IPv6 Interface Identifier (IID)” in the first instance and “Link-local IID” in all subsequent instances, so as to make clear that these identifiers are not to be used with global scope addresses.

— Section 7, page 9 [editorial] should read “...formed by appending the Link-local IID, as defined above…”

— Section 13, the acknowledgement should include the authors of RFC 6282 and RFC 6775 as well.

—james

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 17 Jun 2015 22:44:00 -0400

James,

Thanks for taking the time to review this proposal.  Comments inline...

On Wed, Jun 17, 2015 at 6:47 PM, james woodyatt <[email-masked]> wrote:

> — Section 1, page 1 [editorial] Recommend rewriting the last sentence of
> the first paragraph as follows: “The general approach is to adapt elements
> of the 6LoWPAN specifications [RFC 4944, RFC 6282 and RFC 6775] to
> constrained wired networks.”
>
> OK.

> — Section 1, page 2 [technical] Recommend appending after the final
> paragraph in the section: “This document specifies that MS/TP devices with
> global scope addresses are REQUIRED to use IPv6 Neighbor Discovery
> Compression [RFC 6775] to register opaque 64-bit IIDs with their local
> routers."
>
> Sorry, are you talking about ARO?  I'm not sure it's appropriate to
REQUIRE any particular
policy at this layer, particularly if you're thinking along the lines of
ideas proposed in draft-
thaler-6lo-privacy-addrs.

> — Section 3, page 5 [editorial] How does this specification assume that “a
> unique IPv6 subnet prefix is assigned to each MS/TP segment?” Assuming this
> means “other than the link-local prefix fe80::/10.” I don’t see where this
> assumption is correct. It looks to me like it will work fine if fe80::/10
> is the only subnet assigned to the link. Indeed the use of the MAY keyword
> in paragraph about global scope addresses in section 6 seems to support my
> observation. Recommend removing the relevant sentence noting this
> assumption.
>

Good catch.  What I mean is one link-local prefix, and (optionally) one ULA
prefix and/or one Global prefix.

>
> — Section 3, page 6 [technical] As Peter van der Stok notes, IPv6
> multicast should not be REQUIRED to use link-layer broadcast. It should
> suffice to relax that to RECOMMENDED or OPTIONAL.
>
> See reply to Peter.  Will relax to allow unicast of IPv6 multicast
messages (though that sounds
pretty inefficient).  What is out-of-bounds is re-defining the MS/TP
addressing architecture.

— Section 5, page 6 [editorial] RFC 6282 does not “deprecate” the
> LOWPAN_HC1. It merely provides LOWPAN_IPHC as a more widely applicable
> alternative.

See RFC 6282, section 2, para 1.  That seems pretty clearly worded to me.

Recommend rewriting these sentences as follows: “LoBAC is a subset of the
> LoWPAN encapsulation defined in RFC 4944 and extended in RFC 6282,
> therefore the use of “LOWPAN” in the literals below is intentional. The
> principle difference between LoBAC and LoWPAN are the omission of the
> Fragmentation, Mesh, Broadcast and LOWPAN_HC1 headers.
>
> I will go back and review this again, but I don't see a need to support
HC1 compression.

> — Section 5, page 6 [editorial] RFC 6282 redefines the Escape header,
> reserving a new dispatch code for its eventual replacement, and this has
> been the subject of some debate in 6LO recently. In light of this, the
> language in this draft about “all protocol datagrams (…) SHALL be preceded
> by one of the valid LoBAC encapsulation headers” should be clarified. Is
> the dispatch value reserved for the Escape replacement, which might be used
> for RPL artifacts in forthcoming documents, a valid LoBAC encapsulation
> header? (See further remarks below.)
>
> I've had enough feedback in support of IPHC that I plan to mandate that
and replace the
whole table with a single codepoint (as in RFC 7428).

> It is in my copy of RFC 2119.  I have no aversion to MUST, but most of the
language in
this section is cribbed from RFC 4944.

> — Section 5, page 7 [technical] The pattern “01 000000” used for the ESC
> code should be described as “reserved by RFC 6282 for defining a mechanism
> to allow for more than 64 dispatch values,” c.f. recent discussion on the
> 6LO working group list regarding the erratum reported here: <
> http://www.rfc-editor.org/errata_search.php?rfc=4944&eid=4359>. As an
> aside, inclusion of the ESC code in the set of valid Dispatch values above
> along with the previously stated requirement that all protocol datagrams
> MUST be preceded by one of the valid LoBAC encapsulation headers opens the
> question of whether the ESC header is an encapsulation header. Are protocol
> datagrams allowed to be encapsulated below whatever the ESC header is
> defined to carry in the future, e.g. the RPL artifacts? I don’t think this
> draft should try to imply otherwise, but it might help to call out what the
> ESC header is actually doing in LoBAC. I’m not sure I know, so I leave it
> to the authors to explain.
>
> As I said above, I'm avoiding it entirely.

> — Section 6, page 9 [editorial] the phrases “IPv6 Interface Identifier,”
> “Interface Identifier” and “IID" in the first four paragraphs of section 6
> should be replaced with “Link-local IPv6 Interface Identifier (IID)” in the
> first instance and “Link-local IID” in all subsequent instances, so as to
> make clear that these identifiers are not to be used with global scope
> addresses.
>
> Yes, I need to re-work this.  As an example, RFC 7428 does a good job of
making this distinction.
They use the term "link-layer-derived IPv6 address".

> Link-local IID, as defined above…”

Ibid.

> OK.

Kerry

> —james
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Jun 2015 10:43:30 -0700

> On Jun 17, 2015, at 19:44, Kerry Lynn <[email-masked]> wrote:
> 
> Recommend rewriting these sentences as follows: “LoBAC is a subset of the LoWPAN encapsulation defined in RFC 4944 and extended in RFC 6282, therefore the use of “LOWPAN” in the literals below is intentional. The principle difference between LoBAC and LoWPAN are the omission of the Fragmentation, Mesh, Broadcast and LOWPAN_HC1 headers.
> 
> I will go back and review this again, but I don't see a need to support HC1 compression.

I don’t mean to suggest 6LoBAC should support HC1 compression. I was merely making an editorial note about the use of the word “deprecated” in the current draft. That’s unclear terminology, and my recommendation is just to explicitly list the LOWPAN_HC1 header as one of the kinds that appears in 6LoWPAN [RFC 4944] that doesn’t appear in 6LoBAC.

—james