>
> s6.3, next to last para. s8 and s 12.2: In view of the statement in s6.3:
> The RPL Root MUST set the 'E' flag to 1 for all rejection and unknown status
> codes. The status codes in the 1-10 range [RFC8505] are all considered
> rejections. I think that IANA should be requested to add a column to the EARO
> status codes registry being modified by s12.2 to add a column that identifies a
> status code as a rejection or otherwise. Some words in s8 may be appropriate.
Well that would require normative text on the 6LoWPAN part. I guess we can do that at the next iteration of a 6LoWPAN ND specification.
For now what we specify is that from the RPL perspective the listed codes denote a failure such that the RPL operation that wraps it cannot happen and that's enough for us.
ED> While I understand that it would be polite to involve 6LoWPAN, WGs don't 'own' RFCs and their associated IANA registries. Since this draft 'needs' the extra information I personally wouldn't see a problem in asking for the extra column. It doesn't break
anythng 6LoWPAN are doing AFAICS. Anyway that's not my call... ask your AD.
PT> I posted a separate thread on this one.
> s7: Given that [EFFICIENT-NPDAO] is still a draft, I think this section should be
> synchronized with the draft so that we don't end up with one or the other new
> RFC updating an RFC that doesn't yet exist.
Yes, this was a discussion with Alvaro as well during his AD review and what you see is the outcome.
In particular, this is one reason why [EFFICIENT-NPDAO] is referenced normatively.
ED> Hmm. Maybe the rest of the IESG will have something to say about this.
PT> Maybe I misunderstand what you mean by synchronize. Would you report the change in NPDAO?
PT> trouble is that spec is virtually RFC, stuck in MISSREF in cluster C 310, in particular by this doc.
>
> Abstract: Expand RPL on first use (currently done in s1.) Expand ND.
Done it (relunctantly) for ND. RPL has been used as a noun by people of the art for a long while now. Expending it would turn the abstract in a book.
ED> I know, I know. But it isn't in the RDC Editor's list of well-jnown abbreviations. Sorry!
PT> It’s hard to recognized RPL in its full expansion. I tricked the text to avoid the acronym.
“
This specification updates RFC6550, RFC6775, and RFC8505, to provide
routing services to IPv6 Nodes that implement RFC6775, RFC8505, and
their extensions therein, but do not support RFC6550.
“
> s9.2.3, item 1: This would be a useful point to mention that the Target IPv6
> address is marked by the F Flag being 1.
Actually it is not. It is set to 0 per the previous section. But the Prefix Length is 128 indicating a host address (not that of the advertiser though, thus the 'F' flag set to 0).
ED> I'll take your word for that! The point I was trying to make was that given you have introduced the F Flag, I think it would be highly desirable
to explicitly highlight the point where an implementation would expect to set an F flag as well as places where it isn't set. I thought there would be an opportunity somewhere in s9.2.1.
PT> You’re correct, we define the flag here because we change the Target Option but this spec is not the one that really needs it. It was an opportunistic insertion. This information
is useful to test the path back when we advertise a prefix. It gives the root an address to ping within the advertised prefix. For Host routes, it’s only an indicator that the node is advertising self vs. another party, which in the case of this spec, is redundant
with the ‘External’ flag.
Take care,
Pascal
