On Fri, Sep 12, 2014 at 2:22 PM, Joel M. Halpern <[email protected]>
wrote:
> Thanks for doing this Jeff. It is a great start.
>
> The Object Relationships issue does need more work however.
> Some of the cases are handled...
>
> YANG's tools for reuse can be used to meet the inheritance requirements.
> I think that the requires and when clauses are probably powerful enough to
> meet the architecture requirements for optionality (arch 6.4.5.2).
>
> I do not know of anything in YANG that corresponds to agent side
> templating, as was agreed by the working group and captured in arch
> 6.4.5.3. (Since I am one who argued against this, if we need more detailed
> examples I would appreciate some assistance.)
>
I agree with you that Agent templates do not belong in the I2RS base spec.
There is nothing in YANG or RESTCONF to support it (yet).
For some features the I2RS agent is supposedly simple and mostly stateless.
This template service does not seem to fit with that theme.
Are these templates ephemeral? That would be annoying. They are not
straight
config, so a new a configuration data model is needed to manage the
templates.
New protocol mechanisms to use templates in addition to payload data will
be needed.
> The object relationships are three piece. Arch 6.4.5.4.2 on correlation
> and arch 6.4.5.4.3 on actual references seem to be covered by various parts
> of YANG. But the initialization reference described in arch 6.4.5.4.1 does
> not correspond to anything I know of in YANG. Is there a YANG tool for
> that? This is the case where the definition of an object Foo says that
> whenever a new Foo is created, it takes its initial values from an instance
> of Bar, so as to simplify instantiation. This is similar too, but not the
> same as the templates material.
>
Nothing in YANG like that except the description-stmt.
The server can magically create whatever it wants, whenever it wants.
>
> You talk about the priority requirements. You should probably mention the
> multi-headed behavioral requirements there (as I think that the resolutions
> will be tightly coupled.)
>
> Section 7.9 of the archtiecture document talks about several transactional
> scopes. The text you have does not seem to deal with all of these. Does
> YANG handle them all easily?
>
I would need to review this again -- I don't remember any problems last
time I read the arch draft.
I am confused about some text in the draft about ephemeral config:
In 2.1:
The author wishes to
prevent any action that would lead to preserving any configuration
state entered via the I2RS agent across reboots. If state has to be
restored, it should be solely by replay actions from I2RS client via
I2RS agent.
Why does the author wish to prevent NV-storage of the I2RS data?
What is it about the accidental reboot of the router that makes it the
I2RS data needed before the accidental reboot, but not after?
If the reason is because I2RS agents are simple and NV-storage is not
simple,
then why does the agent need to support templates?
This section might mention that the I2RS datastore has its own
access control model, that is not the same as the running config.
2. Configuration state in the existing running datastore where the
module is "tagged ephemeral".
3. Permitting existing configuration to be optionally configured as
ephemeral. As an example, the NETCONF server advertises in its
<hello> message if it supports the specified YANG module
persistently and/or ephemerally.
I thought the I2RS charter said I2RS was not altering the local config.
Why does I2RS need to change the meaning of YANG configuration nodes
in an ad-hoc manner (via tagging)?
This does not really work because YANG validation may fail without some
config data
that has been tagged "do not save". If the router reboots and the startup
config
does not validate, it is probably wedged. It can't really fall back to a
"known good config"
if I2RS has forced some of the data to be omitted from the saved config.
In sec 2.1.3, if you want a new third choice for the config-stmt for
"ephemeral",
then I2RS is gated on the completion of YANG 1.1 (and development of YANG
1.1 tools).
Are you really sure you want that? That's why a YANG extension was
suggested instead
(or maybe do both).
> Yours,
> Joel
>
Andy
>
> On 9/12/14, 4:59 PM, [email protected] wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title : I2RS requirements for netmod/netconf
>> Author : Jeffrey Haas
>> Filename : draft-haas-i2rs-netmod-
>> netconf-requirements-00.txt
>> Pages : 10
>> Date : 2014-09-12
>>
>> Abstract:
>> This document covers requests to the netmod and netconf Working
>> Groups for functionality to support requirements to implement the
>> I2RS architecture.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-
>> netconf-requirements/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00
>>
>>
>> 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 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
