Subject: Re: [Last-Call] Last Call: RFC 8321 (Alternate-Marking Method for Passive and Hybrid Performance Monitoring) and RFC 8889 (Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring)to Proposed Standard

From: Barry Leiba <[email-masked]>
Date: Sun, 29 Aug 2021 12:51:38 -0400

I don't understand how we can reclassify Experimental RFCs to Proposed
Standard without re-issuing them with a new RFC number, as the
boilerplate is incompatible.  Specifically, the "Status of This Memo"
section says:

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.

The status-change reclassification is for reclassification in place
(as when we move from Proposed Standard to Internet Standard, or from
any status to Historical).  But to move Experimental to Proposed
Standard, it seems to me that we need a new Internet Draft that
Obsoletes the Experimental RFC, with normal processing of that draft
and publication as a new RFC.

Barry

On Fri, Aug 27, 2021 at 5:08 PM The IESG <[email-masked]> wrote:
>
> The IESG has received a request from an Area Director to make the
> following status changes:
>
> - RFC8321 from Experimental to Proposed Standard
>     (Alternate-Marking Method for Passive and Hybrid Performance Monitoring)
>
> - RFC8889 from Experimental to Proposed Standard
>     (Multipoint Alternate-Marking Method for Passive and Hybrid Performance
>     Monitoring)
>
> The supporting document for this request can be found here:
>
> https://datatracker.ietf.org/doc/status-change-rfc8321-rfc8889-alt-mark-to-ps/
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-09-24. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> The affected documents can be obtained via
> https://datatracker.ietf.org/doc/rfc8321/
> https://datatracker.ietf.org/doc/rfc8889/
>
> IESG discussion of this request can be tracked via
> https://datatracker.ietf.org/doc/status-change-rfc8321-rfc8889-alt-mark-to-ps/ballot/
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 29 Aug 2021 10:00:50 -0700

FWIW, I would also expect a summary report on the “experiment”, i.e., what is known now that wasn’t known then.

For RFCs issued under 6 months ago, it seems unlikely things would change that much.

Joe

> On Aug 29, 2021, at 9:51 AM, Barry Leiba <[email-masked]> wrote:
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: John C Klensin <[email-masked]>
Date: Sun, 29 Aug 2021 16:26:53 -0400

FWIW, I strongly concur.  Everyone participating in the IETF who
has been concerned about, or had to listen to people complaining
about, non-standards-track RFC being marketed as standards
should think about the boon this would be to those inclined to
do such things if we start providing worked examples of RFCs
that clearly say "Experimental" and "Not a Standard" being
standards after all.

And, like Joe, I'd expect to see a formal report on the
experiment and is outcome before any action is taken on this or
a replacement document.

   john

--On Sunday, August 29, 2021 12:51 -0400 Barry Leiba
<[email-masked]> wrote:

> I don't understand how we can reclassify Experimental RFCs to
> Proposed Standard without re-issuing them with a new RFC
> number, as the boilerplate is incompatible.  Specifically, the
> "Status of This Memo" section says:
> 
>    This document is not an Internet Standards Track
> specification; it is    published for examination,
> experimental implementation, and    evaluation.
> 
>    This document defines an Experimental Protocol for the
> Internet    community.
> 
> The status-change reclassification is for reclassification in
> place (as when we move from Proposed Standard to Internet
> Standard, or from any status to Historical).  But to move
> Experimental to Proposed Standard, it seems to me that we need
> a new Internet Draft that Obsoletes the Experimental RFC, with
> normal processing of that draft and publication as a new RFC.
> 
> Barry
> 
>> The IESG has received a request from an Area Director to make
>> the following status changes:
>> 
>>     (Multipoint Alternate-Marking Method for Passive and
>>     Hybrid Performance Monitoring)
>> 
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action. Please send
>> substantive comments to the [email-masked] mailing lists
>> by 2021-09-24. Exceptionally, comments may be sent to
>> [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Aug 2021 14:23:55 +1200

I also strongly concur. It is very close to trivial to issue these two documents as I-Ds with standards track boilerplate and give them a 4-week last call. That would conform to our process and avoid an extremely confused and confusing end state. A report on their experimental use would be a useful adjunct to that last call.

Maybe it would be quicker to use the normal downref mechanism, since draft-mirsky-bier-pmmm-oam wants it.

Regards
   Brian Carpenter

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Aug 2021 00:25:23 -0400

--On Monday, August 30, 2021 14:23 +1200 Brian E Carpenter
<[email-masked]> wrote:

> I also strongly concur. It is very close to trivial to issue
> these two documents as I-Ds with standards track boilerplate
> and give them a 4-week last call. That would conform to our
> process and avoid an extremely confused and confusing end
> state. A report on their experimental use would be a useful
> adjunct to that last call.
> 
> Maybe it would be quicker to use the normal downref mechanism,
> since draft-mirsky-bier-pmmm-oam wants it.

Brian,

A downref to a standards track document, especially one we
believe is stable (and maybe even deployed and interoperable)
but that no one has gone to the effort to advance is one thing.
Maybe I'm being over-rigid, but a downref to an explicitly
experimental document without even an experimental outcome
report seems to violate basic principles about stable
references.  

AFAIKT, no Last Call has been issued on draft-ietf-bier-pmmm-oam
(formerly draft-mirsky-bier-pmmm-oam).  Why not just spin up
I-Ds to replace RFCs 8321 and 8889 and do this in an orderly
fashion?  

   john

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 30 Aug 2021 17:01:32 +0000

Hi All,
I just want to clarify the background. The debate started since draft-ietf-6man-ipv6-alt-mark has been submitted to IESG for publication as Proposed Standard. To avoid downref, the current solution adopted in draft-ietf-6man-ipv6-alt-mark was to take some text from RFC 8321 / RFC 8889 and move into draft-ietf-6man-ipv6-alt-mark so that it can be elevated to PS. 
But this approach was considered suboptimal during the IESG evaluation and it was proposed to elevate RFC 8321 and RFC 8889 to PS.

Regarding the maturity of RFC 8321 / RFC 8889, I want to add that the experiment, started in 2010, is now done. Indeed Alternate Marking is implemented by vendors (e.g. Huawei, Cisco, ZTE, Broadcom..) and deployed by operators (Telecom Italia, China Mobile, China Unicom..) as also confirmed by the answers to the poll launched by Martin Duke two weeks ago on the IPPM mailing list.

Regards,

Giuseppe

-----Original Message-----
From: last-call <[email-masked]> On Behalf Of John C Klensin
Sent: Monday, August 30, 2021 6:25 AM
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]; Barry Leiba <[email-masked]>; IESG <[email-masked]>
Subject: Re: [Last-Call] Last Call: RFC 8321 (Alternate-Marking Method for Passive and Hybrid Performance Monitoring) and RFC 8889 (Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring)to Proposed Standard

