Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT)

[Benoit Claise <[e-mail]>]

Understood Sue. Nobody is asking the impossible.
Also, let's not forget that a DISCUSS should serve as discussion points.

Regards, Benoit
> Benoit:
>
> I will be glad to address these comments.  It is a little difficult when
> they come at 7:44am on Thursday morning.
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:[e-mail]] On Behalf Of Benoit Claise
> Sent: Thursday, October 27, 2016 8:03 AM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: [i2rs] Benoit Claise's Discuss on
> draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT)
>
> Benoit Claise has entered the following ballot position for
> draft-ietf-i2rs-ephemeral-state-20: 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/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/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> -
>     The I2RS Working Group has chosen to use the YANG data modeling
>     language [RFC6020] as the basis to implement its mechanisms.
>
> I guess you mean RFC 7950.
> RFC7950 should be a normative reference.
>
>
> -
> I read the abstract and title: clearly this is about ephemeral state.
>
>                    I2RS Ephemeral State Requirements
>                   draft-ietf-i2rs-ephemeral-state-19.txt
>
> Abstract
>
>     The I2RS (interface to the routing system) Architecture document
>     (RFC7921) abstractly describes a number of requirements for ephemeral
>     state (in terms of capabilities and behaviors) which any protocol
>     suite attempting to meet the needs of I2RS has to provide.  This
>     document describes, in detail, requirements for ephemeral state for
>     those implementing the I2RS protocol.
>
> And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's
> DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client.
> Why (re-hashing) requirements not related to ephemeral?
> What the goal of this section 2?
> It seems more like adding confusing that being helpful. Too many
> requirements from different documents in I2RS: "distilling" them between
> documents is looking for troubles.
> note: section 9 title "
> Pub/Sub Requirements Expanded for Ephemeral State" and content area clear
>
>
>
>
> - 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.
>
> - Clarification:
> Ephemeral-REQ-12: When a collision occurs as two clients are trying
>     to write the same data node
>
> I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients?
> Note: multiple instances of "clients" (as opposed to I2RS clients) in the
> doc.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Editorial:
> - Section 5 versus 6
> For NETCONF:
>     2.  The ephemeral state MUST support notification of write conflicts
>         using the priority requirements defined in section 7 below (see
>         requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
> For RESTCONF:
>     2.  The ephemeral state must support notification of write conflicts
>         using the priority requirements defined in section 7 below (see
>         requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
>
> must versus MUST. If there are some language subtleties here, I didn't grasp
> them.
>
> - "To support Multi-Headed Control,"
> Multi-Headed Control? I guess I know what you mean, but expressed like this
> (capitalized), I'm looking for a well-known, well-defined term.
> Later on, I see "Multi-headed control"
>
> - s/yang/YANG
>
> -
>     Ephemeral-REQ-11: The following requirements must be supported by the
>     I2RS protocol I2RS Protocol
>
> remove one "I2RS protocol" instance
>
> -
>     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:
>
> I would remove: "(e.g.  NETCONF/RESTCONF + yang)"
>
>
> - "MUST BE" = MUST Belgium :-)
>
> Pretty good feedback from Lionel Morand's OPS DIR review:
>
> 1. Introduction
>
>     The I2RS Working Group has chosen to use the YANG data modeling
>     language [RFC6020] as the basis to implement its mechanisms.
>
>     Additionally, the I2RS Working group has chosen to re-use two
>     existing protocols, NETCONF [RFC6241] and its similar but lighter-
>     weight relative RESTCONF [I-D.ietf-netconf-restconf], as the
>     protocols for carrying I2RS.
>
>     What does re-use of a protocol mean?  Re-use means that while YANG,
>     NETCONF and RESTCONF are a good starting basis for the I2RS protocol,
>     the creation of the I2RS protocol implementations requires that the
>     I2RS requirements
>
>     1.  select features from YANG, NETCONF, and RESTCONF per version of
>         the I2RS protocol (See sections 4, 5, and 6)
>
>     2.  propose additions to YANG, NETCONF, and RESTCONF per version of
>         the I2RS protocol for key functions (ephemeral state, protocol
>         security, publication/subscription service, traceability),
>
>     The purpose of these requirements is to ensure clarity during I2RS
>     protocol creation.
>
> [LM] The aim of the document is not so clear. The working assumption is :
> re-use but with "addition".
> What does addition mean? Who is in charge to check that the proposed
> "additions" can be supported by YANG/NETCONF/RESTCONF without protocol
> updates? Where is the need to first derive specific requirements from
> RFC7921 and then check if they can be fulfilled by the model and the
> protocols, instead of doing both in the same document?
>
> 2.  Review of Requirements from I2RS architecture document
>
>     The I2RS architecture defines important high-level requirements for
>     the I2RS protocol.  The following are requirements distilled from
>     [RFC7921] that provide context for the ephemeral data state
>     requirements given in sections 3-8:
>
> [LM] What is the meaning of "distilled" here? Are these requirements
> explicitly part of the RFC7921 or the requirements listed in this draft may
> be "relative" or even complementary requirements compared to the RFC7921?
>
>     1.  The I2RS protocol SHOULD support a high bandwidth, asynchronous
>         interface, with real-time guarantees on getting data from an I2RS
>         agent by an I2RS client.
>
> [LM] Is it a requirement related to the I2RS protocol or to the transport
> protocol?
>
>     2.  I2RS agent MUST record the client identity when a node is created
>         or modified.  The I2RS agent SHOULD to be able to read the client
>         identity of a node and use the client identity's associated
>         priority to resolve conflicts.  The secondary identity is useful
>         for traceability and may also be recorded.
>
> [LM] I think that the first sentence is not so related to the I2RS protocol
> but rather to the mechanism to provision the I2RS agent with this info (e.g.
> AAA).
>
>     3.  An I2RS Client identity MUST have only one priority for the
>         client's identifier.  A collision on writes is considered an
>         error, but the priority associated with each client identifier is
>         utilized to compare requests from two different clients in order
>         to modify an existing node entry.  Only an entry from a client
>         which is higher priority can modify an existing entry (First
>         entry wins).  Priority only has meaning at the time of use
>
> [LM] If I'm correct, "First entry wins" is for clients associated with the
> same priority, right? If it is, it is not only about 'higher'
> priority.
>
>     4.  I2RS Client's secondary identity data is read-only meta-data that
>         is recorded by the I2RS agent associated with a data model's node
>         is written.  Just like the primary client identity, the secondary
>         identity SHOULD only be recorded when the data node is written.
>
> [LM] Not sure of the relevance of this requirement in the context of the
> I2RS protocol design if this info is opaque for the agent.
>
>     5.  I2RS agent MAY have a lower priority I2RS client attempting to
>         modify a higher priority client's entry in a data model.  The
>         filtering out of lower priority clients attempting to write or
>         modify a higher priority client's entry in a data model SHOULD be
>         effectively handled and not put an undue strain on the I2RS
>         agent.
>    
> [LM] This requirement seems to imply that the priority associated with the
> client ID is transitively associated with the client's entry in the I2RS
> agent. If it is, this requirement should be clarified along with Req
> 3 or just after.
>
> 3.1.  Persistence
>
>     Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
>     not persist across reboots.  If state must be restored, it should be
>     done solely by replay actions from the I2RS client via the I2RS
>     agent.
>
> [LM] this one is related to Req 8 and is about a "MUST" regarding the YANG
> model. As defined in RFC7950 (recently published), there are only two
> flavors of data managed with YANG: configuration data and state data,
> differentiated by the "config" statement with the argument the string "true"
> or "false". This requirement seems to imply a new "flavor" i.e.
> ephemeral state, which seems not compatible with the existing model that
> cannot be accommodated using a Boolean value. Does it mean that a new
> version of the YANG model would be required to fulfil this requirement?
>
> [LM] Most of the other requirements are derived from and/or dependent on the
> req 1.
>
> [LM] Other specific comments:
>
> 5.  NETCONF Features for Ephemeral State
>
>     2.  The ephemeral state MUST support notification of write conflicts
>         using the priority requirements defined in section 7 below (see
>         requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
>
> [LM] I wonder how this impacts the recommendation on the use of
> configuration lock mechanism when it is known that multiple instances may
> update the same configuration data as per RFC6241. Here, it seems that the
> priority is able to override the lock in place, which is not allowed in
> NETCONF.
>
>     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.
>
>     o  The priority MAY be dynamically changed by AAA, but the exact
>        actions are part of the protocol definition as long as collisions
>        are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13,
>        and Ephemeral-REQ-14.
>
> [LM] there are several references to the use of AAA-based solutions for
> priority handling. Does it require any action in RADEXT or Dime to support
> these requirements, at least as a default standard mechanism for I2RS?
>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>
> .
>