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

"Susan Hares" <shares@ndzh.com> Fri, 01 July 2016 19:51 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 D5BB812D7C0 for <i2rs@ietfa.amsl.com>; Fri, 1 Jul 2016 12:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.749
X-Spam-Level: *
X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] 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 j7ArzgminBxs for <i2rs@ietfa.amsl.com>; Fri, 1 Jul 2016 12:51:08 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [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 58FE912D1B8 for <i2rs@ietf.org>; Fri, 1 Jul 2016 12:51:08 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.202.159;
From: Susan Hares <shares@ndzh.com>
To: 'Martin Bjorklund' <mbj@tail-f.com>
References: <4a3b01d1d2e5$76dca350$6495e9f0$@ndzh.com> <20160701.124510.1016107013440022699.mbj@tail-f.com> <036101d1d398$60e5d5e0$22b181a0$@ndzh.com> <20160701.161321.1018267250429655769.mbj@tail-f.com>
In-Reply-To: <20160701.161321.1018267250429655769.mbj@tail-f.com>
Date: Fri, 01 Jul 2016 15:50:27 -0400
Message-ID: <08df01d1d3d1$d100a100$7301e300$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_08E0_01D1D3B0.49F828C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKRY4QTSlv7KEdh3PBvByKwGzr1uQE3ToSKAVAl9zABcG93955lC/ig
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/k7kyUzXZyM0vdFvlzokkmlTz8VQ>
Cc: jhaas@pfrc.org, i2rs@ietf.org
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: Fri, 01 Jul 2016 19:51:14 -0000

Martin: 

 

 

Trimming a bit as well.  Starting with ephemeral-REQ-03. 

 

   Ephemeral-REQ-03: Ephemeral state may have constraints that refer

     to operational state, this includes potentially fast changing or

     short lived operational state nodes, such as MPLS LSP-ID or a BGP
IN-RIB.

 

Thanks for Acting the following for Ephemeral-REQ-04 

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.

 

Old: 

Ephemeral-REQ-07: Ephemeral configuration state could override overlapping 

local configuration state, or vice-versa.  

Implementations MUST provide a mechanism to choose which takes precedence.  

/

New 

Ephemeral-REQ-07: Ephemeral configuration state could override overlapping 

local configuration state, or vice-versa.  

Implementations MUST provide a mechanism to choose which takes precedence.  

This mechanism MUST include local configuration

(policy) and MAY be provided via the I2RS protocol mechanisms.

 

Ephemeral-REQ-08:  Status: No change, discussion continuing  

Ephemeral-REQ-09/Ephemeral-REQ-10: No change, discussion indicates minor
point. 

 

Ephemeral-REQ-11/12/13: No change 

Ephemeral-REQ-14: No change, do we have agreement? 

 

I’ll send version-13 out later todasy. 

 

Sue 

 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund
Sent: Friday, July 1, 2016 10:13 AM
To: shares@ndzh.com
Cc: jhaas@pfrc.org; i2rs@ietf.org
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt-
2 week WG LC (6/21 to 7/5/2016)

 

Trimming a bit, and replying inline -- starting with Ephemeral 

 

 

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

> > > 

> > >   For the I2RS state which is ephemeral configuration state, the 

> > > constraints may have all of 8.3 in yang 1.1 or part of the yang 

> > > 1.1 constraint.

> > >  The final definition of the ephemeral configuration state depends 

> > > on the design of operational state modules.

> 

> > This explanation helps to understand this requirement.  You 

> > obviously have

> some ideas what "constraint" means, and that it means different things 

> for config and state.

> >  This should go into the document, but see below.

> 

> With respect, we have gone 4 rounds with different NETCONF experts.   Each

> with a different suggestion to put in/take out.

 

> Please don't misunderstand me, but also with respect, I simply state my
opinion.  I think the text is not clear, even if it has gone 4 rounds with
different NETCONF experts.

 

I understand it is unclear to you.   This last proposal was from Robert
Wilton that resulted in this text which he understood. 

The previous text tried to make it clear to Juergen.  ... etc.   At some
point, I must just get it approved with the 

I2RS WG folks, and then try to get netmod key people, netmod chairs, netconf
chairs, and netconf key people  in a room to get a common definition. 

 

  Ephemeral-REQ-03: Ephemeral state may have constraints that refer to

   operational state, this includes potentially fast changing or short

   lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB.

 

>> However, since you have

>> asked: 

>> 

>> There are 4 classes of I2RS ephemeral configuration state checking we 

>> have defined so far:

>>   1) normal (r/w) of drafts (draft-ietf-i2rs-rib-data-model)  - check 

