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

Paul Wouters <paul.wouters@aiven.io> Fri, 28 October 2022 14:35 UTC

Content-Type: multipart/alternative; boundary="Apple-Mail-A480D230-F0BD-4AB3-B80F-948339930741"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul.wouters@aiven.io>
Mime-Version: 1.0 (1.0)
Date: Fri, 28 Oct 2022 10:35:20 -0400
Message-Id: <F06781BA-FB58-431A-8C4A-97CAF910E5CB@aiven.io>
References: <202210281014303170486@zte.com.cn>
Cc: iesg@ietf.org, draft-ietf-ippm-ioam-conf-state@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com
In-Reply-To: <202210281014303170486@zte.com.cn>
To: xiao.min2@zte.com.cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Lb7xPue32v79KWij8rCVdzbfGPU>
Subject: Re: [ippm] Paul Wouters' No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)
Precedence: list

Thank you for the changes !

Paul

Sent using a virtual keyboard on a phone

> On Oct 27, 2022, at 22:15, xiao.min2@zte.com.cn wrote:
> 
> 
> Hi Paul,
> 
> 
> 
> Following the discussion with John Scudder, I've updated the proposed changes corresponding to your comments.
> 
> Please check inline the new proposed changes. Sorry for the inconvenience.
> 
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> Original
> From: 肖敏10093570
> To: paul.wouters@aiven.io <paul.wouters@aiven.io>;
> Cc: The IESG <iesg@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;
> Date: 2022年10月26日 15:27
> Subject: Re: Paul Wouters' No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)
> 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
> 
> 
> 
> From: PaulWoutersviaDatatracker <noreply@ietf.org>
> To: The IESG <iesg@ietf.org>;
> Cc: draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;
> 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.
> 
> [XM-2]>>> Will use your text "and MUST be ignored when non-zero", and remove "whether all the reserved fields are set to zero" from the penultimate paragraph of the security section.
> 
> 
> 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.
> 
>

[ippm] Paul Wouters' No Objection on draft-ietf-i… Paul Wouters via Datatracker
Re: [ippm] Paul Wouters' No Objection on draft-ie… xiao.min2
Re: [ippm] Paul Wouters' No Objection on draft-ie… xiao.min2
Re: [ippm] Paul Wouters' No Objection on draft-ie… Paul Wouters
Re: [ippm] Paul Wouters' No Objection on draft-ie… xiao.min2