Re: [Gen-art] [6lo] Genart telechat review of draft-ietf-6lo-rfc6775-update-14

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Peter:

Many thanks for this (incredible) in depth review!
Adrian helped me correct some of that language in version 15, but you doubled it and more.
You helped me a lot and will save time on all the future reviewers of my prose to come : ) : ) : )

I'm attaching the resulting -16 since I cannot publish it but that will be done on Monday.

Please see below:


> -----Original Message----- 

<snip>
> 
> Summary: This document updates RFC 6775 with an Extend Address
> Registration Option and various changes/simplifications.  There are some
> questions I have that should be addressed along with a list of nits. [Ready
> with issues.]
> 
> I am aware that this is a review against draft -14.  Unfortunately, I started the
> review before -15 was released and I lack the time to go back and start with
> draft -15.  I hope that most of my comments remain relevant and useful.
> 
> Major issues:  None
> 
> Minor issues:
> 
> Page 6, 2nd paragraph: why is the capability for multiple registrations only
> "RECOMMENDED"?  It's not entirely clear why one would not want to follow
> this recommendation.  The second sentence says "It is also RECOMMENDED
> to provide new mechanisms..."  To whom is this recommendation made - the
> working group?
> It's not clear why this recommendation is here and stated in RFC 2119 form.

[PT>] Agreed, rereading it I find it surprising. 
This are actually requirements on this specification. I'll remove the RFC 2119 format to require


> 
> Page 11, Section 4.6, 5th paragraph, last sentence: it's not clear to me how
> the 6LN knows this is the case.
> 
[PT>] With Adrian's review, we clarified that the 6LR is found to support this spec or not based on 6CIO in RA. Adding a fwd ref to where that is explained


> Page 19, Section 7.1.2, 4th paragraph, last sentence: the sentence reads:
> "Once the 6LR is known to support this specification, the 6LN MUST obey this
> specification."  Isn't that only true with respect to that 6LR, not necessarily all
> 6LRs with which the 6LN may be communicating?  If so, perhaps that point
> should be clarified in the text.

[PT>] You right. I'll add "when communicating with that 6LR" to the text in 15 (changed since the T flag is no more used to discover capabilities so section 7.1.2 is partially gone).


> Page 20, Section 7.3, 3rd paragraph: what's the definition of "reasonable".  If
> guidance on what reasonable can't be given other than to say it's device and
> deployment dependent, is the guidance useful?  Or are there known
> guidelines that are easily derived from the device type and perhaps less so
> from the deployment parameters?

[PT>]  yes, this sentence was removed

> Page 21, Section 8, 2nd paragraph: the paragraph notes an expectation of a
> secure MAC in order to work.  Is that a realistic assumption?  Or is that a
> requirement and the whole scheme (potentially) falls apart if a secure MAC is
> not being used?

[PT>] This really means to say that ND is not protecting itself, and expects a L2 encryption to avoid potential attacks. I can say that at the beginning of the sentence.  The text now read:

"
    RFC6775 does not protect the content of its messages and
    expects a lower layer encryption to defeat potential attacks.
   This specification also expects that the LLN MAC provides secure unicast
    to/from the Backbone Router and secure Broadcast or Multicast from the
    Backbone Router in a way that prevents tampering with or replaying
    the Neighbor Discovery messages.
"
> 
> Page 22, 1st partial bullet item, last sentence: I may be confused, but why
> would a larger lifetime be appropriate for a node that moves compared to
> one that is relatively static?  Wouldn't the mobile node do better with a
> smaller lifetime so its registration doesn't linger on a 6LR that is simply not
> aware that the node has moved (and probably failed to deregister from it)?
> 
[PT>] This is about pruning LRU state in the router. A mobile node may very well act as you say. From the router perspective, keeping only LRU (short lived) address may cause to destroy a long lived address of the node, e.g. for use in management. This text suggests care there. But removing state before lifetime expires will have side effects and hopefully this is very, very rare. 