--On Monday, August 30, 2021 14:23 +1200 Brian E Carpenter <[email-masked]> wrote:

> I also strongly concur. It is very close to trivial to issue these two 
> documents as I-Ds with standards track boilerplate and give them a 
> 4-week last call. That would conform to our process and avoid an 
> extremely confused and confusing end state. A report on their 
> experimental use would be a useful adjunct to that last call.
> 

Brian,

A downref to a standards track document, especially one we believe is stable (and maybe even deployed and interoperable) but that no one has gone to the effort to advance is one thing.
Maybe I'm being over-rigid, but a downref to an explicitly experimental document without even an experimental outcome report seems to violate basic principles about stable references.  

AFAIKT, no Last Call has been issued on draft-ietf-bier-pmmm-oam (formerly draft-mirsky-bier-pmmm-oam).  Why not just spin up I-Ds to replace RFCs 8321 and 8889 and do this in an orderly fashion?  

   john

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Aug 2021 14:20:06 -0400

Thanks for the background information, Giuseppe.

To be clear, none of us who have commented are saying that we don't
think RFCs 8321 and 8889 are ready to move to PS.  We're just saying
that the "status change" mechanism isn't the appropriate way to do it,
and that it should be done with new I-Ds that go into IETF last call
through the normal I-D process.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Aug 2021 14:02:12 +1200

> report seems to violate basic principles about stable

I agree it probably isn't what BCP97 intended, but there
is at least one precedent in the downref registry (RFC 3973).
However, I do prefer the other solution.

   Brian

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 31 Aug 2021 09:42:59 +0000

Hi Barry,
I see your point. Maybe we can go ahead with draft-ietf-6man-ipv6-alt-mark as PS and, meanwhile, we can work on a new Standard Track I-D on RFC8321bis and RFC8889bis to be used as reference.

Regards,

Giuseppe

-----Original Message-----
From: Barry Leiba <[email-masked]> 
Sent: Monday, August 30, 2021 8:20 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: John C Klensin <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]; IESG <[email-masked]>
Subject: Re: [Last-Call] Last Call: RFC 8321 (Alternate-Marking Method for Passive and Hybrid Performance Monitoring) and RFC 8889 (Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring)to Proposed Standard

To be clear, none of us who have commented are saying that we don't think RFCs 8321 and 8889 are ready to move to PS.  We're just saying that the "status change" mechanism isn't the appropriate way to do it, and that it should be done with new I-Ds that go into IETF last call through the normal I-D process.

Barry

On Mon, Aug 30, 2021 at 1:01 PM Giuseppe Fioccola <[email-masked]> wrote:
> Subject: Re: [Last-Call] Last Call: RFC 8321 (Alternate-Marking Method 
> for Passive and Hybrid Performance Monitoring) and RFC 8889 
> (Multipoint Alternate-Marking Method for Passive and Hybrid 
> Performance Monitoring)to Proposed Standard
>
>
>
> > I also strongly concur. It is very close to trivial to issue these 
> > two documents as I-Ds with standards track boilerplate and give them 
> > a 4-week last call. That would conform to our process and avoid an