?> 8.3.1, 8.3.2, 8.3.3 + ephemeral requirements (1-15)

 

>There are no 8.3.x sections in draft-ietf-i2rs-rib-data-model-05.  Did you
mean some other document?

Yang 1.1 section 8.3.1, 8.3.2, 8.3.3.  

 

 

>>   2) bulk (r/w) within rpcs (see draft-ietf-i2rs-rib-data-model) - 

>> constraints check interfaces (real configuration) + checks on route 

>> overlay (Ephemeral 7) + Ephemeral (-15)

>>   3) bulk (r/w) with lots of data learned from other routing protocols

>> (draft-ietf-i2rs-l3-network-topology) + checks on static configured 

>> protocols

>>   4) bulk (r/w) with rpcs that are "high-speed" using only checks on 

>> 8.3.1 + ephemeral requirements (1-15)

>> 

>> We desire to be able to define additional data constraints per data
model.

>> These additional constraints can go in rpcs. 

 

>I'm sorry, but you are confusing me completely.  How can a constraint go
into an rpc?  

>Now I'm _really_ curious to understand your definition of constraints.

 

An rpc has input/output parameters.   What do you call checking on the 

 

   rpcs:

      +---x rib-add

      |  +---w input

      |  |  +---w rib-name        string

      |  |  +---w rib-family      rib-family-def

      |  |  +---w ip-rpf-check?   boolean

      |  +--ro output

      |     +--ro result uint32

      |     +--ro reason? string

 

Rpc = yang1.1 section 17.14 

 

              +--------------+---------+-------------+

              | substatement | section | cardinality |

              +--------------+---------+-------------+

              | anydata      | 7.10    | 0..n        |

              | anyxml       | 7.11    | 0..n        |

              | choice       | 7.9     | 0..n        |

              | container    | 7.5     | 0..n        |

              | grouping     | 7.12    | 0..n        |

              | leaf         | 7.6     | 0..n        |

              | leaf-list    | 7.7     | 0..n        |

              | list         | 7.8     | 0..n        |

              | must         | 7.5.3   | 0..n        |

              | typedef      | 7.3     | 0..n        |

              | uses         | 7.13    | 0..n        |

              +--------------+---------+-------------+

 

>From section in rpc input: 

   If a leaf in the input tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in an RPC invocation.
 
   If a leaf in the input tree has a default value, the server MUST use
   this value in the same cases as described in Section 7.6.1
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.6.1>
.  In these
   cases, the server MUST operationally behave as if the leaf was
   present in the RPC invocation with the default value as its value.
 
   If a leaf-list in the input tree has one or more default values, the
   server MUST use these values in the same cases as described in
   Section 7.7.2
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.7.2>
.  In these cases, the server MUST operationally behave
   as if the leaf-list was present in the RPC invocation with the
   default values as its values.
 
   Since the input tree is not part of any datastore, all "config"
   statements for nodes in the input tree are ignored.

 

What do you call these requirements for input?  Constraints or something
else?  How do you define the validity of the grouping, choice, container,
leaf-list, list, etc. without enforcing some type of syntactical (section
8.3.1) constraint.  If you use a different term, where is it define in
section 7.14? If not, why is it not constraint. 

 

>> And what does the r/w label above mean?  Are constraints checked during
read operations?

Yes, the constraints of the read format are expected to be syntactically
checked as netconf server receives it from I2RS agent.  The response from
the read is syntactically check at the I2RS client when the read response is
received.  The constraints of the write format are expected to be
syntactically checked when the netconf server receives it from I2RS agent.
If a rpc is used to add/delete/modify the data in the I2RS agent, then
section Yang 1.1 in section 17.4 has “constraints” or something on the input
and output parameters. 

 

> >> Every effort we have made to tie this down has resulted in cycles 

> >> of unproductive discussion.  Therefore, this portion will not be
re-opened.

[snip] 

 

> I have not mentioned "Operational vs ephemeral configuration state".

