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]] On Behalf Of Joel Halpern
Sent: Wednesday, May 25, 2016 10:04 PM
To: [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] 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
[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]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