> Page 36, Req5.3: the requirement reads: "6LoWPAN ND security mechanisms
> SHOULD lead to small packet sizes".  Should that really say that their use
> SHOULD NOT lead to large packets?  I can't imagine a security mechanism
> that makes a packet smaller.
[PT>] 
[PT>] changed

> 
> Page 36, Req5.6: You may wish to expand this beyond CCM* as IEEE
> 802.15.4y is being spun up to make IEEE 802.15.4 algorithm agile.  At a
> minimum, this will likely add 256-bit key sizes and allow the use of GCM as a
> peer to CCM*.
[PT>] The requirement will evolve I guess. Is there anything final I can point to ?
In the meantime, I can add that agility and support for large keys are desirable 

"      Algorithm agility and support for large keys 
        (e.g., 256-bit key sizes) is also desirable, following at Layer-3 the
        introduction of those capabilities at Layer-2.


"

> 
> Nits/editorial comments:
> 
> General:
> 
> I mark these nits in order to save the RFC Editor a bit of work later on in the
> process and to make comprehension easier for all readers.  Take these as you
> will.
> 
> General:
> 
> Throughout the document, change "a NA" to "an NA".  Change "a NS" to "an
> NS".
[PT>] done

> Change "a LLN" to "an LLN".  
[PT>] done

Change "a RPL" to "an RPL" unless RPL is typically spoken as "ripple" and not spelled out.
[PT>] It is - no change

  Change "a EARO" to "an EARO".  Change "a EDAR" to "an EDAR". 
[PT>] done

 Change "a RUID" to "an RUID" unless
> it pronounced like "druid" without the leading 'd'.
> 
[PT>] named changed to ROVR after Adrian's point there. Added a pronunciation for it in the glossary

> Change "ARO option" to "ARO".  Change "EARO option" to "EARO".  Change
> "SLLAO option" to "SLLAO".
[PT>] done

> 
> Change any use of "IEEE Std." to "IEEE Std" and leave a space after "Std".
> Yes, the IEEE is aware that it would be more grammatical to use "Std.", but
> they don't.
[PT>] They (Bob Heile, Pat Kinney) actually asked me to use that specific form. I'd rather leave it at that.

> 
> Make sure each use of "i.e." and "e.g." is followed by a comma.
[PT>] done
> 
> Change "replacement to" to "replacement for".
[PT>] done

> 
> Replace "BLUETOOTH" with "Bluetooth".  And if you're going to use "(R)" for
> Bluetooth, consider that IEEE says, "The term EUI-64 is trademarked by IEEE
> and should be so identified."
> 
[PT>] OK, added it too. 

> Change "TimeSlotted" to "Timeslotted" to match IEEE Std 802.15.4 usage.
> 
[PT>] OK note that 6TiSCH uses TimeSlotted

> Change "Dependant" to "Dependent".
> 
[PT>] done

> Specific:
> 
> Page 1, Authors: change "cisco" to "Cisco" or "Cisco Systems" to reflect the
> official name of the company.
[PT>] historically it is a lower case; been there a while, now that you mention it. But OK.

> 
> Page 1, Abstract: change "low power" to "low-power".
> 
> Page 3, Section 1, 1st paragraph, 1st sentence: change "Low Power" to "Low-
> Power".
>
[PT>] done  : )

> Page 3, Section 1, "Registration" bullet item: change "a IPv6" to "an IPv6".
> 
> Page 4, "Extended LLN" definition: change "MultiLink" to "Multilink" or
> "Multi-Link" or "Multi-link", depending on which original use of the term you
> wish to align with.
[PT>] 
[PT>] done

> 
> Page 4, "updated" definition: append a comma after "6LR".
[PT>] done

> 
> Page 6, first paragraph, 1st sentence: delete comma after "messages".
[PT>] 
[PT>] This sentence is now as follows; should it be changed?
[PT>] 
"

	The extensions to the ARO option are used in the Duplicate Address messages,
	the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC),
              so as to convey the additional information all the way to the 6LBR.