> I am just trying to understand what you mean when you talk about

> "constraint".   The requirements are very specific that "constraints"

> MUST be able to refer to fast-changing operational data. 

 

Ø   I don't think it is too much to ask for to get a definition of what a
"constraint" is.

 

I agree you are being reasonable.  I am trying to provide you with the
definition of constraints per yang 1.1 documentation and the ephemeral
requirements in this document. 

 

What I am stating is unreasonable is that the process of getting the
definition of “constraints” has been enmeshed in the opstate debate which
has gone on for 2 years.  IHMO – that is an unreasonably long period of time
for opstate debate to go on without quick resolution.   Hopefully, my
answers will steer clear of the opstate debate. 

 

> >> For operational state listed in ephemeral constraints going quickly 

> >> from TRUE to FALSE, please note that an event notification will be
sent

>> to the I2RS Client.   See the event-notification draft for specifics. 

> 

> > Which draft do you mean?

>> Draft-gonzalez-netconf-event-notifications.

 

Ø  I'm sorry, but what does this draft have to do with the constraints that
refer to fast-changing operational data?

 

You are missing a piece that the architecture specifies.  I2RS ephemeral
state may refer to operational state that rapidly changes (e.g. LSP-ID).  If
this causes the I2RS ephemeral state to become invalid, the I2RS agent needs
to notify the I2RS client via the notification process.    See the
notification examples from the ietf-i2rs-rib-data-model. 

 

notifications:
      +---n nexthop-resolution-status-change
      |  +--ro nexthop
      |  |  +--ro nexthop-id?           uint32
      |  |  +--ro sharing-flag?         boolean
      |  |  +--ro (nexthop-type)?
      |  |     +--:(nexthop-base)
      |  |     |  ...
      |  |     +--:(nexthop-chain) {nexthop-chain}?
      |  |     |  ...
      |  |     +--:(nexthop-replicates) {nexthop-replicates}?
      |  |     |  ...
      |  |     +--:(nexthop-protection) {nexthop-protection}?
      |  |     |  ...
      |  |     +--:(nexthop-load-balance) {nexthop-load-balance}?
      |  |        ...
      |  +--ro nexthop-state nexthop-state-def
      +---n route-change
         +--ro rib-name                 string
         +--ro rib-family               rib-family-def
         +--ro route-index              uint64
         +--ro match
         |  +--ro (route-type)?
         |     +--:(ipv4)
         |     |  ...
         |     +--:(ipv6)
         |     |  ...
         |     +--:(mpls-route)
         |     |  ...
         |     +--:(mac-route)
         |     |  ...
         |     +--:(interface-route)
         |        ...
         +--ro route-installed-state route-installed-state-def
         +--ro route-state         route-state-def
         +--ro route-change-reason route-reason-def

 

In Ephemeral-REQ-03, we are simply indicating that these notifications may
occur rapidly if the operational state changes cause the operational state
or the ephemeral configuration state (see the above example for i2rs-rib
data model).   The intent of this notification is to indicate load on the
notification functions.   The new designs for notification in
NETCONF/RESTCONF are trying to handle this rapid form of events. 

 

Snip ….. 

 

> How about: 

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

 

Ok.

 

> >> If the operator deletes some "local configuration" (in I2RS terms), 

> >> and the I2RS Ephemeral state depends on the local configuration - 

> >> the I2RS agent will Provide a notification that the ephemeral 

> >> configuration state or the Operational state defined in an 

> >> ephemeral model is no longer valid.

> >> The I2RS client must handle this one. 

> 

> > Again, this explanation really helps!  It should go into the document.

> OR, if this is explained in another document, a pointer to that text 

> would be great.

> See section 6.3 of RFC7921.

 

Ø  Hmm, section 6.3.1 says that "must" and "when" statements should be
considered, but not how to do it.

 

Yes – we were told if we went further, it was encroaching on the solution
space.  Do you want I2RS opinions on MUST and WHEN. 

 

> We put these references in, and Juergen asked for their removal as TMI
(too much information).

 

>> I checked all previous versions of this document, and I did not find such
a reference in any one of them.  Could you specify what you mean?

 

The I2RS chairs have had email discussions online and offlist.   It is in
these email discussions.  

 

>> Please check with other netconf/netmod experts before we put-in/take-out
again.

 

