Last Call Review of draft-ietf-i2rs-ephemeral-state-19
review-ietf-i2rs-ephemeral-state-19-opsdir-lc-morand-2016-11-03-00

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.

Regards,

Lionel

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

_________________________________________________________________________________________________________________________

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.