Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-ephemeral-state-23: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Fri, 02 Dec 2016 06:35:56 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-ephemeral-state-23: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: <[email-masked]>
Date: Wed, 7 Dec 2016 11:23:48 +0000

hi,

On the following point:

> - Just one comment from Lionel's OPS DIR feedback left, that might need some
> clarifications.
> 
> [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.
> 
> implementation may attach a priority to the I2RS client and choose to only

My comment was on the MAY applying to both "store I2RS client identity" and "not the effective priority".
Since then, this has been clarified in an updated version as "the data nodes MUST store I2RS client identity and MAY store the  effective priority at the time the data node is stored."

Lionel

> -----Message d'origine-----
> De : Benoit Claise [mailto:[email-masked]]
> Envoyé : vendredi 2 décembre 2016 15:36
> À : The IESG
> Cc : [email-masked]; Joe Clarke; [email-masked];
> [email-masked]; [email-masked]; MORAND Lionel IMT/OLN
> Objet : Benoit Claise's No Objection on draft-ietf-i2rs-ephemeral-state-23: (with
> COMMENT)
> 
> 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.)
> 
> 
> “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
> 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
> - Just one comment from Lionel's OPS DIR feedback left, that might need some
> clarifications.
> 
> [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.
> 
> implementation may attach a priority to the I2RS client and choose to only

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.