Many thanks, Rob.






Best Regards,



Xiao Min









Original



From: RobWilton(rwilton) <rwilton@cisco.com>
To: 肖敏10093570;
Cc: ippm-chairs@ietf.org <ippm-chairs@ietf.org>;iesg@ietf.org <iesg@ietf.org>;ippm@ietf.org <ippm@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;
Date: 2022年11月07日 15:22
Subject: RE: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)






HI Xiao Min,


 


Thanks for accommodating my concerns.  I’ve cleared my discuss.


 


Regards,


Rob


 


 




From: xiao.min2@zte.com.cn <xiao.min2@zte.com.cn> 
 Sent: 07 November 2022 01:57
 To: Rob Wilton (rwilton) <rwilton@cisco.com>
 Cc: ippm-chairs@ietf.org; iesg@ietf.org; ippm@ietf.org; draft-ietf-ippm-ioam-conf-state@ietf.org
 Subject: Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)




 


Hi Robert,


 


The I-D submission tool reopens and I've posted -08 revision. Link as below.


https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-08


Much appreciated if you would check it over to see whether your DISCUSS point has been addressed.


 


P.S. I just realize that I used a wrong email address while firstly replying to your comments, sorry for the inconvenience.


 


Best Regards,


Xiao Min

 


Original



From: 肖敏10093570



To: noreply@ietf.org <noreply@ietf.org>;



Cc: ippm-chairs@ietf.org <ippm-chairs@ietf.org>;iesg@ietf.org <iesg@ietf.org>;ippm@ietf.org <ippm@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;



Date: 2022年10月28日 10:45



Subject: Re: [ippm] Robert Wilton's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)




_______________________________________________
 ippm mailing list
 ippm@ietf.org
 https://www.ietf.org/mailman/listinfo/ippm

Hi Robert,

 


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: RobertWiltonviaDatatracker <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月27日 15:23



Subject: Robert Wilton's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)




Robert Wilton has entered the following ballot position for
 draft-ietf-ippm-ioam-conf-state-07: Discuss
 
 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/
 
 
 
 ----------------------------------------------------------------------
 DISCUSS:
 ----------------------------------------------------------------------
 
 Hi,
 
 I support Roman and Warren's discuss, and again, I have a similar, but slightly
 separate concern:
 
 (1) p 14, sec 6.  Security Considerations
 
    To protect against unauthorized sources using echo request messages
    to obtain IOAM Capabilities information, it is RECOMMENDED that
    implementations provide a means of checking the source addresses of
    echo request messages against an access list before accepting the
    message.
 
 I'm concerned that performing a source address filtering isn't necessarily that
 secure, compared with use NETCONF or RESTCONF that can provide AAA access
 controls.  Hence, I think that the security considerations should REQUIRE that
 IOAM daemons do not respond to these capability requests unless explicitly
 configured to do so, specifically to avoid implementations potentially leaking
 information if they are not aware of this functionality (e.g., if it was
 enabled by default).

[XM]>>> OK. Propose to add a new paragraph into the security section as below.


NEW

   A deployment MUST support the configuration option to enable/disable the IOAM Capabilities Discovery feature defined in this document. By default, the IOAM Capabilities Discovery feature MUST be disabled.



 ----------------------------------------------------------------------
 COMMENT:
 ----------------------------------------------------------------------
 
 (2) p 2, sec 1.  Introduction
 
    *  When NETCONF/YANG is used in this scenario, each IOAM
       encapsulating node (including the host when it takes the role of
       an IOAM encapsulating node) needs to implement a NETCONF Client,
       each IOAM transit and IOAM decapsulating node (including the host
       when it takes the role of an IOAM decapsulating node) needs to
       implement a NETCONF Server, the complexity can be an issue.
       Furthermore, each IOAM encapsulating node needs to establish
       NETCONF Connection with each IOAM transit and IOAM decapsulating
       node, the scalability can be an issue.
 
 Isn't it quite likely that the network devices in question has already
 implement NETCONF servers, and hence really the additional code would only be
 NETCONF client code.  There is also a separate option that RESTCONF could be
 used instead of NETCONF, which is a somewhat lighter protocol.  I believe that
 one big advantage to using NETCONF over these loopback mechanisms is that they
 are properly secure, and NACM can be used to limit access to the IOAM
 capabilities to only those devices/individuals which should be allowed to

access the data.

[XM]>>> I understand this paragraph might be undesirable to you (as NETCONF AD), so I believe it's helpful to retrospect the journey of this paragraph.

As I recall it, there were two wg adoption calls for this draft before it's adopted, this paragraph was added between the two calls, because the proposal to use NETCONF was raised during the first adoption call. There were some heated discussions on whether to use NETCONF or Echo Request/Reply, and the wg (rough) consensus was that Echo Request/Reply is more appropriate. Since then this paragraph remains there.

From my personal perspective I'm unwilling to reopen this discussion at this point.

If you have any suggestions on changing the text of this paragraph, or even removing it, please let me know :-)



 Regards,
 Rob