Subject: [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 May 2016 02:13:34 -0400

<WG chair hat off, co-author hat on> 
This version of the protocol strawman is the result of all the suggestions from the I2RS meeting and inputs from other reviews.  
Please let us know if you have additional reviews. 

Sue, Amit, and Andy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 06, 2016 2:11 AM
To: Amit Daas; [email-masked]; Andy Bierman; Susan Hares
Subject: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt

A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt
has been successfully submitted by Susan Hares and posted to the IETF repository.

Name:		draft-hares-i2rs-protocol-strawman
Revision:	02
Title:		I2RS protocol strawman
Document date:	2016-05-05
Group:		Individual Submission
Pages:		52
URL:            https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-02.txt
Status:         https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/
Htmlized:       https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-protocol-strawman-02

Abstract:
   This strawman proposal for the I2RS protocol supports I2RS
   requirements for ephemeral data store, management data flows, and
   protocol security.  It proposes additions to the NETCONF, RESTCONF,
   and YANG for these requirements.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 May 2016 09:44:18 +0200

I disagree with many things in the document. For example, a data model
must not detail things like

   o  encoding [XML | JSON]

   o  protocol [RESTCONF | NETCONF]

   o  protocol-transport [ssh, tls, tcp]

   o  transport-ports [ports]

because of layering and modularity concerns and of deployment
flexibility. There are many more of these. Overall, it would help if
there were fewer documents and not so many overlapping documents.

/js

On Fri, May 06, 2016 at 02:13:34AM -0400, Susan Hares wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 May 2016 11:51:38 -0400

Reading the latest revision, in section 3.1.1, the text in bullet 5 says 
that the data model indicates which portions are ephemeral.  That makes 
sense to me.

Then bullet 6 says that the management protocol needs to signal (in its 
yang library) which parts are ephemeral.

Why the second requirement?  If the data model is supported, and the 
data model states that certain items are ephemeral, what would it mean 
if the signaling did not also say that.  Conversely, what would it mean 
if the signaling said something was ephemeral that the model does not 
define as ephemeral?

It may be that I am misreading bullet 6.  Please explain.

Thank you,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 May 2016 11:57:35 -0400

Section 3.1.3 requirements 6 and 7 introduce the marking that the 
protocol used by YANG / NetConf is i2RS specific.  From one important 
angle, this makes good sense.  It avoids confusing the I2RS 
communication with other NetConf or RestConf usage.

On the other hand, it seems to create a difficulty when YANG evolves 
beyond YANG 1.1.  Do we have to explicitly decide each time if I2RS will 
support the new version, and assign a new i2rs version number?  This 
seems unfortunate.

Could there not be some other way to indicate that the protocol is YANG 
1.1, but that the usage of the channel is I2RS?

Thank you,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 May 2016 12:08:45 -0400

The text at the end of this section talks about the I2RS agent 
re-evaluating a set of writes done by a client when the assigned 
priority of the client changes.  Dealing with such changes makes sense.

I am confused by the specific proposal.  What is being reevaluated, and 
why are notifications being sent?  Since the I2RS agent does not store 
operations from clients which are not active, there is no way that 
changing the priority can cause a previously ignored operation to be 
applied.  Equally, if the priority is lowered, there is now way that any 
other I2RS cleint operation will suddenly take precedence.

The only case I can construct is if the routing system is using priority 
to decide between local config and I2RS (which earlier changes seem to 
rule out).  IN that case, a change could cause an I2RS client operation 
to be removed in favor of local config.
Even that case would seem to cause only a single notification of that 
event, not a whole series of notifications.

Yours, somewhat confused,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 May 2016 16:15:36 -0700

Hi,

I have not have enough time to work on this draft yet, but here are my
initial concerns.
I won't comment on the details yet.

1) datastores

There is an opstate design team working on everything except ephemeral.
We need 1 RPC defining the datastore framework and each specific datastore
(known at this time).
The I2RS protocol should not be that document.

2) requirements

There should not be any duplication of requirements.
There should just be normative text defining the protocol, and
non-normative examples.

3) YANG validation

As stated in BA, I am strongly against protocol documents redefining how
YANG works
for their spot solution.  The YANG designer and operator want the data
models to be as
protocol-independent as possible.

Andy

On Thu, May 5, 2016 at 11:13 PM, Susan Hares <[email-masked]> wrote:

> This version of the protocol strawman is the result of all the suggestions
> from the I2RS meeting and inputs from other reviews.
> Subject: New Version Notification for
> draft-hares-i2rs-protocol-strawman-02.txt
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/
> Htmlized:
> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-protocol-strawman-02
>
> Abstract:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 7 May 2016 09:53:41 -0700

On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern <[email-masked]> wrote:

> Why the second requirement?  If the data model is supported, and the data
> model states that certain items are ephemeral, what would it mean if the
> signaling did not also say that.  Conversely, what would it mean if the
> signaling said something was ephemeral that the model does not define as
> ephemeral?
>

I think you are correct that the YANG library does not need any changes
to identify ephemeral data.  Only the variable components of
YANG conformance are contained in the library.

Thank you,

Andy

> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 May 2016 14:42:45 -0400

Jürgen,

>    o  transport-ports [ports]

I believe the strawman document may be too general with regard to these
items.  These keywords may be appropriate for subscription/notification type
model entries, especially when the subscription is intended to be directed
to an end-point different than the transport connect the subscription is
being requested from.

The strawman should be updated to cover an example to clarify this point.

> there were fewer documents and not so many overlapping documents.

I agree that there are too many documents.  The number of them has been
somewhat driven by different parties pushing for analysis of requirements
from different angles.  As we converge on content, we should be centralizing
the content.

-- Jeff