Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB43012092B; Wed, 19 Feb 2020 11:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=0wu3Vgu+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mp+YRBxe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw6TFzsG5d5l; Wed, 19 Feb 2020 11:59:06 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4441208D4; Wed, 19 Feb 2020 11:59:05 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id B31C0706; Wed, 19 Feb 2020 14:59:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 19 Feb 2020 14:59:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=kSWPORRnvmwys5SzyyN7yzK VXC0pbxfX8Uvl9ycsIQ8=; b=0wu3Vgu+J1mCR1nvGMDKaBlIzjzJevCGwxANojN 9EPmtfZb78h11aeJC0De5bx+vyW+cyK+p2MfOQIKnDYxmCS0JYRaWfUbI9i1SKJB skxbgofQrQlFtZ4qegnpgEJLP5PwczOutIZTl9rCk0oA1uvyEIoZzOobG5pKmxNo 34w0RWKnFjv30vfJLr935GeZN2gMPeY1jlqloXVlDTCETnhGESuHynn6GzNubZ6B J0PpjTDI21QgLph0gPiThbA5Y+5MNRurqOkczrIxbOSbBMifiRCybl/QBao8rPpi KK3bPUvVjwml4Rqyy2U/05RuIOCqtLs7P3OMRexRhYliaVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=kSWPOR Rnvmwys5SzyyN7yzKVXC0pbxfX8Uvl9ycsIQ8=; b=mp+YRBxeSb89XUblb9aFGw CW2HrCp6TA7nw+YUdT4xbU8l1hAnyaKAGJRa/b+Fopn7k9k5Ag9vlnEOgac0SOXA aLTuCni0b2HdVeIPARqTcz6NsM2u88eKyGsnreYlBaHNALgnFGYQKWflvBqIlkAE 3Z+Vxray33C6Q1VeMvWb8bajIam7iFVNgAxME19iA7dkrM019TaziLOJYJir8r8y cIpnPAMBQ3+Sa1n+eQBNCIo8Pieu5gaGxkX6zdk3DbUGvaE5l9SUpU9OJuzbwjar tE1fbn5AJtumGoDSgivEDLAUYDkcNpehV3wQSYFq3GoXYCCB5z4BxNxwLJsJBfaQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedtgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppeduje efrdefkedruddujedrkedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 62E323280060; Wed, 19 Feb 2020 14:59:03 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A8BC16EC-3411-4FA5-9D92-B4B50063FD73" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 19 Feb 2020 14:59:04 -0500 In-Reply-To: <43418FF0-2E98-4720-BB23-B0032E70038E@cisco.com> Cc: "last-call@ietf.org" , "gen-art@ietf.org" , "draft-ietf-6lo-backbone-router.all@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> To: "Pascal Thubert (pthubert)" , elwynd References: <5e3dbec6.1c69fb81.1f440.717b@mx.google.com> <43418FF0-2E98-4720-BB23-B0032E70038E@cisco.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [6lo] [Gen-art] Genart last call review of draft-ietf-6lo-backbone-router-14 X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 19:59:15 -0000 --Apple-Mail=_A8BC16EC-3411-4FA5-9D92-B4B50063FD73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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) = wrote: >=20 > Hello Elwyn >=20 > 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. >=20 > Many thanks again ! >=20 > Pascal >=20 >> Le 7 f=C3=A9vr. 2020 =C3=A0 20:47, elwynd a = =C3=A9crit : >>=20 >> =EF=BB=BF >> Hi, Pascal. >>=20 >> Thanks for the rapid turnround! >>=20 >> 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. >>=20 >> But otherwise... that looks good and we are all done. >>=20 >> 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. >>=20 >> Cheers, >> Elwyn >>=20 >>=20 >>=20 >> Sent from Samsung tablet. >>=20 >>=20 >> -------- Original message -------- >> From: "Pascal Thubert (pthubert)" >> Date: 07/02/2020 13:36 (GMT+00:00) >> To: Elwyn Davies , gen-art@ietf.org >> Cc: last-call@ietf.org, draft-ietf-6lo-backbone-router.all@ietf.org, = 6lo@ietf.org >> Subject: RE: Genart last call review of = draft-ietf-6lo-backbone-router-14 >>=20 >> Hello Elwyn: >>=20 >> Many thanks for your review! >>=20 >> Let's see below: >>=20 >>=20 >> > General: s/i.e. /i.e., / (4 places), s/e.g. /e.g.,/ (2 places) >>=20 >> Done >>=20 >> >=20 >> > 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. >>=20 >> Made a pass >>=20 >>=20 >> > 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. >>=20 >> Added the abbreviations >>=20 >>=20 >> > Use of Layer-2 and Layer-3: These terms are not normally = hyphenated. >>=20 >> Removed the hyphen. >>=20 >> > 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). >>=20 >> STA and AP are 802.11 terminology, STA means station I believe. = Changed to=20 >> " >> connectivity to the end node (the Wi-Fi STA) >> " >>=20 >> >=20 >> > s1, para 5: s/Like/In the same way as/ >>=20 >> Done >>=20 >> >=20 >> > s1, para 5: ID is not a well-known abbreviation - please expand on = first use. >>=20 >> Added in the "Abbreviation" section which is where it is first used >>=20 >> >=20 >> > s1, para 9: Need to expand MAC. >>=20 >> I think we got directives from RFC editor not to expand very = well-known terms. If my memory serves me that was one. >>=20 >> >=20 >> > s2.2, "Sleeping Proxy": It might be useful to add in " which might = be in a sleep >> > state in a low power network". >>=20 >> " >> Sleeping Proxy >>=20 >> 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. >>=20 >>=20 >> " >>=20 >> >=20 >> > s2.2, "Routing Proxy": Need to expand TLLA. >>=20 >> Done >>=20 >> >=20 >> > s3, para 1: s/The next/The following/=20 >>=20 >> Done >>=20 >> >=20 >> > 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/ >>=20 >> The point is really the MLD thingy. What about: >>=20 >> " >> 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. >>=20 >> " >>=20 >> >=20 >> > s3, 2nd set of bullets, bullet #3: Expand NUD on first use = (currently expanded >> > twice in sss6 and 8). >>=20 >> Done and looked up /updated the other cases >>=20 >> > s3.1: Expand SLLAO on first use. >>=20 >> done >>=20 >> > s3.3, para at bottom of page 13 just before Figure 5: s/is a = transmitted as a >> > multicast/is transmitted as a multicast / >>=20 >> done >>=20 >> > s3.3, last para: s/suggests using RPL/suggests using the RPL = routing protocol/ >>=20 >> Done >>=20 >> > s3.4, last para: s/details/detail/ >>=20 >> Done >>=20 >> > s3.5, para 1: s/as silently ignored./are silently ignored./ >>=20 >> Done >>=20 >> > s4, last para: s/the MTU MUST have a same value/the MTU MUST have = the >> > same value/ >>=20 >> Done, found several places >>=20 >> > 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/=20 >>=20 >> Done >>=20 >> > s5, para 3: s/ which may be avoided of/ which may be avoided if/ >>=20 >> Done >>=20 >> > s5, para 5: Expand TLLAO on first use. >>=20 >> Done >>=20 >> > s9: It would be useful to add a forward ref to s12 where the value = of >> > TENTATIVE_DURATION is defined. >>=20 >> Done, same for STALE_DURATION >>=20 >> >=20 >> > s9.1: Remove empty second bullet. >>=20 >> Was gone already >>=20 >> >=20 >> > Titles of ss9.1, 9.2 and 9.3: I Think these should be "Operations = on...." >>=20 >> Changed >>=20 >> >=20 >> > 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? >>=20 >> Added " e.g., a few seconds to a minute;" >>=20 >>=20 >>=20 >> >=20 >> > ss9.2, 9.3: It would be useful to add a forward ref to s12 where = the value of >> > STALE_DURATION is defined. >>=20 >> Done per the above comment >>=20 >> Many thanks again Elwyn! >>=20 >> I'm publishing right away as version 15 so people do not suffer from = those nits again. >>=20 >> All the best >>=20 >> Pascal=20 >>=20 >>=20 >>=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_A8BC16EC-3411-4FA5-9D92-B4B50063FD73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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) <pthubert@cisco.com> = 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=C3=A9vr. 2020 =C3=A0 20:47, = elwynd <elwynd@googlemail.com> a =C3=A9crit :

=EF=BB=BF
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)" <pthubert@cisco.com> =
Date: 07/02/2020 13:36 (GMT+00:00)
To: Elwyn Davies <elwynd@dial.pipex.com>, gen-art@ietf.org
Cc: last-call@ietf.org, draft-ietf-6lo-backbone-router.all@ietf.org, 6lo@ietf.org
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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_A8BC16EC-3411-4FA5-9D92-B4B50063FD73--