Last Call Review of draft-ietf-i2rs-ephemeral-state-19

Request Review of draft-ietf-i2rs-ephemeral-state
Requested rev. no specific revision (document currently at 23)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-10-25
Requested 2016-10-06
Authors Jeffrey Haas, Susan Hares
Draft last updated 2016-11-03
Completed reviews Opsdir Last Call review of -19 by Lionel Morand (diff)
Rtgdir Early review of -02 by Joel Halpern (diff)
Assignment Reviewer Lionel Morand
State Completed
Review review-ietf-i2rs-ephemeral-state-19-opsdir-lc-morand-2016-11-03
Reviewed rev. 19 (document currently at 23)
Review result Serious Issues
Review completed: 2016-11-03


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document: draft-ietf-i2rs-ephemeral-state-19
Summary:   This document describes the requirements for the support for ephemeral state in the I2RS protocol, which can be supported by NETCONF/RESTCONF and the related impacts on the YANG model, the NETCONF and RESTCONF protocols.
Main feedback:

The rational for this document is unclear. It is somehow positioned between the high-level requirements given in the RFC7921 and a future document that will further investigate the impacts on YANG, NETCONF and RESTCONF. Some of the critical requirements listed in this draft seem to challenge the current design of YANG model and NETCONF/RESTCONG protocols and then jeopardize the whole basic assumption of "re-use" highlighted in the RFC7921.
IMHO, it would be more useful to capture in a single document the specific requirements on ephemeral state, impacts on YANG/NETCONG/RESTCONF and the conclusion on the feasibility/required enhancements.

Detailed review provided below.



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
[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

[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?


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.