Re: [ippm] Paul Wouters' No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)

[[e-mail]]

Hi Paul,






Thank you for the review and thoughtful comments.


Please check inline the proposed changes that will be incorporated into the next revision.





Best Regards,


Xiao Min







Original



From: PaulWoutersviaDatatracker <[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]>;
Date: 2022年10月26日 07:53
Subject: Paul Wouters' No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)


Paul Wouters has entered the following ballot position for
draft-ietf-ippm-ioam-conf-state-07: 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-ippm-ioam-conf-state/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
Thanks to Chris Lonvick for the SecDir review. He raised a few points that are
worth addressing:
https://datatracker.ietf.org/doc/review-ietf-ippm-ioam-conf-state-05-secdir-lc-lonvick-2022-09-30/
 
   Reserved field is reserved for future use and MUST be set to zero.
 
Can this be extended to say "and MUST be ignored when non-zero" ? There is more
than one of these.

[XM]>>> Yes, I think this can be extended. I propose s/and MUST be ignored when non-zero/and SHOULD be ignored when non-zero, the reason is that in the penultimate paragraph of the security section it indicates that the receiver can also report an exception event to the management when non-zero. I'll take care of all the places where the extended text is needed.


Why is the SoP field specified as two bits from a reserved field, when it only
uses one bit? Why not just take one bit from the reserved field?
 [XM]>>> The reason is that in section 4.5.1 of RFC 9197 it says

Note: Larger or smaller sizes of "PktID" and "Cumulative" data are feasible and could be required for certain deployments, e.g., in case of space constraints in the encapsulation protocols used. Future documents could introduce different sizes of data for "Proof of Transit".

Assume the future documents introduce one larger size and one smaller size, then one bit seems not enough.