Ø  Are you saying that if one person provides some feeback, another person
must not provide conflicting feeback?

 

YES!!!!

 

> >Clarifacation question: does this mean that the ephemeral state in 

> >question

> is removed and a notification is sent, or that the ephemeral state is 

> still present, but not used, and a notification is sent?

> Clarification question:   It is possible any time the ephemeral state goes

> from active to inactive (see draft-ietf-i2rs-rib-data-model), or if state
is

> removed (see draft-ietf-i2rs-rib-data-model)   

 

Ø  That's not what I asked though.  My question is if the ephemeral state is
removed when the constraint becomes false.

 

The removal of data is model dependent, but the requirement to notify the
I2RS client if a constraint becomes false is mandatory. 

For example, the installed state in the i2RS RIB below can go to inactive
with a reason of interface down. 

 

      +---n route-change
         +--ro rib-name                 string
         +--ro rib-family               rib-family-def
         +--ro route-index              uint64
         +--ro match
         |  +--ro (route-type)?
         |     +--:(ipv4)
         |     |  ...
         |     +--:(ipv6)
         |     |  ...
         |     +--:(mpls-route)
         |     |  ...
         |     +--:(mac-route)
         |     |  ...
         |     +--:(interface-route)
         |        ...
         +--ro route-installed-state route-installed-state-def
         +--ro route-state         route-state-def
         +--ro route-change-reason route-reason-def

 

 

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

> > 

> > Sue:  Previous netconf/netmod reviewers have cautioned the I2RS WG 

> > on defining a solutions.  If the NETCONF/NETMOD does not define a 

> > solution - then the implementation should provide a solution.

> > Of course, a standardized solution would be preferred. 

> 

> >I agree that this document shouldn't specify a solution.  This 

> >document's role is to define requirements for a solution (not for
implementations).

> Maybe simply:

> >

> >OLD:

> 

>  > Implementations MUST provide a mechanism to choose which takes

>   > precedence.

> 

> >NEW:

> 

>  > It MUST be possible to choose which takes precedence.

> 

> Sue:  This was part of an earlier version, but people felt we must 

> indicate what chooses.

 

Ø  Ok, so I assume the current text that this should be up to the
implementation rather than a standardized solution is correct.

 

No, our understanding is that this text would allow the NETCONF to specify a
solution,  and if it did not – for implementations to create a solution.  If
this is not what you think this requirement means, then I’ve got to go back
to refining the text. 

 

How about: 

Old:

Implementations MUST provide a mechanism to choose which takes  precedence.

 

New: 

Implementations MUST provide a mechanism to choose which takes precedence.

If a standard mechanism to choose precedence exists, then the implementation
MUST implement the standard mechanism. 

 

 

> Summary: No change

> 

> 

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

> > >

> > > > Ephemeral-REQ-08: Yang MUST have a way to indicate in a data 

> > > > model that schema nodes have the following properties: 

> > > > ephemeral,  writable/  not-writable, and status/configuration.

> > 

> > > Here we are indicating that Ephemeral state may be Ephemeral 

> > > configuration state or Operational state.

> 

> > I understand that.

> 

> > > Every time we have not used "ephemeral", "read/write", 

> > > "status/configuration"  - we have bumped into someone's 

> > > operational  data model.

> > > Unless the netmod group has a finalized version of operational 

> > > state, it will Remain this way.

> 

> > This doesn't make any sense to me.  This is a requirement to YANG, 

> > and I

> do not understand how to interpret this requirement.  

> 

> Martin - I apologize, but I keep getting request to change to 

> different answers based on different "yang experts" opinion.

> I respect your expertise and your questions

> 

> > My questions were simple:

> > Can I have "ephemeral, read-only, configuration"? 

> You are missing a key point.  Different I2RS agents have different 

> permissions.

 

Ø  I do understand this, but the requirement is for YANG to provide a
mechanism to specify these parameters *in the data model*.

What is “data mode”?  It is not defined in yang 1.1.  

 

> For I2RS agent 1, you can have ephemeral, read-only configuration 

> because Agent 1 does not have permission to write this section of the data
models.

> For I2RS agent 2 (who has permission to read this portion of the data

> model), the data will be ephemera, configuration, read/write.    

> 

> This is part of the normal case of the I2RS client-I2RS agent. 

