[mpls] Re: Warren Kumari's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)

[[e-mail]]

Hi Warren,
Thanks for your review and comments.
Please see inline.


Original


From: WarrenKumariviaDatatracker <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年09月04日 08:02
Subject: Warren Kumari's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)


Warren Kumari has entered the following ballot position for
draft-ietf-mpls-inband-pm-encapsulation-15: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
Ooof, this is a hard one...
 
While balloting I have repeatedly cycled between DISCUSS, Abstain, and No
Objection.
 
This text makes me want to Abstain like Eric:
"Note that in parallel to the work of this document, there is ongoing
work on MPLS Network Actions (MNA) [I-D.ietf-mpls-mna-fwk].
Considering the MPLS performance measurement with the Alternate-
Marking method can also be achieved by MNA encapsulation, it is
agreed that this document will be made Historic once the MNA solution
of performance measurement with the Alternate-Marking method is
published as an RFC." 
It feels distinctly weird for a document to be published with a built in
expiration date -- but this is tempered by the fact that 1: there is
(apparently) WG consensus behind this and 2: there are implementations, so...
well, I finally decided to not Abstain.
 [XM]>>> Understood. Thank you!


I very strongly agree with Roman on:
"Why is the SHOULD in (b), (c) and (d) not a MUST?
 [XM]>>> As I've responded to John and Roman, the SHOULD in (b), (c) and (d) will be replaced by MUST in the next revision.


If (a) mandates that there is no signaling of the Flow-ID outside of the
administrative domain, (b) and (c) should be mandatory to enforce that policy." 
... but he is already carrying the DISCUSS. While I could also ballot DISCUSS on
this point, I feel that this would be redundant, and so I'll jsut note that I
am supporting his position. The same goes for John Scudder's DISCUSS, both on
the limited number of flows, and the PHP issue.
 [XM]>>> Understood. Will address Roman's and John's DISCUSSes.


I'd also like to thank Daniele Ceccarelli for the Ops-Dir review
(https://datatracker.ietf.org/doc/review-ietf-mpls-inband-pm-encapsulation-14-opsdir-lc-ceccarelli-2024-08-23/)
and the authors for engaging.
 
 Best Regards,
Xiao Min