Skip to main content

Interface to the Routing System (I2RS) Ephemeral State Requirements
RFC 8242

Yes

(Alia Atlas)

No Objection

Alvaro Retana
(Joel Jaeggli)

Note: This ballot was opened for revision 19 and is now closed.

Alvaro Retana (was Discuss) No Objection

(Alia Atlas; former steering group member) Yes

Yes (for -19)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2016-10-26 for -19)
In Section 9: 

s/Pub-Sub-REQ-03: The subscription service must support/Pub-Sub-REQ-03: The subscription service MUST support/ 

(I'm assuming that was the intent, anyway)

(Ben Campbell; former steering group member) No Objection

No Objection (2016-10-25 for -19)
I'm curious about the requirements on YANG and NETCONF/RESTCONF. Does this contemplate changes to those? Criteria to determine if they are acceptable choices?

(Benoît Claise; former steering group member) (was Discuss) No Objection

No Objection (2016-12-02)
My previous DISCUSS, which was ... 
  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.
... as been solved with Sue's email:

“This change difference was suggested by 
Juergen and Andy as two separate cases rather than the original one. 
  Juergen and Andy have been concerned about the speed of testing 
constraints that are in the operational state if the operational state 
yang variables are fast changing and short-lived.    They believe this 
requirement might not be doable in implementations.  They wanted this 
split out from Ephemeral-REQ-04 that simply states that ephemeral state 
MUST be able to refer to non-ephemeral state (configuration or 
operational state).  Since we do not 
know if the I2RS can handle the fast changing and short-lived ephemeral 
state, I think this split is a good one.” 


- Just one comment from Lionel's OPS DIR feedback left, that might need some clarifications.

   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.

[Sue]: I do not understand your point.   The "MAY" Deals with the fact the
implementation may attach a priority to the I2RS client and choose to only
store the link to the I2RS client.   What is the concern here?

(Deborah Brungard; former steering group member) No Objection

No Objection (2016-10-25 for -19)
Agree with Alvaro's Discuss. Not clear where Section 2 requirements are distilled from or if they are tied with supporting ephemeral state as RFC7921 did not require an active communication channel to be open at all times.

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -19)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-10-24 for -19)
Thanks for the updates from the previous version, it looks better and is nicer to have the security requirements in one place.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2016-10-24 for -19)
Two comments:

1) "I2RS requires ephemeral state; i.e. state that does
   not persist across reboots." -> why? Maybe add 1-2 sentences about the use (case) in the introduction.

2) Are all these requirements specific to ephemeral state? I would assume that some requirements are more general, e.g. don't you need priorities also for all other state updates?

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-10-24 for -19)
Ephemeral-REQ-12: "were created" seems wrong. (Oh, and
"MUST BE" isn't 2119 language:-)

(Suresh Krishnan; former steering group member) No Objection

No Objection (2016-10-26 for -19)
I am surprised to see MUST level requirements on YANG 

"Ephemeral-REQ-06: YANG MUST have the ability to do the following:"

and further requirements on NETCONF (REQ-09) and RESTCONF (REQ-10) in this document.

Are there associated drafts in the respective WGs to make sure these requirements are met?