Re: [netmod] Y45-04 and ietf-yang-library
On Mon, Jul 06, 2015 at 08:16:32AM -0700, Andy Bierman wrote: If the import of C really depends on specific revisions of some typedefs, groupings, etc. then import by revision MUST be used everywhere in the dependency chain (C and all its imports). If no revision-stmt is present the server can pick whatever revision it wants. If this is a problem, then fix this problem, don't add some complex monitoring requirements for servers to implement and clients to process. Let's make import-by-revision mandatory if import-without-revision is a such a problem. If the data model leaves it open, then indeed the implementor can choose. What is wrong with reporting what was chosen? If there is just a leaf that says 'default-revision=true' like I proposed, then no problem. But this assumes that there is a single revision that has been used by all imports. Are we sure this will be true for all implementations? Benoit just posted some numbers - OpenDaylight Lithim shipped with 473 YANG modules, about 155 YANG modules that can be extracted in I-Ds for the upcoming IETF, and other SDOs are on their way as well to produce YANG modules. If I assume that products will in a couple of years implement hundreds of YANG modules, do we believe that imports without revision can all be kept at a specific revision throughout the whole system? If I have to reproduce the entire imports/include-imports tree with filled in revision dates, then this is overkill, too much memory/data, and it is a problem. It seems to be a trade-off. If a vendor manages to manage his software very well, then 'default-revision=true' may do its job. If not, then we have no standard way to find out what was actually implemented. So we have the following scenarios: a) Import by revision de-factor disappears. Problem disappears. b) Import by revision does not disappear. 1) Vendor manages to keeps all modules aligned to a single revision, then 'default-revision=true' works. 2) Vendor does not manage to keep all modules aligned to a single revision (btw, this can also be forced on the vendor by modules from differnet SDOs), then we apparently need additional complexity to report what precisely was implemented. One option out could be to strongly recommend a), to provide the 'default-revision=true' possibility, to provide b.2) as a feature for systems where 'default-revision=true' is not workable. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
But don't get mw wrong, syntactically annotations would be allowed everywhere although in some places they may be a no-op. OK This is also valid, see sec. 7.7.6 in RFC 6020: snip/ I see, thanks. True, I'd rather we can find a solution for annotating XML lists. Until then, the draft SHOULD explicitly call it out as not supported. Maybe put in into an OPEN ISSUES section? But that means XML clients would be unable to receive some information. Is it what we want? I agree that is not what we want. Do you have any ideas other than using a processing instruction inside an XML comment? Thanks, Kent (as a contributor) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)
Kent Watsen kwat...@juniper.net writes:
Maybe I don't understand your response, but if we agree that annotations
are a server-level thing (not module-specific), then I do not agree
that a
module's description should be able to say that an annotation should be
ignored in other modules.
It depends on the annotation's semantics, and it may be designed to do
something only for certain node instances (such as leafs with union
type), or for nodes in a given namespace etc. Do you think it may be a
problem?
Those kinds of uses are fine, as they are not module-specific. I just
want to ensure we don't ever wind up with module-specific
annotations
A single namespace is essentially the same as a single module, isn't it?
But don't get mw wrong, syntactically annotations would be allowed
everywhere although in some places they may be a no-op.
I see, but then this make the example misleading. I thought it was
trying
to show how to place an annotation on the list as a whole. I see now
it says list instance, but this seems uninteresting example, as list
I will use list entry because the term instance in not defined in
YANG.
instances are just nodes for which how to apply annotations is already
known - there's nothing special about the node being a list element -
right?
Do you suggest to remove the second example in that section? But you
also wanted to add an example on anydata that is arguable even more
alike to a container.
Yes, an example for each item discussed (including anydata) is desired.
What I'm questioning here is why we need to discuss annotating list
entries at all, since they seem to follow normal rules. If true, I
recommend removing a special section for list entries/instances entirely.
I don't understand. There is no special section for list entries/instances, this
is included in the section 4.2.2 (Adding Annotations to Anydata,
Container and List Instances). I agree an example should be included for
each data node type, i.e. container, list and anydata.
As for the list example, I think it is also important to show that some
entries may be decorated with annotations while other aren't.
An annotation cannot be attached to a list as a whole? - that seems
fundamentally broken, though I understand why you say it cannot be
easily
represented in XML (via attributes). Should we consider alternative
representations?
I agree it might be useful, and I was thinking about it but I haven't
found any good way for encoding it in XML, also because in XML list
entries can be interspersed with other elements.
Interspersed with other elements? - I don't understand. For instance,
assuming:
container foobars {
list foo {
...
}
list bar {
}
}
The XML would be:
foobars
foo.../foo
foo.../foo
foo.../foo
bar.../bar
bar.../bar
bar.../bar
/foobars
Where is the interspersion?
This is also valid, see sec. 7.7.6 in RFC 6020:
foobars
foo.../foo
bar.../bar
foo.../foo
bar.../bar
bar.../bar
foo.../foo
/foobars
As for how to place annotations on an XML list as a whole, I was thinking
we could use a fake first element. For instance, the following shows an
annotation on the bar list:
foobars
foo.../foo
foo.../foo
foo.../foo
bar color=red/ // colors entire list red (notice empty
element)
bar.../bar
bar.../bar
bar.../bar
/foobars
But this is most likely illegal since it's not a valid instance
document.
This would mess up all standard XML tools.
So then maybe we could use an XML comment like this:
foobars
foo.../foo
foo.../foo
foo.../foo
!-- annotation: bar color=red --
bar.../bar
bar.../bar
bar.../bar
/foobars
A processing instruction would be slightly better but yes, it's ugly.
Ugh, this isn't great either. Anybody else have an idea?
That said, if unavoidable, the draft needs to call that out as a
limitation somewhere, because it wan't clear to me. Are there other
limitations that are not also not being called out?
Well, one could e.g. think about structured annotations but this is
again not exactly easy with XML attributes. I don't think though we can
really call it limitations - after all, the motivation for this document
was to officialize the use of XML attributes, so it would be a bit
weird to to make it incompatible with them.
True, I'd rather we can find a solution for annotating XML lists. Until
then, the draft SHOULD explicitly call it out as not supported. Maybe
put in into an OPEN ISSUES section?
But that means XML clients would be unable to receive some
information. Is it what we want?
Lada
Thanks,
Kent (as a contributor)
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] yang:xpath1.0 values and JSON encoding
Jernej Tuljak jernej.tul...@mg-soft.si writes: Hi, since draft-ietf-netmod-yang-json-04 describes a special mapping for instance-identifiers, I'm wondering about how to handle values which are constrained using the standard XML specific yang:xpath1.0 type or a derivative of it. I assume the same or similar rules should apply to any XPath expression that appears in a JSON instance, right? Perhaps this deserves mention in the I-D? From the definition of the xpath1.0 type it seems clear that values of this type must be real XPath expressions as specified in [XPATH]. The necessary context info (including prefix bindings) has to be provided in the description of the data node that uses this type. So this is OK even if xpath1.0 values appear in JSON. Instance-identifiers need a different approach because their context is defined through XML namespace scope that is absent in JSON. Lada Jernej ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