> 

> >  Can I have "ephemeral, write, status"?

> It is possible if you allow a remote client permission to clear 

> counters prior to sending.

> This is possible if the I2RS data model allows read and clear.  

 

Ø  Sure, and there are already similar constructs, e.g., RFC 7317 defines an
RPC to set the current date and time, even though the current-datetime is
config false.  This is possible even in YANG 1.0.

 

OK – the history is I had ephemeral state/non-ephemeral state (ephemeral
configuration state and operational state) and read/write, but this did not
seem to allow rpcs.   

 

How does this text work for you: 

 

Ephemeral-REQ-08:In addition to config true/false, there MUST be a way to
indicate that YANG schema nodes represent ephemeral state. 

It is desirable to allow for, and have to way to indicate, config false YANG
schema nodes that are writable operational state.

 

 

 

> > > o  Ephemeral-REQ-09

> > > 

> > > >   This requirement is fine, but why is it labeled *changes* to 

> > > > NETCONF?  NETCONF already supports this requirement.

> > >  

> > > Do you really support the following: 

> > > 

> > >   1.  Support for communication mechanisms to enable an I2RS 

> > > client to

> >  >       determine that an I2RS agent supports the mechanisms needed for

> >  >  I2RS operation.

> 

> > > Sure, by using std YANG features and/or protocol capabilities.

> 

> Ok.  How easy is it for the I2RS client to request this of the NETCONF 

> server or RESTCONF server?  This requirement underscores that it must 

> not only be possible, but Easy for the client to query.

 

I'd say that it is easy; YANG 1.1 even provides a way for the client to
cache the server's capabilities in order to not have to re-check all
capabilities every time.

 

Howabout:

 

>> OLD:

 

>>  The conceptual changes to NETCONF

 

>> NEW:

 

>>  The requirements to NETCONF are:

 

This was the previous version.  Juergen wanted it changed to configuration.
If it is minor, lets leae it. 

 

But in the light of the other issues, this one is really minor.

 

> >>    2.  The ephemeral state must support notification of write conflicts

> >>       using the priority requirements defined in section 7 below in

> > >      requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).

> 

> > > NETCONF the protocol supports notifications; it is not involved in 

> > > the

> semantics for when/how these notifications are generated.

> > > I think this requirement probably should not be directed to NETCONF.

> 

> People woho have been working in netconf are actively supporting 

> changes to event notifications for netconf  

> (draft-gonzalez-netconf-4277bis-02,

> draft-gonzalez-netconf-evnet-notifications-00) or restconf 

> (draft-voit-netconf-restconf-notif-00).  Where else would you suggest 

> the write conflict is provided?  Early reports to I2RS during protocol 

> selection claimed this was the place to work.

 

Ø  I think it will be in the definition of ephemeral state.  Such a solution
would specify under which circumstances certain notifications are generated.

 

Sue: This did not provide a clean definition of ephemeral state agreeable to
Juergen.  We left it in the rather length ephemeral-REQ-11 to
ephemeral-REQ-14. 

 

> >> This is not what other netconf/netmod people have indicated. 

> 

> > If I'm not mistaken, Andy said the same thing re capabilities.

> Andy did same the same thing on #1.  However, the emphasis is going 

> from "possible" to "easy".

> 

> > Summary: Need response on -09 and -10 before changing.

> 

> Summary:  Awaiting confirmation on "write-conflict" prior to any change. 

> 

> > > >o  Ephemeral-REQ-10

> > > >

> > > >   This requirement is fine, but why is it labeled *changes* to 

> > > > RESTCONF?  RESTCONF already supports this requirement.

> > > 

> > > Are you really sure you support priority requirements as specified 

> > > in items Ephemeral-REQ-11 through Ephemeral-REQ-14?

> > > Not what other people have said.  Does not hurt if you do? 

> > > 

> > Summary: Need response on -09 and -10 before changing. 

> 

> > See above.

> See answers above as well. 

> 

> > >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 ...")

> > 

> >    Ephemeral-REQ-13: The requirement to support multi-headed control is

> >    required for collisions and the priority resolution of collisions.

> >    Multi-headed control is not tied to ephemeral state.  I2RS is not

> >    mandating how AAA supports priority.  Mechanisms which prevent

> >    collisions of two clients trying the same node of data are the focus.

