Re: [i2rs] Comments re: draft-i2rs-ephemeral-state-12

"Susan Hares" <shares@ndzh.com> Tue, 05 July 2016 21:11 UTC

From: Susan Hares <shares@ndzh.com>
To: "'Alexander Clemm (alex)'" <alex@cisco.com>
References: <9394d0df0b724551b691959366dc2310@XCH-RTP-001.cisco.com>
In-Reply-To: <9394d0df0b724551b691959366dc2310@XCH-RTP-001.cisco.com>
Date: Tue, 05 Jul 2016 17:11:07 -0400
Message-ID: <04be01d1d701$bf4d0510$3de70f30$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04BF_01D1D6E0.383E2430"
Content-Language: en-us
Thread-Index: AQIa24eKlZVB5OUWjqMY7EwCeHRV9J94QoDg
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/UeKZtlmiv0N138WehBBxk2h3Cgs>
Cc: i2rs@ietf.org
Subject: Re: [i2rs] Comments re: draft-i2rs-ephemeral-state-12
Precedence: list

Alex:

 

Thank you for your comments.    The nit will be released in version 14. 

 

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm
(alex)
Sent: Thursday, June 30, 2016 8:13 PM
To: Susan Hares (shares@ndzh.com)
Cc: i2rs@ietf.org
Subject: [i2rs] Comments re: draft-i2rs-ephemeral-state-12

 

Hi Susan,

 

this document looks very good & I clearly support it.    

 

Just two very minor comments:

 

-          editorial nits - page  2:  "Sections 7" --> "Section 7"; "is I2RS
protocol requirement" --> "is an I2RS protocol requirement"

 

-          I consider Ephemeral-REQ-03 as very important ("may have
constraints that refer to operational state").  I am wondering, should the
draft mention how to deal with the fact that it is possible for operational
state to dynamically change.  I would think it is might be worth stating
something to the effect that constraints should be assessed when ephemeral
state is written, and that situations are conceivable where violations of
such constraints might occur due to changing of operational state after the
write occurred.   By the nature of the issue, the framework must allow for
that; how to deal with such a situation and maintain integrity of the
ephemeral configuration in such cases is up to the client.  

 

Alexander: 

 

   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.

 

Is this your suggested change? 

 

   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.

   Ephemeral state constraints should be assessed when the ephemeral 

   State is written, and if the constraint change after that time 

   the I2RS agent should notify the I2RS Client. 

 

If this expresses your desired change, please let me know - I will add it to
version 14. 

 

 

One thought re: section 9, clearly we have a requirement to support
subscriptions against ephemeral data; is there a requirement for
subscriptions to be ephemeral themselves?  (I think it is implicitly
supported via dynamic subscriptions.)

 

Yes, the subscriptions for the ephemeral only models must be ephemeral.   Is
this text addition ok? 

 

Pub-Sub-REQ-03:   The subscription service must support subscriptions which
are ephemeral. 

(E.g. An ephemeral data model which has ephemeral subscriptions.)

  

 

 

Thanks

--- Alex

 

Thank you for your comments. 

 

Sue

Re: [i2rs] Comments re: draft-i2rs-ephemeral-stat… Alexander Clemm (alex)
Re: [i2rs] Comments re: draft-i2rs-ephemeral-stat… Susan Hares
[i2rs] Comments re: draft-i2rs-ephemeral-state-12 Alexander Clemm (alex)