Elwyn, thanks for your review. Pascal, thanks for your responses. I entered a No Objection ballot.
Alissa > On Dec 15, 2020, at 2:36 AM, Pascal Thubert (pthubert) > <pthubert=40cisco....@dmarc.ietf.org> wrote: > > Many Thanks Elwynd: > > > > > 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 > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>_______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
