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

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 <barryleiba@computer.org> 
Sent: Monday, August 30, 2021 8:20 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: John C Klensin <john-ietf@jck.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; last-call@ietf.org; IESG <iesg@ietf.org>
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

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

On Mon, Aug 30, 2021 at 1:01 PM Giuseppe Fioccola <giuseppe.fioccola@huawei.com> wrote:
>
> 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 <last-call-bounces@ietf.org> On Behalf Of John C 
> Klensin
> Sent: Monday, August 30, 2021 6:25 AM
> To: Brian E Carpenter <brian.e.carpenter@gmail.com>
> Cc: last-call@ietf.org; Barry Leiba <barryleiba@computer.org>; IESG 
> <iesg@ietf.org>
> 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 <brian.e.carpenter@gmail.com> 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
>
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call