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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
