Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt- 2 week WG LC (6/21 to 7/5/2016)

Martin Bjorklund <mbj@tail-f.com> Wed, 29 June 2016 10:49 UTC

Return-Path: <mbj@tail-f.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 C9CCA12DB49 for <i2rs@ietfa.amsl.com>; Wed, 29 Jun 2016 03:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 xFq-5xJIcaUZ for <i2rs@ietfa.amsl.com>; Wed, 29 Jun 2016 03:49:24 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3297E12DA5B for <i2rs@ietf.org>; Wed, 29 Jun 2016 03:49:24 -0700 (PDT)
Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id C55231AE02EF for <i2rs@ietf.org>; Wed, 29 Jun 2016 12:49:21 +0200 (CEST)
Date: Wed, 29 Jun 2016 12:49:46 +0200
Message-Id: <20160629.124946.1123239025236388287.mbj@tail-f.com>
To: i2rs@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <004901d1cbf1$85b87430$91295c90$@ndzh.com>
References: <004901d1cbf1$85b87430$91295c90$@ndzh.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/fijtngvwWH2Abo8vg_VAX3RlsBM>
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt- 2 week WG LC (6/21 to 7/5/2016)
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: Wed, 29 Jun 2016 10:49:26 -0000

"Susan Hares" <shares@ndzh.com> wrote:
> This begins a 2 WG LC last call on the text of
> draft-ietf-i2rs-ephemeral-state-10.txt.

Hi,

I have reviewed draft-ietf-i2rs-ephemeral-state-11, and here are my
comments.


o  Ephemeral-REQ-02

   I suggest you remove the text:

     it SHALL be considered a validation error if it does.

   The requirement is clear as it is without this.  And maybe the
   solution will make sure it is not even syntactially possible to
   define such constraints.


o  Ephemeral-REQ-03

   I think you need to define what you mean with "constraint".  For
   normal config, YANG has very detailed rules about when constraints
   are checked and what a server MUST do when a constraint becomes
   false.

   Since this requirement says that constraints can refer to fast
   changing state, you need to say what should happen if such a
   constraint suddenly becomes false due.


o  Ephemeral-REQ-04

   The requirement says that ephemeral state can refer to
   non-ephemeral state in constraints.  Does the term "non-ephemeral
   state" include configuration?  If so, does this mean that if an
   operator tries to delete some config, the existance of some
   ephemeral state may reject the config change request?


o  Ephemeral-REQ-07

   This requirement says:

     "Implementations MUST provide a mechanism..."

   Does this mean that this mechanism should not be standardized;
   rather implementations are required to invent some vendor-specific
   mechanism?


o  Ephemeral-REQ-08

   I understand "ephemeral" and "read/write".  But what does
   "status/configuration" mean in this context?  Can I have
   "ephemeral, read-only, configuration"?  Can I have
   "ephemeral, write, status"?


o  Ephemeral-REQ-09

   This requirement is fine, but why is it labeled *changes* to
   NETCONF?  NETCONF already supports this requirement.


o  Ephemeral-REQ-10

   This requirement is fine, but why is it labeled *changes* to
   RESTCONF?  RESTCONF already supports this requirement.


o  Ephemeral-REQ-13

   I do not understand what this requirement means.

   (BTW, the text should be rephrased; it now says "the requirement
   ... is required ...")


o  Ephemeral-REQ-14

   If this is not a new requirement, does it need to be part of this
   document?

   If the answer is yes, are there other things from the architecture
   document that should be listed here, e.g., details about priority
   interaction w/ local config?


o  Ephemeral-REQ-15

   I do not understand what this requirement means.


o  general

   s/Yang/YANG/g



/martin