Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt

As far as I can tell, there is no such thing as i2RS protocol version 1.
Rather there are (or more accurately) will be, a package of features the 
I2RS uses.

Asking of identification as a singular thing is an efficiency gain, but 
not a requirement.

And masking the YANG version is an extremely undesirable side-effect.

Yours,
Joel

On 5/26/16 2:03 PM, Susan Hares 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.
>
>
> Sue
>
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Thursday, May 26, 2016 1:42 PM
> To: Susan Hares; i2rs@ietf.org
> 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:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern
>> Sent: Wednesday, May 25, 2016 10:04 PM
>> To: i2rs@ietf.org
>> 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, internet-drafts@ietf.org 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.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> 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
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>

Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification