Subject: [NGO] partial lock in RELAX NG

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 02 Mar 2008 17:45:09 +0100

Hi Balasz,

attached is the RELAX NG schema for the partial locking extension (in
both XML and compact syntax, select whichever you like:-).

There are two assumptions about the base NETCONF schema that is
included, namely the existence of "config-name-choice" and
"rpc-operation-choice" patterns (equivalent to the XSD substitution
groups with heads "rpcOperation" and "config-name" appearing in RFC
4741). The latter is extended in the present schema.

To make the whole picture clearer, I will now translate the base NETCONF
schema to RELAX NG (or does such a translation already exist?). 

Cheers, Lada

Balazs Lengyel píše v St 27. 02. 2008 v 10:19 +0100:
> I hereby invite all DML teams to send me their version of the partial-locking data model. I 
> will include it in the draft. In the long run probably most will be removed, but it can serve 
> as a small real-life example to show of your DML.
> 
> Balazs
> 
> Mehmet Ersue wrote:
> > 
> > Hi All,
> > 
> > I don't want to be a nitpicker here but we had a long discussion
> > in the IETF #70 NETCONF session whether we should keep the
> > YANG-based data model in the document "Partial Lock RPC"
> > (http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-01.txt).
> > 
> > Since it is not an official language yet Dan recommended to use it
> > in the Appendix only. I understand your enthusiasm but I guess IESG
> > will not support the usage a Standards track document (at least currently).
> > 
> > Cheers,
> > Mehmet
> > 
> >  
> > 
> >  > -----Original Message-----
> >  > From: [email-masked] [mailto:[email-masked]] On
> >  > Behalf Of ext Andy Bierman
> >  > Sent: Tuesday, February 26, 2008 7:58 PM
> >  > To: Ladislav Lhotka
> >  > Cc: [email-masked]
> >  > Subject: Re: [NGO] completed CANMOD agenda
> >  >
> >  > Hi,
> >  >
> >  > ...
> >  > > My suggestion is to let the supporters of each methodology
> >  > create few
> >  > > non-trivial data models and show how they can be used.
> >  > Without practical
> >  > > experience, these discussions are indeed academic.
> >  > >
> >  >
> >  >
> >  > Great idea.
> >  >
> >  > An IPFIX configuration data model was just published:
> >>  http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configur
> >  > ation-04.txt
> >  >
> >  > This is a real data model, developed by a real WG.
> >  > This is exactly the scenario that the NETCONF WG is looking for:
> >  > non-NETCONF and non-XML DM writers who are creating a domain-specific
> >  > data model.
> >  >
> >  > The true measure of 'ease-of-use' is not whether the authors
> >  > know their own proposal, or a few experts know the technology,
> >  > but whether or not the intended audience (NETCONF data modelers)
> >  > actually think it is easy to use.
> >  >
> >  >
> >  > Andy
> >  > _______________________________________________
> >  > NGO mailing list
> >  > [email-masked]
> >>  http://www.ietf.org/mailman/listinfo/ngo
> >  >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > *Ihre erste Baustelle?* Wissenswertes für Bastler und Hobby Handwerker. 
> > <http://de.rd.yahoo.com/evt=48734/*http://de.answers.yahoo.com/dir/;_ylc=X3oDMTEzY2IyNmI0BF9TAzIxMTQ3MTgzMjIEc2VjA01haWwEc2xrA3RhZ2xpbmVz?link=list&sid=396545394>
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > NGO mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/ngo
> 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 03 Mar 2008 10:10:58 +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.
- organization
- contact
- description for elements. The schema must be readable on its own without the rest of the RFC.
- revision information

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)

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.)

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).

Your rpc-operation-choice pattern is as yet missing from the DSDL draft.

If you could provide an updated version, then it would be easier to compare the different 
solutions.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 03 Mar 2008 14:47:53 +0100

Hi Balasz,

attached is a new version (only RNG) that is annotated according to
draft-mahy-canmod-dsdl-00.txt. Further comments are below.

> - 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.

> - description for elements. The schema must be readable on its own without the rest of the RFC.

This is all included in the new version.

> 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?

> 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.)

> 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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 03 Mar 2008 15:16:32 +0100

Hi Lada,
Thanks for the updates. I personaly prefer the compact version of Relax, but anyway see stuff 
below.
Balazs

> I'd suggest to specify the conventional prefix in the text of the draft,
I think a module should be complete without the draft/RFC, it might be handled as a MIB today. 
In a tool you only load the MIB not the draft/RFC. So if the prefix is defined, it should be in 
the model as well.
> to have a way for specifying it formally?
YES, Definitely.
> and I plan to write it before Philly.
I agree, that redefinitions are evil, but as we don't have a standard DSDL or YANG version, the 
redefinition might be needed just for now.
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: <[email-masked]>
Date: Thu, 6 Mar 2008 18:04:10 +0200

WARNING: contains banned part

Subject: [NGO] DHCP and Partial Lock Examples in Kalua and - how Kalua meets the requirements
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 6 Mar 2008 18:04:10 +0200
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>

WARNING: contains banned part

Subject: DHCP and Partial Lock Examples in Kalua and - how Kalua meets the requirements
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 6 Mar 2008 18:04:10 +0200

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

> 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,
>