Re: [Gen-art] Genart last call review of draft-ietf-6lo-backbone-router-14

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

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 <[e-mail]> 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)" <[e-mail]>
Date: 07/02/2020 13:36 (GMT+00:00)
To: Elwyn Davies <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
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