> > 

> > I believe this text refines the requirement to support multi-headed 

> > control to only be required for collisions and priority resolution 

> > of

> collisions.

> 

> Ok, this makes it clearer.  Maybe you can do:

> 

> OLD:

> 

>   The requirement to support multi-headed control is

>   required for collisions and the priority resolution of collisions.

> 

> NEW:

> 

>  Multi-headed control is required for collisions and the priority 

> resolution of collisions.

> 

> > Perhaps you understood the English in a different manner. 

> > 

> > This text is terse, and assumes you understand the I2RS architecture. 

> > Rather than repeat that text here, perhaps you will review it and 

> > see if you then understand this text.

> > We have been terse based on feedback from netconf/netmod reviewers. 

> 

> Terse is fine, as long as it is clear.  Pointers to other documents 

> are also fine, they help the readers to understand what you had in mind.

> 

> Summary: 

> Will change to: 

> /Multi-headed control is required for collisions and the priority 

> resolution of collisions./

 

Ok.

 

 

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

> > 

> > Again, we were cautioned in our early discussions not to define the 

> > solution or to assume a solution in I2RS requirements.

> > 

> > Summary: No change

> 

> > Actually, you *did* change this in -12, to the better!

> 

> Yes.  I'm glad you liked it. 

> 

> > >o  Ephemeral-REQ-15

> > > > I do not understand what this requirement means.

> >> 

> > >  Example: 

> > > 

> > > I2RS client                I2RS Agent 

> > >  ===========          =============

> > >  Message 0 [query to see if eth0 is up] 

> > >                                 [response eth0 is up ] Message 1 

> > > [install I2RS Static route associated with eth0 ] Message 2 

> > > [install  BGP I2RS route dependent on I2RS static route]

> >  >                               [Message 1-reply success]

> >  >                                [Message 2-reply success]

> >  >

> > > Message 1 and Message 2 are individual actions but linked.  

> > > However,  Message 2 will not work if the I2RS static route has not be
installed.

> > > 

> > > I2RS does not include roll-back or atomicity of Message 1 and Message
2.

> 

> > > It requires that the I2RS client know the status of each action. 

> > > 

> > > None of these multiple message sequences should allow the I2RS 

> > > agent to insert errors into the Ephemeral Configuration state or 

> > > Ephemeral  operational state.

> > >

> > > Does this example help? 

> 

> > Well, I think that this follows from the requirements on 

> > 'constraints', so

> this requirement is at best redundant.

> Perhaps this is true, however this text is the result of 4 weeks of
debate.

> The compromise for all participants was to place this requirement.  If 

> you feel it is redundant, you are aligning with some of the people in 

> the debate.

> 

> > The text is also not very clear.  For example it talks about "not 

> > insert

> errors".  What is an "error" that could be inserted?  What you 

> probably mean is that all constraints MUST be true.

> 

> No - we mean that multiple messages MUST not insert an error.  Andy 

> Bierman states if we allow less than the current constraints (8.3.1, 

> 8.3.2, 8.3.3 in

> netconf) and the current netconf constraints we could have a error in the

> ephemeral configuration data store.   We simply state this MUST not
happen. 

 

Ø  I think you just confirmed what I wrote :)

 

Sue: Yes, I did.  Andy seem to desire to say it in this fashion.  

 

 

/martin

 

 

 

> For some models using the high-speed update with minimal checking, the
I2RS

> is willing to provide self-checks of the data.   If you mix this type
(type

> 4 above) and the normal type, perhaps you could get an error.  The 

> self-checking would then detect it, invalidate all the "invalid" data 

> and send a notification to the I2RS client that the data has been
invalidated.

> This is not what we are focusing on here. 

> 

> 

> > /martin

> 

> 

> 

> 

> > 

> > Summary: No changes

> > 

> > o  general

> > 

> >    s/Yang/YANG/g

> > 

> > Thank you - I will change this after other revisions have been
suggested. 

> > 

> > 

> > /martin

> > 

> > _______________________________________________

> > i2rs mailing list

> >  <mailto:i2rs@ietf.org> i2rs@ietf.org

> >  <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

> > 

> 

 

_______________________________________________

i2rs mailing list

 <mailto:i2rs@ietf.org> i2rs@ietf.org

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs