That text change seems good.
Moving specific mechanism protocol proposals to the protocol strawman
also seems appropriate.
Yours,
Joel
On 5/26/16 3:49 PM, Susan Hares wrote:
Andy and Joel:
<draft author hat on>
On Ephemeral-REQ-07.1 - draft-ietf-i2rs-ephemeral-state-07 - I2RS
Ephemeral State Requirements
I think the efficiency gain for a single place to check I2RS protocol
support is useful. How about if I propose in the protocol-strawman a
specific set of support that can be implemented in open source? And we
can take this to the rest of the list.
I do not intend to masking the NETCONF/RESTCONF version. If
implementations want to go through all the checking, this is fine for
the implementations. However, this is a simple place to store the
checking. As Andy notes, we will need to indicate the ephemeral support
in the draft-ietf-netconf-yang-library.
On Ephemeral-REQ-06: ] - did you like this revision?
Ephemeral-REQ-06: Yang MUST have a way to indicate in a data model that
nodes have the following properties: ephemeral, writable/not-writable
and status/configuration. Yang MUST have a way to indicate whether data
models can be passed over secure or non-secure transport.
(If you desire examples, please see [I-D.hares-i2rs-protocol-strawman]
for potential yang syntax).
Sue
*From:*Andy Bierman [mailto:[email protected]]
*Sent:* Thursday, May 26, 2016 2:33 PM
*To:* Susan Hares
*Cc:* Joel M. Halpern; [email protected]
*Subject:* Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
identification
On Thu, May 26, 2016 at 11:03 AM, Susan Hares <[email protected]
<mailto:[email protected]>> wrote:
Joel:
<wg chair hat off>
This requirement is not about forking I2RS protocol off the NETCONF/RESTCONF
stream.
My requirement is to have a parameter in some NETCONF model (? Extension to
draft-ietf-netconf-yang-library) that that indicates I2RS protocol version 1
(with all its requirements) are supported (true/false).
Otherwise, as a developer of an implementation - you must go to check all
the different types of netconf. It would seem to me that causing the
implementation to check all of the specific NETCONF and model support would
be much more work that indicating a I2RS protocol version support. I think
your mechanism is a lot more work for the I2RS client querying 1 variable.
The protocol identification was removed from the YANG library.
It was decided that each protocol would return the view of the library
that is supported in the protocol. Only NETCONF and RESTCONF
were considered, but if I2RS uses these protocols then it is covered.
IMO there should be an optional capability for "ephemeral" that
indicates the I2RS extensions (to NETCONF or RESTCONF) are supported.
There really isn't a separate I2RS protocol (e.g., entry points are the
same)
Sue
Andy
-----Original Message-----
From: Joel M. Halpern [mailto:[email protected]
<mailto:[email protected]>]
Sent: Thursday, May 26, 2016 1:42 PM
To: Susan Hares; [email protected] <mailto:[email protected]>
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
identification
First, I would prefer that we express our requirements, and let the
protocol
developers determine what is the best way of meeting those requirements.
That is what I want when I receive requirements, so I try to meet that
standard when I send them.
As for a proposed mechanism, I would again separate pieces. The I12RS
Client needs to know if certain capabilities are present. These include
support for specific models (already present in netConf), support for
specific additional capabilities such as Ephemeral handling, and
support for
the attribution mechanisms. There may be others. Depending upon
how these
needs are met, there are multiple ways to indicate these
capabilities within
the NetConf and YANG framework.
Further, and part of the reason for my concerns, is that I would want to
know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a
future
YANG 1.2 or 2.0. Without having to change the I2RS "protocol"
indication.
If we were really in a situation where I2RS support was a fork from
the base
protocols, then a protocol version would be appropriate. That situation
would be extremely unfortunate. I believe we are avoiding that.
yours,
Joel
On 5/26/16 12:55 PM, Susan Hares wrote:
> Joel:
>
> I2RS protocol as a re-use protocol is specifying a set of changes to
> NETCONF or RESTCONF. We have two ways it can be identified:
>
> 1) Implementations can "value" (I2RS protocol version) to query that
> indicates the NETCONF implementation or the RESTCONF implementation
> provides all the features requested by I2RS protocol requirements.
>
> 2) Implementations query the NETCONF implementation or the RESTCONF
> implementation supports all the features required for the I2RS
protocol.
>
> It seemed reasonable to me to specify that NETCONF or RESTCONF set-up
> a value that implementations can query to indicate it supports I2RS
> protocol requirements.
>
> Did you have a better way to do this?
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Joel Halpern
> Sent: Wednesday, May 25, 2016 10:04 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
> identification
>
> Mostly, this looks very good.
>
> I find it odd and overspecified that the first requirement for netConf
> and Restconf is described as indicating I2RS support via the protocol
version.
>
> It seems unlikely that the protocol version is the right way to
> represent this. And it seems that the I2RS WG should specify the
> need, not the mechanism used to represent it.
>
> Yours,
> Joel
>
> On 5/25/16 9:39 PM, [email protected]
<mailto:[email protected]> wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> This draft is a work item of the Interface to the Routing System of
>> the
> IETF.
>>
>> Title : I2RS Ephemeral State Requirements
>> Authors : Jeff Haas
>> Susan Hares
>> Filename : draft-ietf-i2rs-ephemeral-state-07.txt
>> Pages : 14
>> Date : 2016-05-25
>>
>> Abstract:
>> This document covers requests to the NETMOD and NETCONF Working
>> Groups for functionality to support the ephemeral state
requirements
>> to implement the I2RS architecture.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07
>>
>>
>> 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 <http://tools.ietf.org>.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
> I2RS
>
> _______________________________________________
> i2rs mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
_______________________________________________
i2rs mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
