RE: Thoughts on draft-bonica-6man-deprecate-router-alert

["BRUNGARD, DEBORAH A" <[e-mail]>]

Barry or Michelle😊

Per RFC8126, IANA defines in section 9.6, "obsolete" (no longer in use) and "deprecated" (use is not recommended). So I would lean to "deprecate". As Ron's IANA section is requesting to change the Destination Options and Hop-by-Hop Options Registry, I think that RFC2711 is applicable for update as it is the one listed by IANA, but nothing preventing adding multiple other documents in the string.

(and whatever propose - I'm sure it will be discussed again by the IESG - two very popular discussion items with many views: "deprecate" and "update")
Deborah


-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Adrian Farrel
Sent: Sunday, January 2, 2022 4:04 PM
To: 'Brian E Carpenter' <[e-mail]>; '6MAN' <[e-mail]>; [e-mail]
Subject: RE: Thoughts on draft-bonica-6man-deprecate-router-alert

Hi Brian,

Shall we argue English language semantics? 😊

>> I believe that the word "deprecate" is wrongly used in this document in that
>> this document does not make the router alert option obsolete.
>
> I disagree. The word "deprecate" has no formal status in the IETF standards
> process, so there is no rule here.

I agree that there is no formal status in the IETF (where is Barry when you need him?), but I disagree that there is "no rule here." Normal English meaning holds.

> One of the Merriam-Webster definitions of "deprecate" is
> "to withdraw official support for or discourage the use of
> (something, such as a software product) in favor of a newer
> or better alternative." That seems to cover this case.

Precisely not!
The draft states clearly that the use by protocols/implementations that already use it may continue.
That is not discouraging the use of.
And it is on that basis that I argue "deprecate" is wrongly used.

> We've used this sense for many years, eg in RFC2578:
> 'While the value "deprecated" also indicates an obsolete definition,
> it permits new/continued implementation in order to foster
> interoperability with older/existing implementations.'

Ah, so you argue precedent to create a de facto formal status for the word? 

Best,
Adrian

PS - I don't *really* care about this, but I hate to see language abused.

On 03-Jan-22 07:28, Adrian Farrel wrote:
> In general, I am not opposed to the idea of "banning" future uses of the
> router alert option in IPv6.
> 
> I believe that the word "deprecate" is wrongly used in this document in that
> this document does not make the router alert option obsolete. Indeed, the
> Abstract says "Protocols that use the Router Alert Option may continue to do
> so." So, let's make the document say what it is saying, viz., "The IPv6
> router alert option is not to be used in any new protocols or any new
> protocol extensions."
> 
> Some nits...
> 
>     *  The control plane sends routing protocol messages through the
>        forwarding plane to other nodes.
> 
> I think it "may" do that, but it can also send routing protocol messages
> through the management plane or the control plane which are not necessarily
> congruent with the forwarding plane.
> (Additionally, this bullet occurs under "The forwarding and control planes
> communicate with one another as follows:" yet this bullet is an example of
> the control plane elements communicating with each us via the forwarding
> plane, not the two planes communicating with each other.)
> 
> ---
> 
> I find a slight difficulty in the term "control plane". I think it would be
> helpful to talk about "control plane components/elements" for the processing
> pieces, and recall that the control plane is those elements *plus* the
> channels between them.
> 
> ---
> 
>     NOTE: In RFC 6398, the terms "fast path" and "control plane
>     components" are used synonymously.
> 
> Are they? I don't think so. "Fast path" relates to processing in the
> forwarding plane. "Control plane components" are on the slow path.
> 
> ---
> 
> Along with RFC 8029, you should probably consider and reference RFC 7506
> 
> ---
> 
> While it is widely agreed that RSVP-TE (i.e., the MPLS control plane use of
> RSVP) implementations should/do not use the router alert option, it is
> hellishly hard to find where that is documented as a prohibition in IPv6 (or
> IPv4). And, of course, the RSVP spec says that you do use it, so a naif
> implementer of RSVP-TE might assume you should (I'm fairly sure one of the
> WGs - MPLS? - did a survey on this, but I can't find it).
> 
> ---
> 
> Section 4 seems a little frail and possibly it is aspirational rather than
> factual.
> 
> ---
> 
> Rather than mark the Router Alert value as Deprecated in
> https://urldefense.com/v3/__https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml*ipv6-__;Iw!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7Qth9DsJs$ 
> parameters-2, isn't what you really want to do is go to
> https://urldefense.com/v3/__https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-va__;!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7QsKtN5aw$ 
> lues.xhtml#ipv6-routeralert-values-1 and make 70-65502 Reserved [RFC8126]
> with a reference to this RFC. That seems more consistent with allowing the
> old uses to continue the way you describe.
> 
> ---
> 
> Best,
> Adrian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7Qkm-rOnU$ 
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!BhdT!yoEZ8-xl8tOuhqG00ndv-RQk9mwVgsftQGiBwgaUb-mC3boiZLzfeD7Qkm-rOnU$ 
--------------------------------------------------------------------