Re: [ippm] RFC8321bis and 8889bis

[Giuseppe Fioccola <[e-mail]>]

Hi Tom,
It is a good suggestion. We can definitely make a summary of the experiment and therefore highlight the few parts of the RFC that are not carried forward.

Regards,

Giuseppe

-----Original Message-----
From: tom petch <[e-mail]> 
Sent: Wednesday, September 8, 2021 10:04 AM
To: Giuseppe Fioccola <[e-mail]>; Martin Duke <[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: Giuseppe Fioccola <[e-mail]>
Sent: 07 September 2021 11:15

Hi Tom,
Yes, that's exactly the plan.
Regarding RFC8321, the first four sections will remain almost unchanged, while the subsequent sections (5, 6, 7) need some modifications.
Besides, RFC8889 does not define new bits but it basically describes the general way of aggregating counters and timestamps for multipoint unicast flows in order to allow flexible monitoring. This can be kept in the same document or can be separated, depending on the debate.

<tp>

For me, I would keep the documents separate.  I see it as more straightforward, less likely to introduce errors which, as I said before, are often what determines how long something takes. 

Also, I think that any ...bis should include a section on the changes from the RFC, especially here as it is likely that parts of the RFC are not carried forward.  It might be tempting to put these parts in an Informative Appendix but, for me, that would give them too much weight and a summary of what has been removed would be better IMHO.

Tom Petch
.
Regards,

Giuseppe


-----Original Message-----
From: tom petch <[e-mail]>
Sent: Tuesday, September 7, 2021 10:34 AM
To: Giuseppe Fioccola <[e-mail]>; Martin Duke <[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: Giuseppe Fioccola <[e-mail]>
Sent: 05 September 2021 22:53

Hi Tom, All,
Note that, in this specific case, the new I-D will not add nothing more to the original RFC 8321 and RFC 8889. It will elevate Alternate Marking to Proposed Standard by picking only the deployed methods from the two RFCs. Therefore, it will be reused most of the text and omitted the parts related to the experiment.
For this reason, I'm just trying to figure out what can be the fastest way to progress.
Probably Martin, Ian and Tommy could give important advices here.

<tp>
The fastest way is the one that makes the fewest mistakes:-)

I see very little in RC8321 that is about an experiment. and what there is will mostly vanish when the Category is changed.
   Rather the key part I see is going through sections 5, 6, and 7 and removing the parts that are not ready to be elevated to Standards Track.  I think that the most reliable way to do that is to start with RFC8321, change the Category and then review those three sections to see what can be kept, what must go.  That is where the WG comes in, rather than AD or WG Chairs,  to give consensus to that IMHO.  Some of this has happened already in the posts in support of this status change but I think we need that 8321bis to work from and make it formal.

Tom Petch

Regards,

Giuseppe

-----Original Message-----
From: tom petch <[e-mail]>
Sent: Saturday, September 4, 2021 1:22 PM
To: Giuseppe Fioccola <[e-mail]>; Martin Duke <[e-mail]>; IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: ippm <[e-mail]> on behalf of Giuseppe Fioccola <[e-mail]>
Sent: 04 September 2021 08:08

Hi Martin, All,
I can surely start working on a bis document and lead it together with those who already expressed interest.
I'm just wondering if the new I-D on RFC8321bis and RFC8889bis can be submitted directly to IESG as individual submission with the help of a sponsoring AD or as IPPM WG document.
What's your thought?

<tp>

Two WG documents.  Anything else creates more work for an AD and may lead to procedural  issues - e.g. lack of IETF consensus - at a later date.

Tom Petch
an interested bystander.

Regards,

Giuseppe


From: ippm <[e-mail]> On Behalf Of Martin Duke
Sent: Friday, September 3, 2021 5:55 PM
To: IETF IPPM WG <[e-mail]>
Subject: [ippm] RFC8321bis and 8889bis

Hello IPPM,

Last Call on the status change still has some way to run, but there is already quite a bit of resistance to doing this without a bis document.

Consider this a formal invitation to get the process started. A bis document should eliminate both experiment-related boilerplate, and any bits of the design that we don't feel are mature enough for Proposed Standard.

Submit a -00!
Thanks
Martin