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) <pthub...@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évr. 2020 à 20:47, elwynd <elw...@googlemail.com> 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)" <pthub...@cisco.com> >> Date: 07/02/2020 13:36 (GMT+00:00) >> To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org >> Cc: last-c...@ietf.org, draft-ietf-6lo-backbone-router....@ietf.org, >> 6...@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
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
