Dear Paul
Many thanks for your review! please see below:
>
> I share the concerns of Ketan and Mohamed regarding the normative use of an
> individual internet draft that has no IETF consensus. It would be better if
>
This is not the case. The ref is informational and the needed text is
repeated locally, exactly to avoid the above, as follows:
In addition, the terms "Extends" and "Amends" are used as a more
specific term for "Updates" per [I-D.kuehlewind-update-tag] section 3
as follows:
*Amends/Amended by:* This tag pair is used with an amending RFC that
changes the amended RFC. This could include bug fixes,
behavior changes etc. This is intended to specify mandatory
changes to the protocol. The goal of this tag pair is to
signal to anyone looking to implement the amended RFC that
they MUST also implement the amending RFC.
*Extends/Extended by:* This tag pair is used with an extending RFC
that defines an optional addition to the extended RFC. This
can be used by documents that use existing extension points or
clarifications that do not change existing protocol behavior.
This signals to implementers and protocol designers that there
are changes to the extended RFC that they need to consider but
not necessarily implement.
only RFCs that are "updated" (as opposed to "extended") are given the
> Update:
> flag
WFM. I'll comply with the overall recommendation that you guys give us
draft writers.
I've been in a circle doing what you're suggesting, then having a normative
ref to Mirja'd draft (eg draft-ietf-roll-dao-projection-40 - Root-initiated
Routing State in RPL
<https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/>), then
making it informational ( RFC 9685: Listener Subscription for IPv6 Neighbor
Discovery Multicast and Anycast Addresses
<https://www.rfc-editor.org/rfc/rfc9685.html> ) and then back.
> The Update: tag also lists more RFCs than mentioned in the Abstract, so it
> seems something is still missing?
>
Hum... I fail to understand that one as well. All 8 RFCs tagged as
"updated" are listed in the abstract.
>
> I am not a topic expert on this, so I hope the next two questions make
> sense.
> But:
>
> In Figure 4, why is the F bit taken from the next 4 bytes, while there is
> still
> room in the Reserved space before that?
>
>
See my proposal to Ketan in this thread.
> In Figure 5, what was taken up by the space of the F bit before this? It
> seems
> unlikely there was only a single unused bit there?
>
> The byte was reserved in EARO used in NS messages and used for a status in
the response in NA messages.
Now we use is in NA messages for one flag + 7-bits prefix length .
Many thanks again!
Pascal
--
Pascal
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]
