Hi, Pascal.Thanks for the *extremely* speedy response!Further responses
inline.Cheers,ElwynSent from my Galaxy
-------- Original message --------From: "Pascal Thubert (pthubert)"
<pthubert=40cisco....@dmarc.ietf.org> Date: 14/12/2020 18:36 (GMT+00:00) To:
Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc:
draft-ietf-roll-unaware-leaves....@ietf.org, r...@ietf.org, last-c...@ietf.org
Subject: Re: [Gen-art] Genart last call review of
draft-ietf-roll-unaware-leaves-24 Hello Elwyn;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/gFun. 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,
ENDSHeavy 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 sectionsI 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,ElwynPascal_______________________________________________Gen-art
mailing listGen-art@ietf.orghttps://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
