Hi, Pascal. Thanks for the *extremely* speedy response! Further responses inline. Cheers, Elwyn Sent from my Galaxy -------- Original message -------- From: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@xxxxxxxxxxxxxx> Date: 14/12/2020 18:36 (GMT+00:00) To: Elwyn Davies <elwynd@xxxxxxxxxxxxxx>, gen-art@xxxxxxxx Cc: draft-ietf-roll-unaware-leaves.all@xxxxxxxx, roll@xxxxxxxx, last-call@xxxxxxxx Subject: Re: [Gen-art] Genart last call review of
draft-ietf-roll-unaware-leaves-24 Many thanks for your review! It was very thorough and helpful. I placed the first round of corrections here: https://github.com/roll-wg/roll-unaware-leaves/commit/523bd3c7b59a8eca822482a8a26b4cbd6b87c190 There are a few items left open, in particular the RPL-Unaware Leaves vs. RPL-Unaware-Leaves. I fail to see why there's a need for the '-' before Leave. ED> I don't really care either way - as long as the two documents are consistent. Aesthetically I think RPL-Unaware Leaves is marginally prettier. I'm sorry the RPL world has its own terms and habits, and it's hard to write a spec without leaving some of that taken for granted. OTOH, we do not want to over re explain things which are core to RPL operations, when this doc is an extension to those operations; arguable the implementers will be already aware of the code they extend and the art / context. ED> Don't worry! I am well aware of this problem for draft authors. Gen-art sees its job as trying to make sure that non-specialists are not totally bemused and can see if the RFC is of any relevance to them. Please let me know what you think of the below (I snipped all the things I plainly applied, many of them): > > Summary: The document is almost ready for publication. As mentioned > elsewhere in reviews it is a very dense document requesting updates of several > standards and as such it is a difficult read and I would not be totally sure that > everything is consistent. However, I did find s9 and s10 to be pretty clear. > There are a few minor issues that need resolving IMO. > Most are trivial but the connection to EFFICIENT-NPDAO needs fixing - both > these documents are in draft and specifying alterations or updates to a > document still in draft doesn't seem sensible. Apologies for rather late delivery > of this review - it took longer than expected. > > Major issues: > None > > Minor issues: > s6.1, para 2: I found this paragraph difficult to parse. I note also that nowhere in > the document is the implementor told to set the F flag to 1 (there is one place in > s9.2.2 where it has to be forced to 0). Presumably there should be an > instruction somewhere in s9.2.1 that there should be a Target Option with the F > flag set. I would suggest alternative text for this para as > follows: > > OLD: The new 'F' flag is set to 1 to indicate that the Target Prefix field > contains the IPv6 address of the advertising node, in which case the length of > the Target Prefix field is 128 bits regardless of the value of the Prefix Length > field. If the 'F' flag is set to 0, the Target Prefix field MUST be aligned to the next > byte boundary after the size (expressed in bits) indicated by the Prefix Length > field. Padding bits are reserved and set to 0 per section 6.7.7 of [RFC6550]. > > NEW: The added 'F' flag is set to 1 to indicate that the Target Prefix field contains > the IPv6 address of the advertising node and will, accordingly, have the Prefix > Length set to 128. The length of the Target Prefix field will be an integral number > of octets, TPL, which is the smallest integer such that (TPL * 8) is greater than or > equal to Prefix Length. > The Target Prefix is left (high bit) justified in the field and any additional bits in > the rightmost octet will be filled with padding bits. > Padding bits are reserved and set to 0 as specified in section 6.7.7 of [RFC6550]. > ENDS > Misunderstanding alert. The Prefix Length can be say /64 or /48. We need to indicate it, that's the main purpose of the option. What we do with the bit on it put the rest of the bits of the advertiser's address after the prefix bits. Say it's a /48 we announce. Out of that /48 there will be a /64 where the announcer resides. And the announcer will have an IPv6 address from that /64. In that case, if the bit is on, you'll find a Prefix field of 128 bit and a prefix length of 48. The first 48 bits are still the announced prefix. And the field contains the announcer's address starting with the 64 bits of its subnet prefix and then the advertising node's IID. ED> Ah! In that case I think that a clarification is indeed needed 'cos I hadn't got that story from the draft. I tried to do a mix to clarify; does the following help? " The Target Prefix of the RPL Target Option is left (high bit) justified and contains the advertised prefix; its size may be smaller than 128 when it indicates a Prefix route. The Prefix Length field signals the number of bits that correspond to the advertised Prefix; it is 128 for a Host route or less in the case of a Prefix route. This remains unchanged. This specification defines the new 'F' flag that is set to 1 to indicate that the Target Prefix field is extended to 128 bits and contains an IPv6 address of the advertising node taken from the advertised Prefix. When it is set, the Target Prefix field carries contain 2 distinct information, a route that can be a Host route or a Prefix route depending on the Prefix Length, and an IPv6 address of the advertiser. ED> s/carries contain 2 distinct information,/carries two distinct pieces of information:/ If the 'F' flag is set to 0, the Target Prefix field can be shorter than 128 bits and it MUST be aligned to the next byte boundary after the end of the prefix. Any additional bits in the rightmost octet are filled with padding bits. Padding bits are reserved and set to 0 as specified in section 6.7.7 of [RFC6550]. ED> That is much better. " > > s6.2, position of P flag: As a matter of interest why is the flag in position 1 and > not position 0 or 4? It might be more helpful in the event of further additional > functionality being added to have 3 spare bits together if the position is of no > consequence. There are other specs coming up which reserved the other bits but 0 and 1, and the bits were allocated starting from the right. See https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags, knowing that the value of 2 was taken by https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138. Net-net, we're exactly where you'd like us to be. ED> Great. I did look at the IANA registry and I didn't see any early assignments but I might have missed them. > > 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. > 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. > s14: Idnits notes that there is a normative reference to RFC 7102 which is > informational. I note that this was not mentioned in the Last Call. However RFC > 7102 has already had one accepted Downref waiver and the summary of terms > is a suitable use case. Yes, this is a classical nit; the usual solution for that reference is that the AD accepts the downref and we move on. ED> Indeed. This point is just there for form's sake and to remind your AD that he has to fill in the downref registry [and to remind him that the Last Call notice should have said.] > > Nits/editorial comments: > > General: s/byte/octet/g Fun. Carsten asked us to do the exact inverse change. Being French I favor "octets" but really the IETF should provide a guidance here. I just cannot go back and force with each new review. ED> I've been advocating for octets for about 15 years! > > 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! > > Abstract: Idnits produces a spurious warning about RFC 8505... > > -- The draft header indicates that this document updates RFC8505, but the > abstract doesn't seem to directly say this. It does mention RFC8505 though, so > this could be OK. Tool's limitation. > The abstract says > > This specification updates RFC6550, RFC6775, and RFC8505, > > which is fine by me. I will report this to the Tools team. > Yep. We're used to that one. We just learned to ignore it, not sure it's worth the extra code discerning all the language niceties that can be used here. ED> Bit of fun for Henrik! > s1, s2.2, s2.3: The term defined in [USEofRPLinfo] is RPL-Unaware-Leaf rather > than RPL-Unaware Leaf: s/RPL-Unaware Leaf/RPL-Unaware Leaf/ (3 places). > Similarly s/RPL-Aware Leaf/RPL-Aware-Leaf/ (1 place) and s/RPL-Aware > Node/RPL-Aware-node/ (2 places). Good point. In terms of English which makes more sense? We can fix either draft. I posted to the ROLL ML. ED> As I suggested above, I think I have a small preference for RPL-Unaware Leaf bu I don't care as long it used consistently across drafts. > s2.3, para 3: > > > > The term RPL-Aware Node (RAN) is introduced to refer to a node that is > > either > an RAL or a RPL Router. This term is already defined in [USEofRPLinfo] with, I > understand, the same meaning. s3, para 1: s/detailed/summarized/ - the formal > details are in [USEofRPLinfo]. Yep, was updated 😊 I changed to " This document uses the terms RPL-Unaware Leaf (RUL), RPL-Aware Node (RAN) and RPL Aware Leaf (RAL) consistently with [USEofRPLinfo]. A RAN is either an RAL or a RPL Router. As opposed to a RUL, a RAN manages the reachability of its addresses and prefixes by injecting them in RPL by itself. " And made the other proposed change as well. ED> Fine. > > s3. para 4: s/to transport a RPL Packet Information (RPI) [RFC6550]./to > transport the RPL Packet Information (RPI) [RFC6550]option./ Well both are transported, but RFC 6550 defines the RPI as abstract information not as an option. And to make things simpler we typically abuse "RPI" to say "RPL Option". What about: " The RPL data packets typically carry a Hop-by-Hop Header with a RPL Option [RFC6553] that contains the Packet Information (RPI) defined in section 11.2 of [RFC6550]. " ? ED> Fair enough. > > s3, para 4: '... except for the very special case above,' - I am not totally sure what > part of the section is being referred to by this. Do you mean the case referred to > in the previous sentence? Please make this clearer. I gave it a try: " Unless the RUL already placed a RPL Option in outer header chain, the packets from and to the RUL are encapsulated using an IP-in-IP tunnel between the Root and the 6LR that serves the RUL (see sections 7 and 8 of [USEofRPLinfo] for details). If the packet from the RUL has an RPI, the 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags, but it does not need to encapsulate the packet. " Works? ED> I believe so. > > s3, para 5: The jargon term 'going down' is used here without definition. It is > sort of inherited from [USEofRPLinfo] (Section 8.3.1) but is not properly defined > there either. Please improve and explain this jargon. These are defined in section 2 of RFC 6550, and very, very common in RPL parlance. I changed a sentence in section 2.2 to " "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] " ED> That resolves that. > s3, para 5: Might be sensible to add SRH to the glossary instead of expanding > here. Added. I kept the expansion though, in alignment with other acronyms in the glossary. ED> Fine. > s5, title: s/RPL-Unware Leaf/RPL-Unware-Leaf/ I delayed that one. ED> OK.. see above. > s6.3, para 2: > OLD: > This specification enables to carry the 6LoWPAN ND Status values in RPL DAO > and DCO messages, NEW: This specification adds a capability to allow the > carriage of 6LoWPAN ND Status values in RPL DAO and DCO messages, ENDS Heavy carriage! I'll trust you on this ]ED> :-) > s9.2: By convention, there should be a brief description of the purpose and > subsections before starting s9.2.1. The RFC Editor doesn't like empty sections I never hit that one. Interesting. For some reason the ETSI editor will force the opposite. Done anyway. ED> Ah, the unwriten rules! > 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. Again, a great many thanks Elwyn! ED> Glad to be of assistance. Nice to have an interesting document to review. Cheers, Elwyn Pascal _______________________________________________ Gen-art mailing list Gen-art@xxxxxxxx https://www.ietf.org/mailman/listinfo/gen-art |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
