[NGO] DHCP and Partial Lock Examples in Kalua and - how Kalua meets the requirements

[<[e-mail]>]

WARNING: contains banned part

--- Begin Message ---

WARNING: contains banned part

--- Begin Message ---

Hi Balazs, All,

please find attached some of the examples we prepared so far:
These are:
- DHCP and DHCP augmentation examples from RCDML Requirements Document
- Partial Lock RPC

Other examples are in preparation.
Please let me know whether the examples are sufficient for your comparison.

Please find also attached a new version of the Kalua draft extended with the 
examples above and two tables showing how Kalua meets the RCDML 
requirements and the use cases for for SMI and MIB Modules discussed 
in the NGO maillist.

http://www.ersue.de/I-D/draft-ersue-netconf-kalua-dml-01a.txt or
http://www.ersue.de/I-D/draft-ersue-netconf-kalua-dml-01a.html

Cheers, 
Martin


 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of ext Ladislav Lhotka
> Sent: Monday, March 03, 2008 2:48 PM
> To: Balazs Lengyel
> Cc: NGO
> Subject: Re: [NGO] partial lock in RELAX NG
> 
> Hi Balasz,
> 
> attached is a new version (only RNG) that is annotated according to
> draft-mahy-canmod-dsdl-00.txt. Further comments are below.
> 
> Balazs Lengyel píše v Po 03. 03. 2008 v 10:10 +0100:
> > Hello Lada,
> > Some points about your schema (I prefer RNG).
> > The following items are missing:
> > - prefix   // what prefix willyou use on the wire? It would 
> be good to know.
> 
> If you mean namespace prefix, I am opposed to "defining" it in any
> formal spec (including YANG). W3C namespace recommendation says that
> apps SHOULD use the namespace name, not the prefix. Prefix is just a
> placeholder for the namespace name and should thus be irrelevant.
> 
> I'd suggest to specify the conventional prefix in the text of 
> the draft,
> that should do.
> 
> > - organization
> > - contact
> > - description for elements. The schema must be readable on 
> its own without the rest of the RFC.
> > - revision information
> 
> This is all included in the new version.
> 
> > 
> > You don't specify in the schema what is returned for 
> partial-lock (lockId)
> > You don't specify in the schema what is returned for 
> partial-unlock (nothing)
> 
> It's now specified in the in-line documentation. Maybe it's a 
> good idea
> to have a way for specifying it formally?
> 
> > 
> > config-name-choice makes the schema nice and shorter, but 
> as we do not have an official 
> > translation of the RFC 4741 to YANG or DSDL I think you 
> should include it. (I did for YANG.)
> 
> Well, the same problem is for rpc-operation-choice. I think it is
> necessary to have the base NETCONF schema translated to RELAX 
> NG anyway
> and I plan to write it before Philly.
> 
> Your remark points to an interesting question: can YANG refer to or
> reuse types from the base NETCONF schema? Rewriting them again in YANG
> models as you did here is error-prone. And I don't think it 
> is possible
> to translate the XSD schema in RFC 4741 to YANG (it uses attributes
> etc.)
> 
> > 
> > Myself personally, I don't like it that DSDL first defines 
> partial-lock-element, and later in a 
> > separate statement says that it is really an operations 
> (not config data patterns).
> 
> I am not sure I understand your comment. The definitions could be
> structured in any other way, e.g., everything could be under the
> rpc-operation-choice definition in the Russian matryoshka style, which
> is IMO less readable. But if you mean that the elements 
> representing RPC
> operations should be marked so, one option is to define an attribute
> such as dml:role="rpc" that would be attached to the corresponding
> "element" elements in the schema. Is it considered necessary?
> 
> > 
> > Your rpc-operation-choice pattern is as yet missing from 
> the DSDL draft.
> 
> No, it's supposed to be defined by the RELAX NG version of the base
> NETCONF schema. In the same way you reuse the rpcOperation 
> substitution
> group from the XSD schema in RFC 4741.
> 
> Lada
> 
> -- 
> Ladislav Lhotka, CESNET
> PGP Key ID: E74E8C0C
> 

--- End Message ---

_______________________________________________
NGO mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ngo

--- End Message ---