Subject: Re: [6lo] [Gen-art] Genart last call review of draft-ietf-6lo-backbone-router-14
From: Alissa Cooper <[email-masked]>
To: "Pascal Thubert (pthubert)" <[email-masked]>, elwynd <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 19 Feb 2020 14:59:04 -0500
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>

Elwyn, thanks for your review. Pascal, thanks for your responses. I entered a No Objection ballot.

Alissa

> On Feb 7, 2020, at 2:54 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Elwyn
> 
> I implemented it on Cisco IOS years ago. What really hurts is the delay between that and the spec being finalized. The gory details of what I had to do escape me now but at least I still have the code as reference.
> 
> Many thanks again !
> 
> Pascal
> 
>> Le 7 févr. 2020 à 20:47, elwynd <[email-masked]> a écrit :
>> 
>> 
>> Hi, Pascal.
>> 
>> Thanks for the rapid turnround!
>> 
>> I did check the abbreviations list for the well-knownness of MAC.  There are a multitude of possible expansions so it is not marked as well-known.
>> 
>> But otherwise... that looks good and we are all done.
>> 
>> It is pretty complex system and I can't say that my brain was capable of running a proper simulation ;-) but it seemed to cover most of the bases that I could think of.  Are there existing implementations (I'd guess so!) - if so it might be worth mentioning somethng about them but that is a nice-to-have.
>> 
>> Cheers,
>> Elwyn
>> 
>> 
>> 
>> Sent from Samsung tablet.
>> 
>> 
>> -------- Original message --------
>> From: "Pascal Thubert (pthubert)" <[email-masked]>
>> Date: 07/02/2020 13:36 (GMT+00:00)
>> To: Elwyn Davies <[email-masked]>, [email-masked]
>> Cc: [email-masked], [email-masked], [email-masked]
>> Subject: RE: Genart last call review of draft-ietf-6lo-backbone-router-14
>> 
>> Hello Elwyn:
>> 
>> Many thanks for your review!
>> 
>> Let's see below:
>> 
>> 
>> > General: s/i.e. /i.e., / (4 places), s/e.g. /e.g.,/ (2 places)
>> 
>> Done
>> 
>> > 
>> > Abbreviations: The definition of abbreviations in this document is inconistent.
>> > There is a list of abbreviations but it is not complete; many abbreviations are
>> > introduced in the text in the usual way and there are some that are not
>> > expanded. Please be consistent - a complete list would be helpful, especially
>> > as some are used before the abbreviations section.
>> 
>> Made a pass
>> 
>> 
>> > References to Neighbor Solicitation/Advertisement messages: The formats
>> > NS(xxxx) and NA(xxxx) are used to refer to various NS/NA messages. Please
>> > add an explanation of this convention and a definition of the various
>> > messages referred to.
>> 
>> Added the abbreviations
>> 
>> 
>> > Use of Layer-2 and Layer-3:  These terms are not normally  hyphenated.
>> 
>> Removed the hyphen.
>> 
>> > s1: Term STA used for a 'node': Please expand this abbreviation and possibly
>> > explain why it is used (I am unclear how it is derived).
>> 
>> STA and AP are 802.11 terminology,  STA means station I believe. Changed to 
>> "
>> connectivity to the end node (the Wi-Fi STA)
>> "
>> 
>> > 
>> > s1, para 5: s/Like/In the same way as/
>> 
>> Done
>> 
>> > 
>> > s1, para 5: ID is not a well-known abbreviation - please expand on first use.
>> 
>> Added in the "Abbreviation" section which is where it is first used
>> 
>> > 
>> > s1, para 9: Need to expand MAC.
>> 
>> I think we got directives from RFC editor not to expand very well-known terms. If my memory serves me that was one.
>> 
>> > 
>> > s2.2, "Sleeping Proxy": It might be useful to add in " which might be in a sleep
>> > state in a low power network".
>> 
>> "
>>    Sleeping Proxy
>> 
>>          A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor
>>          Solicitations over the Backbone on behalf of the Registering
>>          Node which might be in a sleep state in a low power network.
>>          The Sleeping Proxy that is also a Bridging Proxy will
>>          preferably forward the relevant messages to the Registering
>>          Node as unicast frames in accord to the duty cycle of the
>>          Registering Node and let it respond.
>> 
>> 
>> "
>> 
>> > 
>> > s2.2, "Routing Proxy": Need to expand TLLA.
>> 
>> Done
>> 
>> > 
>> > s3, para 1: s/The next/The following/ 
>> 
>> Done
>> 
>> > 
>> > s3, 2nd set of bullets, bullet #2: s/This includes participating to the
>> >       solicited-node multicast address/This includes responding to messages
>> >       addressed tothe solicited-node multicast address/
>> 
>> The point is really the MLD thingy. What about:
>> 
>> "
>>      This includes joining the multicast group associated to
>>       the SNMA derived from the Registered Address as specified in
>>       section 7.2.1. of [RFC4861] over the Backbone.
>> 
>> "
>> 
>> > 
>> > s3, 2nd set of bullets, bullet #3: Expand NUD on first use (currently expanded
>> > twice in sss6 and 8).
>> 
>> Done and looked up /updated the other cases
>> 
>> > s3.1: Expand SLLAO on first use.
>> 
>> done
>> 
>> > s3.3, para at bottom of page 13 just before Figure 5: s/is a transmitted as a
>> > multicast/is transmitted as a multicast /
>> 
>> done
>> 
>> > s3.3, last para: s/suggests using RPL/suggests using the RPL routing protocol/
>> 
>> Done
>> 
>> > s3.4, last para: s/details/detail/
>> 
>> Done
>> 
>> > s3.5, para 1: s/as silently ignored./are silently ignored./
>> 
>> Done
>> 
>> > s4, last para: s/the MTU MUST have a same value/the MTU MUST have the
>> > same value/
>> 
>> Done, found several places
>> 
>> > s5, para 2: s/It results that a 6LBR MUST be capable of maintaining a
>> > state/Consequently a 6LBR MUST be capable of maintaining state/ 
>> 
>> Done
>> 
>> > s5, para 3: s/ which may be avoided of/ which may be avoided if/
>> 
>> Done
>> 
>> > s5, para 5: Expand TLLAO on first use.
>> 
>> Done
>> 
>> > s9: It would be useful to add a forward ref to s12 where the value of
>> > TENTATIVE_DURATION is defined.
>> 
>> Done, same for STALE_DURATION
>> 
>> > 
>> > s9.1: Remove empty second bullet.
>> 
>> Was gone already
>> 
>> > 
>> > Titles of ss9.1, 9.2 and 9.3: I Think these should be "Operations on...."
>> 
>> Changed
>> 
>> > 
>> > s9.2, 1st bullet: s/small timer/timer with a short setting/.  Is it possible to
>> > recommend any values here or indicate how to assign a suitable value?
>> 
>> Added " e.g., a few seconds to a minute;"
>> 
>> 
>> 
>> > 
>> > ss9.2, 9.3: It would be useful to add a forward ref to s12 where the value of
>> > STALE_DURATION is defined.
>> 
>> Done per the above comment
>> 
>> Many thanks again Elwyn!
>> 
>> I'm publishing right away as version 15 so people do not suffer from those nits again.
>> 
>> All the best
>> 
>> Pascal 
>> 
>> 
>> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art