"
> 
> Page 8, Section 4.2.1, 1st paragraph, 1st sentence: change the first "the" to
> "an", change "of" to "for", and delete "specification".  I'm not entirely sure I
> like "operation" since a counter doesn't by itself have an "operation", but I'm
> not sure "use" is the right substitute either.
> 
> Page 8, Section 4.2.1, 2nd paragraph: put '"Sequence Counter Operation"' in
> parentheses.
[PT>] 
I dare not change 4.2.1 since it is an exact copy of RFC 6550.
> 
> Page 9, Section 4,3, 1st paragraph, 2nd sentence: change "to identify" to
> "identifying".  I'm also not sure what "tentative" modifies in that sentence,
> but it could use a noun.  Maybe "attempt"?
[PT>] attmpet is good. I updated based on -15 as follows:
"

	The ROVR field generalizes the EUI-64 field of the ARO defined
    in <xref target="RFC6775"/>. It is scoped to a registration and
    enables recognizing and blocking an attempt to register a duplicate address,
    which is characterized by a different ROVR in the conflicting registrations
    It can also be used to protect the ownership of a Registered Address, if
    the proof-of-ownership of the ROVR can be obtained 
    (more in <xref target="llar"/>). "
> 
> Page 10, 1st paragraph, 2nd sentence: consider changing "memory" to
> "state".
[PT>] 
I guess you pean the second instance; changed to 

"
	The Registering Node SHOULD store the ROVR,	or enough information to 
              regenerate it, in persistent memory. If this is not done and an event such
              as a reboot causes a loss of state, re-registering the
	same address could be impossible until the 6LRs and the 6LBR time out the
	previous registration, or a management action is taken to clear the relevant
              state in the network.
"
> 
> Page 10, Section 4.4, 1st paragraph: change "a" before "Reserved" to "the".
> I'm not sure how support for the TID transports the "T" flag.  Perhaps this
> sentence could be reworded?
[PT>] yes; now it reads
"
	In order to map the new EARO content in the Extended Duplicate Address
    (EDA) messages, a new TID
	field is added to the Extended DAR (EDAR) and the Extended DAC (EDAC)
	messages as a replacement of the Reserved field, and a non-null value of the
	ICMP Code indicates support for this specification.
    The format of the EDA messages is presented in <xref target="DAM"/>.

"
> 
> Page 10, Section 4.4, 2nd paragraph: change ", and though" to "although".
> Delete the comma after "body".
[PT>] This text is gone. There is a conflict with the extension of the ROVR field that is inferred from the message size. It would have been easier that the DAR/DAC carry the EARO in the first place...

> 
> Page 10, Section 4.4, 3rd paragraph: change "for" to "with".
> 
[PT>] done

> Page 10, Section 4.5, 1st paragraph, 2nd sentence: delete the comma after "addresses".
> 
[PT>] done
> 
> Page 10, Section 4.5, 3rd paragraph, last sentence: delete the comma after "device".
[PT>] This text is gone
> 
> Page 11, Section 4.6, 2nd paragraph, 1st sentence: change "is" to "be".
[PT>] done
> 
> Page 11, Section 4.6, 2nd paragraph, 2nd sentence: delete the comma after
> "addresses".
[PT>] done
> 
> Page 12, 2nd full paragraph, 1st sentence: delete the second "IPv6".
> 
[PT>] done

> Page 12, 3rd full paragraph, 2nd sentence: delete "as".
> 
[PT>] This text is gone

> Page 12, Section 4.7, 1st paragraph, 1st sentence: append a comma after
> "6LR".
[PT>] done
> 
> Page 13, 1st full paragraph, 2nd sentence: put "Table 1" in parentheses.
[PT>] done
> 
> Page 13, 4th full paragraph, 3rd sentence: delete the comma after "6BBR".
[PT>] done
> 
> Page 13, 4th full paragraph, last sentence: move "do so" to after "could".
> Delete "the" before "said".
[PT>] done
> 
> Page 14, 2nd paragraph, 1st sentence: move "yet" before "reach".
[PT>] done
> 
> Page 14, Section 5, 1st paragraph: delete "The".
> 
[PT>] done

