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

["Susan Hares" <[e-mail]>]

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