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

"Susan Hares" <shares@ndzh.com> Thu, 27 October 2016 12:28 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DAA12946F; Thu, 27 Oct 2016 05:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeNUP6vkSnew; Thu, 27 Oct 2016 05:28:31 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260F1129507; Thu, 27 Oct 2016 05:28:22 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.87.48;
From: Susan Hares <shares@ndzh.com>
To: 'Benoit Claise' <bclaise@cisco.com>, 'The IESG' <iesg@ietf.org>
References: <147756978661.24643.15919752806670541040.idtracker@ietfa.amsl.com> <327101d2304a$0f7bf220$2e73d660$@ndzh.com> <195afd1c-5ca3-6ec3-3927-fe0aaf65bdd7@cisco.com>
In-Reply-To: <195afd1c-5ca3-6ec3-3927-fe0aaf65bdd7@cisco.com>
Date: Thu, 27 Oct 2016 08:26:23 -0400
Message-ID: <33e401d2304d$55377ac0$ffa67040$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQF7esXTuTJLyJcbZQYOx+Iy4htfKgGMo6UYApPayP+hSJ/h8A==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/8v8qi3Sd-M4R0eAykzUOxnPlIkE>
Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org, lionel.morand@orange.com
Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Oct 2016 12:28:33 -0000

Benoit: 

It is the timing that is problematic.   With a late discuss, I have no
ability to respond.   With no ability to respond, this gets delayed until
after IETF 97.    I hope Version 21 addresses your DISCUSS comments.  

Sue 

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Thursday, October 27, 2016 8:09 AM
To: Susan Hares; 'The IESG'
Cc: lionel.morand@orange.com; jclarke@cisco.com;
draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org;
i2rs@ietf.org; Benoit Claise
Subject: Re: [i2rs] Benoit Claise's Discuss on
draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT)

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:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise
> Sent: Thursday, October 27, 2016 8:03 AM
> To: The IESG
> Cc: lionel.morand@orange.com; jclarke@cisco.com; 
> draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; 
> i2rs@ietf.org
> 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
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
> .
>