> Page 14, Section 5, 2nd paragraph: delete the comma after "EARO".  Add a
> comma after "6LBR".
[PT>] done; that text was slightly rearranged in -15 but the comment still applies
> 
> Page 14, Section 5, 3rd paragraph, 2nd sentence:  delete "Neighbor
> Solicitation" and "Neighbor Advertisement" along with their associated
> parentheses.
[PT>] this is gone
> 
> Page 14, Section 6 title: change "And" to "and".
[PT>] done
> 
> Page 14, Section 6.1, 2nd paragraph, 2nd sentence: consider changing "On
> the other hand" to "In contrast".
[PT>] In fact, "Similarly," was proposed and looks good

> 
> Page 15, 1st paragraph, 2nd sentence: insert "is" before "also".
[PT>] done
> 
> Page 15, 3rd paragraph, 2nd sentence: insert "being" before "set".
[PT>] done
> 
> Page 15, 2nd partial table, "0..2" entry: put "Duplicate Address" in parentheses.
[PT>] done
> 
> Page 16, Table 1, "4" entry: delete the comma.  Maybe add "sent" after "or".
> I'm not sure that rejections are "placed".
[PT>] does this read better:
"
         Removed: The binding state was removed. This status may be placed in
		an NA(EARO) message that is sent as the rejection of a proxy registration
                            to a Backbone Router, or in an asynchronous NA(EARO) at any time.
"

> 
> Page 16, Table 1, "5" entry, 2nd sentence: append a comma after "instance".
[PT>] done
> 
> Page 16, T bit definition: change "One bit" to "One-bit".
[PT>] done
> 
> Page 17, TID definition: change "id" to "ID".
[PT>] done
> 
> Page 17, RUID definition: change "IDentifier" to "Identifier".  I think most
> people are comfortable with the two letter "ID" being derived from
> "Identifier".  Change "EUI-64 derived" to "EUI-64-derived".  Change "IID" to
> "Interface Identifier (IID)".
[PT>] this text has changed with -15 to reflect better the true nature of that field

"
Registration Ownership Verifier (ROVR):
        Enables the correlation between multiple attempts to register a same
        IPv6 Address. 
        This can be a unique ID of the Registering Node, such as the EUI-64(R) 
        address of an interface. This can also be a token obtained 
        with cryptographic methods and used as proof of ownership of the 
        registration. The scope of a ROVR is the registration of a particular 
        IPv6 Address and it cannot be used to correlate registrations of
        different addresses.
"
> 
> Page 18, Code definition: change "odd" to "odd-numbered".  Totally pedantic,
> I know.
[PT>] This is gone; anything non null indicates support of this spec. 
> 
> Page 18, RUID definition: change "IDentifier" to "Identifier".
[PT>] Now ROVR
> 
> Page 18, 2nd paragraph, 2nd sentence: append a comma after "6LBR" and
> '"B"'.
[PT>] done
> 
> Page 18, 2nd paragraph, 3rd sentence: insert "of a" before "6LR" and insert
> "a"
> before "6LBR".
[PT>] this text is gone
> 
> Page 18, option field L definition: change the comma to a semicolon. 
[PT>] this text is gone
> 
> Page 19, Section 7.1.2, 1st paragraph, 2nd sentence: bracket "for instance"  with commas. 
[PT>] this text is gone
> 
> Page 20, Section 7.2, 1st paragraph, 1st sentence: change "an" to "An".  Insert
> "the" before "source".  Append "address in the ARO" after "source".
> 
[PT>] ended up with the below. Does it work?

