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

From: Elwyn Davies via Datatracker <[email-masked]>
Date: Thu, 06 Feb 2020 16:37:49 -0800

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6lo-backbone-router-14
Reviewer: Elwyn Davies
Review Date: 2020-02-06
IETF LC End Date: 2020-02-06
IESG Telechat date: Not scheduled for a telechat
Summary: Ready with nits.
Major issues:
None

Minor issues:
None

Nits/editorial comments:
General: s/i.e. /i.e., / (4 places), s/e.g. /e.g.,/ (2 places)

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.

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.

Use of Layer-2 and Layer-3:  These terms are not normally  hyphenated.
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).

s1, para 5: s/Like/In the same way as/

s1, para 5: ID is not a well-known abbreviation - please expand on first use.

s1, para 9: Need to expand MAC.

s2.2, "Sleeping Proxy": It might be useful to add in " which might be in a
sleep state in a low power network".

s2.2, "Routing Proxy": Need to expand TLLA.

s3, para 1: s/The next/The following/

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/

s3, 2nd set of bullets, bullet #3: Expand NUD on first use (currently expanded
twice in sss6 and 8).

s3.1: Expand SLLAO on first use.

s3.3, para at bottom of page 13 just before Figure 5: s/is a transmitted as a
multicast/is transmitted as a multicast /

s3.3, last para: s/suggests using RPL/suggests using the RPL routing protocol/

s3.4, last para: s/details/detail/

s3.5, para 1: s/as silently ignored./are silently ignored./

s4, last para: s/the MTU MUST have a same value/the MTU MUST have the same
value/

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/

s5, para 3: s/ which may be avoided of/ which may be avoided if/

s5, para 5: Expand TLLAO on first use.

s9: It would be useful to add a forward ref to s12 where the value of
TENTATIVE_DURATION is defined.

s9.1: Remove empty second bullet.

Titles of ss9.1, 9.2 and 9.3: I Think these should be "Operations on...."

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?

ss9.2, 9.3: It would be useful to add a forward ref to s12 where the value of
STALE_DURATION is defined.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Feb 2020 13:35:49 +0000

Hello Elwyn:

Many thanks for your review!

> General: s/i.e. /i.e., / (4 places), s/e.g. /e.g.,/ (2 places)

Done

> as some are used before the abbreviations section.

Made a pass

> 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.

> 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

>       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

Done and looked up /updated the other cases
 
> s3.1: Expand SLLAO on first use.

done

> 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

> 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

> 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

> recommend any values here or indicate how to assign a suitable value?

Added " e.g., a few seconds to a minute;"

> 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

---

From: elwynd <[email-masked]>
Date: Fri, 07 Feb 2020 19:47:18 +0000

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,ElwynSent 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 commentMany thanks again Elwyn!I'm publishing right away as version 15 so people do not suffer from those nits again.All the bestPascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Feb 2020 19:54:58 +0000

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:

Done

Made a pass

Added the abbreviations

Removed the hyphen.

Done

"
   Sleeping Proxy

"

Done

Done

"

"

done

done

Done

Done

Done

Done

Done

Done

Was gone already

Changed

Many thanks again Elwyn!

All the best

Pascal

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 19 Feb 2020 14:59:04 -0500

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
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art