Benoit Claise has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-23: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My previous DISCUSS, which was ... I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state. I should be missing something. Examples would help me. ... as been solved with Sue's email: “This change difference was suggested by Juergen and Andy as two separate cases rather than the original one. Juergen and Andy have been concerned about the speed of testing constraints that are in the operational state if the operational state yang variables are fast changing and short-lived. They believe this requirement might not be doable in implementations. They wanted this split out from Ephemeral-REQ-04 that simply states that ephemeral state MUST be able to refer to non-ephemeral state (configuration or operational state). Since we do not know if the I2RS can handle the fast changing and short-lived ephemeral state, I think this split is a good one.” - Just one comment from Lionel's OPS DIR feedback left, that might need some clarifications. Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: o the data nodes MAY store I2RS client identity and not the effective priority at the time the data node is stored. [LM] This requirement seems to be in contradiction with the one given in section 2 i.e. "I2RS agent MUST record the client identity when a node is created or modified.". If I'm correct, the "MAY" applies only to the "effective priority" and not to the I2RS Id storage. [Sue]: I do not understand your point. The "MAY" Deals with the fact the implementation may attach a priority to the I2RS client and choose to only store the link to the I2RS client. What is the concern here? _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