"
        An RFC6775-only 6LN will use the Registered Address as the source
        address of the NS message and will not use an EARO.
"
> Page 20, Section 7.3, 1st paragraph, 1st sentence: insert "the" before
> "source"
> and append "address" after "source".
[PT>] this text is gone
> 
> Page 20, Section 7.3, 5th paragraph: change "can not" to "cannot".  (Yes, both
> are correct, but cannot is more common and is used in the very next
> paragraph.)
[PT>] done :) 
> 
> Page 21, Section 8, 1st paragraph, 2nd sentence: delete "a" before "rogue".
[PT>] done :)
> 
> Page 21, Section 8, 3rd paragraph: delete the comma after ")" and change
> "protection" to "protecting".
[PT>] done 
> 
> Page 22, 1st full bullet item, 2nd sentence: change "stringer" to "stronger".
[PT>] done 
> 
> Page 22, 1st paragraph after bullet items, 2nd sentence: delete the comma. 
[PT>] done :)
> 
> Page 22, Section 9, 1st paragraph, 1st sentence: change "that is" to either
> "such that it is" or "that is,".  The latter form is equivalent to "i.e.,".
[PT>] used the former
> 
> Page 22, Section 9, 2nd paragraph: append a comma after "[RFC3971]" and
> delete the following "and".
[PT>] done
> 
> Page 23, 1st full paragraph: change "deployment" to "deployments" and
> "environment" to "environments".
[PT>] done
> 
> Page 23, 2nd full paragraph, 3rd sentence: append a period after the first
> "[RFC8064]". 
[PT>] done
> 
> Page 23, Section 10, 1st paragraph: maybe change "attributed" to
> "allocated"?
[PT>] done
> 
> Page 25, Table 5, ARO status 9: change "registry" to "Registry" to match prior
> use. 
[PT>] done
> 
> Page 26, Section 11, 1st sentence: append a comma after "Lovnick".
[PT>] Now it's your name actually,
> 
> Page 25, Section 11, 2nd sentence: append a comma after "Also" and after
> "6LBR".
[PT>] done
> 
> Page 31, Appendix A, 2nd paragraph: change "Network" to "network".
[PT>] done
> 
> Page 32, 1st full paragraph: there doesn't seem to be an exact "Low-Power
> Wi-Fi" definition.  Maybe you want to cite "Wi-Fi HaLow", which is the Wi-Fi
> Allowance's term for this technology.  Or is this some other term?  In which
> case, you should probably call it low-power IEEE 802.11 networking.  Delete
> the "(R)" after "Bluetooth" as it was already used earlier in the document.
> Change "11AH" to "11ah".
[PT>] I mean low power settings of the original .11 so I changed to that. 

> 
> Page 32, 4th full paragraph: I-D.chakrabarti-nordmark-6man-efficient-nd is no
> longer active.  And its title was "IPv6 Neighbor Discovery Optimizations for
> Wired and Wireless Networks".  It expired 2.5 years ago.  Does it still make a
> good reference?
[PT>] Yes, I hope we revive it someday soon
> 
> Page 32, Appendix B, 1st paragraph, 2nd sentence: remove the space after
> "B.8".
[PT>] done
> 
> Page 32, Section B.1, 1st sentence: should the first use of "6LR-a" be
> something like "6LR-b" as in a different a 6LR from 6LR-a, which can no longer
> be notified?
[PT>] right; text updated to
"

	    Due to the unstable nature of LLN links, even in an LLN of immobile
	    nodes a 6LN may change its point of attachment from 6LR-a to 6LR-b,
	    and may not be able to notify 6LR-a. Consequently, 6LR-a may still
	    attract traffic that it cannot deliver any more.
