On Wed, Apr 23, 2014 at 9:07 AM, t.petch <[email protected]> wrote:
> YANG (with NETCONF) is designed for writing configuration and reading
> everything else, and does an excellent job at it. Trouble is, for me,
> that configuration doesn't mean what I think of it as; it means, in the
> YANG context, what you might put in through the CLI and it excludes
> everything else, such as data learnt via a protocol.
>
> Take routing. A static route is configuration; anything learnt, via
> BGP, IS-IS, RIP etc, is not configuration (and is read only).
>
> An interface configured automatically on a hot-plugged card is not
> configuration; adding 'ospf passive' is.
>
> And so on, for DHCP, NTP, .....
>
> In practice, this means that the YANG model comes in twin sets, one of
> read-write configuration and one of read-only not-configuration (as can
> be seen in the current I-Ds that the netmod WG is producing) with no
> formal way in YANG of relating the one to the other. So if you want
> e.g. the routing table, the host software has to know where to look and
> how to combine the pieces to produce a coherent picture (and then you
> cannot edit most of it).
>
> So if I2RS never wants to write anything to a router, YANG is fine; if
> I2RS is only producing a Information Model (and ignoring whether or not
> data is read-only or read-write), and not moving on to an
> implementation, then YANG is fine.
>
> Rather, as Andy Bierman said at IETF89, likely I2RS would need an
> extension to YANG, a new sub-statement for all data objects, semantics
> not too clear but designed to separate out the not-configuration, learnt
> via a protocol, 'editable-state' (and in doing so, making it
> read-write - but still 'config false').
>
> Yes, YANG allows for such extensions but it seems to me that I2RS would
> then be getting YANG++ (and NETCONF++), once the necessary work has been
> done.
>
So far, 2 extensions have been identified that are needed by I2RS.
1) identification of editable operational state.
The config=false property in YANG will cause NETCONF and RESTCONF
to (correctly) treat operational state as read-only. I2RS servers must
implement the extension: The I2RS protocol will use its own access
control
model on this data. NACM is not required.
e.g. (not real data, just example!)
extension edit-data {
description
"If this statement is present, and the parent statement represents
a non-configuration data node, then instances of this data node
can be modified by a client.";
}
container rib {
config false;
i2rs:edit-data;
....
}
2) identification of objects associated with event notifications
This could also be done with a YANG extension, and there is a proposal
to change YANG 1.1 to support this feature:
extension event-object {
description
"If this statement is present, and the parent statement is
a notification statement, then the 'path' argument represents
the resource associated with the notification.";
argument path;
}
notification some-interface-event {
i2rs:event-object /if:interfaces/if:interface;
leaf name {
type leafref { path /if:interfaces/if:interface/if:name; }
}
leaf some-data { type string; }
....
}
Nobody said YANG or ForCES could be used without any modifications
to support I2RS. YANG allows instant modifications that require no
changes to the language specification.
> Tom Petch
>
Andy
>
>
> ----- Original Message -----
> From: "Edward Crabbe" <[email protected]>
> To: <[email protected]>
> Sent: Friday, April 11, 2014 6:50 PM
> Subject: [i2rs] consensus on I2RS protocol and model
>
>
> > Dear I2RSers,
> >
> >
> > At the last I2RS WG meeting there was a great deal of conversation
> > regarding selection of both modeling language and underlying transport
> > protocol. Consensus at the time was to make use of Yang and (NetConf
> or
> > RestConf) (unclear).
> >
> > Before coming to a final consensus, we'd like to give people
> adequate
> > time to review source material, marshall arguments and discuss on the
> > mailing list. To this end, we're asking that interested parties do
> just
> > this over the course of the next ~two weeks. Following that period, on
> > 4/28, we'll be initiating a consensus call that will last an
> additional two
> > weeks, with the aim of converging modeling language / protocol by
> Friday,
> > 5/9.
> >
> > The consensus call should also generate proposals for any material
> changes
> > required to the underlying protocols. These proposals in turn will
> form
> > the basis for a later draft including gap analysis and said changes.
> Those
> > strongly in favor of one protocol over another should be prepared to
> > contribute to this analysis.
> >
> >
> > best,
> >
> > -ed
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > i2rs mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/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