"
> 
> Page 33, Section B.2, 1st paragraph, 2nd sentence: change "at" to "by".
[PT>] done
> 
> Page 33, Section B.2, 1st paragraph, 4th sentence: does it make sense to
> change "would need to" to "must"?
[PT>] Actually I clarified. The req is that the 6LN signals to the 6LR whether it participates to the routing or wishes the 6LR to do it on its behalf. This draft enables the generic signaling and a companion draft at ROLL acts on that signaling for the particular case of RPL.
 "
       It is required that a 6LoWPAN Node 
        attached via ND to a 6LR indicates whether it participates in the
        selected routing protocol to obtain reachability via the 6LR, or
        whether it expects the 6LR to manage its reachability.

"
> 
> Page 33, Section B.2, 2nd paragraph, 1st sentence: consider changing "Next
> to"
> to "Beyond".
[PT>] done
> 
> Page 33, Section B.2, 2nd paragraph, 2nd sentence: append a comma after
> "example".
[PT>] done
> 
> Page 34, Req2.2: append a comma after "[RFC6550]".
[PT>] done
> 
> Page 34, Req2.3, 1st sentence: append a comma after "instance".
[PT>] done
> 
> Page 34, Section B.3, 1st paragraph, 1st sentence: change "Identifier" to  "identifier".
[PT>] done
> 
> Page 34, Section B.3, 1st paragraph, 2nd sentence: insert "including" before "ITU-T".  Change "IEEE1901.2" to "IEEE 1901.2"
[PT>] Actually the draft is obsolete, tere's new work with "Transmission of IPv6 Packets over PLC Networks" so I updated the reference
> 
> Page 34, Req3.2: change "Identifier" to "identifier".
[PT>] done
> 
> Page 35, Section B.4, 2nd paragraph: change "Addresses" to "addresses".
[PT>] done
> 
> Page 35, Req4.1: change "Address" to "address".
[PT>] done
> 
> Page 35, Req4.2: delete the comma and insert "SHOULD" before "enable".
[PT>] done
> 
> Page 35, Req4.3: change "in" to "on".
[PT>] done
> 
> Page 35, Section B.5, 1st paragraph, 1st sentence: append a comma after "6LBR".
[PT>] done
> 
> Page 35, Section B.5, 3rd paragraph, 2nd sentence: append a comma after "joining".
[PT>] done
> 
> Page 36, Req5.1: append a comma after "6LBR".
[PT>] done
> 
> Page 36, Req5.3, 2nd sentence: append a comma after "DAR".
[PT>] done
> 
> Page 36, Req5.9: change "Node" to "node".  Delete the comma after "owner".
[PT>] done
> 
> Page 36, Section B.6: should "DODAG" be added to the glossary in Appendix C?
[PT>] 
[PT>] done; the glossary as moved up in the terminology
> 
> Page 37, Req6.2: change "and" to "or".
[PT>] done
> 
> Page 37, Section B.7, 1st paragraph, 1st sentence: delete the extraneous
> space before the colon.
[PT>] done
> 
> Page 37, Section B.7, 2nd paragraph: change "he" to "the administrator".
> Change "his" to "the".
> 
> Page 37, Req7.1: I'm not a fan of "provided providing".  I don't have better
> wording at the moment.
[PT>] -> provided that enables ?
> 
> Page 37, Req7.2: change "n" to "in".
[PT>] done
> 
> Page 37, Req7.3: change the first use of "information" to "Information".
> Change "the Address" to "the address".  Append a comma after "6LR".
[PT>] done
> 
> Page 37, Req 74: append a period to the end of the requirement.
[PT>] done
> 
> Page 39, Table 7: for entries that don't have a document listed, should there
> be something?  Where did these requirements come from?
[PT>] There was a requirement draft that was presented repeatedly to the group but based n IESG recommendations, we decided not to turn it into RFC. This appendix is a state of the art at the time of publication of we we are and where e see we are going.
> 
> Page 39, LLN definition: change to "Low-Power and Lossy Network".
[PT>] done

Again, Peter, that was an incredible effort on your part. I learnt quite  a few things on English syntax and how things are done differently from the French as I know it. I really appreciate all you did.

Take care,

Pascal

> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo