Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Ladislav Lhotka]

Benoit Claise  writes:

> Hi Lada,
>>
>
> - In the introduction, you mention:
>  Typical use cases are:
>
>  o  Deactivating a subtree in a configuration datastore while keeping
> the data in place.
>
>  o  Complementing data model information with instance-specific data.
>
>  o  RPC operations may use metadata annotations for various purposes
> in both requests and responses.  For example, the 
> operation in the NETCONF protocol (seesection 7.2 of [RFC6241] 
> )
> uses annotations in the form of XML attributes for identifying the
> point in the configuration and type of the operation.
>
>
> Don't you have any other examples than those 3?
> What about showing these examples with the spec. in this document?
> Note: I see that the first one is documented with module
> example-inactive
 Well, the backlash I received with
 draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there
 is consensus about general utility of annotations, practical definitions
 may be controversial.
>>> Even as example?
>> Yes, I am afraid.
> I would be in favor to have at the very minimum one example.
> Otherwise, it's difficult to visualize how these metadata should be
> used.

Sure, there will be at least one. I just have to select an appropriate
one to demonstrate the intended use without stirring up some ghosts.

Lada

>
> Regards, Benoit (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] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Ladislav Lhotka]

Andy Bierman  writes:

> On Wed, Jul 1, 2015 at 7:41 AM, Benoit Claise  wrote:
>
>> Hi Lada,
>>
>>>
>>>
>> - In the introduction, you mention:
>>  Typical use cases are:
>>
>>  o  Deactivating a subtree in a configuration datastore while
>> keeping
>> the data in place.
>>
>>  o  Complementing data model information with instance-specific
>> data.
>>
>>  o  RPC operations may use metadata annotations for various
>> purposes
>> in both requests and responses.  For example, the 
>> operation in the NETCONF protocol (seesection 7.2 of [RFC6241]
>> )
>> uses annotations in the form of XML attributes for identifying
>> the
>> point in the configuration and type of the operation.
>>
>>
>> Don't you have any other examples than those 3?
>> What about showing these examples with the spec. in this document?
>> Note: I see that the first one is documented with module
>> example-inactive
>>
> Well, the backlash I received with
> draft-lhotka-netmod-yang-annotations-00 (expired) show that whilst there
> is consensus about general utility of annotations, practical definitions
> may be controversial.
>
 Even as example?

>>> Yes, I am afraid.
>>>
>> I would be in favor to have at the very minimum one example.
>> Otherwise, it's difficult to visualize how these metadata should be used.
>>
>>
>
> We support an attribute called "owner" which is basically the I2RS
> client-id.
> At ;least one solution proposal for I2RS is going to allow retrieval of the
> metadata from the ephemeral datastore (e.g., client-id, secondary-id).
> Perhaps an example like this will not be controversial.


Yes, this looks like a good one, thanks.

Lada

>
>
>
>> Regards, Benoit (as a contributor)
>>
>
>
> Andy
>
>
>>
>> ___
>> 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

Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> 
>> > On 01 Jul 2015, at 16:25, Benoit Claise  wrote:
>> > 
>> > Hi Lada,
>> >>> ay
>> >>> -
>> >>> The set of annotations must be extensible in a distributed manner
>> >>> so as to allow for defining new annotations without running into
>> >>> the risk of collisions with annotations defined and used by
>> >>> others.
>> >>> 
>> >>> What does "in a distributed manner" mean?
>> >> It means that different parties needn't coordinate the names and use of
>> >> annotations, as long as they don't choose conflicting YANG module names
>> >> or namespace URIs.
>> > Ok, it was not too clear (to me) from the text.
>> 
>> I will add text to explain what “distributed” means.
>
> Maybe call it "decentralized"?

Yes, this looks better.

Lada

>
>
>
> /martin

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

[Ladislav Lhotka]

Kent Watsen  writes:

>>>1. In Section 3, it says:
>>>
>>>
>>>   Does this mean that the annotation A can be used by *any* module
>>>   the server advertises, or just the modules that define/import
>>>   annotation A?
>>
>>For all modules implemented by the server, no import is needed.
>
>
> Good, but I think the text should say this explicitly.

OK.

>
>
>
>>>   I assume that the intent is for the annotation to apply to
>>>   the server as a whole, not any specific module.  It might
>>
>>Yes. The description can also say that the annotation is ignored
>>elsewhere.
>
> 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?


>
>
>>>   help enforce this if annotations can only be defined in
>>>   modules that don't define any data-nodes and it is required
>>>   that the server advertises this module explicitly (not via
>>>   an import)...
>>
>>I expect this will be the normal way of defining annotations, and it
>>could appear in the document as a guideline. I don't think though it is
>>necessary to state it as a hard rule.
>
> OK, a SHOULD or RECOMMENDED statement would help to clarify this.
>

OK.

>
>
>>>3. In Section 4.2.2, adding metadata to the first entry in a list doesn't
>>> seem elegant.  Can we instead create a special list element like the
>>> following?
>>
>>Maybe I don't understand but the idea is that a separate metadata objects
>>can be attached to any or all entries of a list. In the example it is
>>added only to the first entry but another metadata object could be added
>>to the second entry as well.
>
> 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.

>
>
>
>
>>It is not possible to add an annotation to the whole list, also because
>>this cannot be represented in XML encoding (via attributes).
>
> 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.

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

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] WG Last Call for draft-ietf-netmod-yang-metadata-01 (until 2015-06-29)

[Kent Watsen]

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



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



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

  
...

...

...

...


...

...

  

Where is the interspersion?

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:

  
...
...
...
   // colors entire list "red"  (notice empty
element)
...
...
...
  


But this is most likely illegal since it's not a valid instance document.
So then maybe we could use an XML comment like this:

  
...
...
...

...
...
...
  


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?


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-json-04 (until 2015-06-29)

[Andy Bierman]

On Wed, Jul 1, 2015 at 11:33 PM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > I agree with Juergen that the implementation of YANG constraints
> > on  a datastore is not XML-specific.  The text refers to data nodes
> > not XML elements.  It is quite possible for a server to populate data
>
> The text says in sec. 6.4: "The data model used in the XPath expressions
> is the same as that used in XPath 1.0 [XPATH], …", and the data model in
> [XPATH] is about elements, attributes, namespaces etc. In order to
> correctly interpret [XPATH], one needs to map (conceptually, if you
> wish) the data tree onto the XPath data model.
>
> > nodes in a datastore without NETCONF of XML being involved.
>
> And what about RPCs and notifications? In this case the accessible data
> tree is defined as the corresponding XML instance document.
>
>

There is no possibility for data to be converted between
XML and JSON if this is the case.



> Consider this definition:
>
>   rpc foo {
> input {
>   leaf x {
> type uint8;
> must ". = ../y";
>   }
>   leaf y {
> type string;
>   }
> }
>   }
>
> Then what's the result of conceptual XPath evaluation for this RPC
> request?
>
>

Just because you can construct a pathological
case comparing strings and numbers doesn't
mean anything.

Use "number(foo) < number(bar)" to ensure that
numeric comparisons are done correctly.




>   http://example.com/xtest";>
> +1
> 1
>   
> 
>
> And how about this RPC input in JSON?
>
> {
>   "foorpc:input": {
> "x": +1,
> "y": "1"
>   }
> }
>
> >
> > We keep getting stuck on the difference between resource representations
> > on the wire, and implementation details within a client or server.
>
> This is not my problem here.
>
>

There are lots of XPath expressions that can be constructed
that create problems because of the way XPath converts
types by default.  That is why there are functions number(), string(), etc.




> Lada
>

Andy


>
> > There is no requirement that they be the same "XML or JSON".
> > inside.
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET)

[Mahesh Jethanandani]

> On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit)  wrote:
> 
> What might be interesting for a NETCONF speaking slot is an analysis of what 
> requirements from “draft-ietf-i2rs-pub-sub-requirements” are met by 
> “draft-clemm-netconf-yang-push”. 

Susan or somebody from i2rs WG can decide whether the suggested presentation 
would help clarify i2rs requirements to NETCONF. From a personal perspective it 
would certainly help to have examples of how the requirements could be met.

Cheers.

Mahesh Jethanandani
mjethanand...@gmail.com



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET)

[Susan Hares]

Mahesh: 

 

I think this would really help show how the requirements can be met. Let’s plan 
on Eric doing an analysis of what requirements are met by 
“draft-clemm-netconf-yang-push”. 

 

Sue 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Thursday, July 02, 2015 5:06 PM
To: Eric Voit (evoit)
Cc: rtg-yang-co...@ietf.org; i...@ietf.org; NETMOD Working Group; BRUNGARD, 
DEBORAH A; Alexander Clemm (alex); Netconf; Susan Hares
Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol 
and I2RS interim (6/24/2015 at 10:00 - 11:30am ET)

 

 

On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit)  wrote:

 

What might be interesting for a NETCONF speaking slot is an analysis of what 
requirements from “draft-ietf-i2rs-pub-sub-requirements” are met by 
“draft-clemm-netconf-yang-push”. 

 

Susan or somebody from i2rs WG can decide whether the suggested presentation 
would help clarify i2rs requirements to NETCONF. From a personal perspective it 
would certainly help to have examples of how the requirements could be met.

 

Cheers.

 

Mahesh Jethanandani

mjethanand...@gmail.com

 

 

 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET)

[Susan Hares]

Mahesh: 

 

I’m trying to schedule a set of meeting before I2RS presents at NETCONF so it 
would be helpful to know when the I2RS session would be schedule in NETCONF. 

 

Is I2RS requirements presentation at the Tuesday meeting with Netconf [15:20 – 
17:20] which is just before the I2RS meeting [17:40- 18:40].  This back-to-back 
session would allow us to encourage people to hear the presentations in NETCONF 
and then come to I2RS to discuss any open issues for I2RS.  

 

Do you think we should present the NETMOD requirements before the NETCONF 
requirements?  I can request a brief presentation in NETMOD.  I am working on a 
draft to express I2RS requirements for netmod.  The requirements for NETMO will 
not be an I2RS WG document – only a chair’s observations on the differences 
between the yang modules. 

 

Sue Hares 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Mahesh Jethanandani
Sent: Thursday, July 02, 2015 5:06 PM
To: Eric Voit (evoit)
Cc: rtg-yang-co...@ietf.org; i...@ietf.org; NETMOD Working Group; BRUNGARD, 
DEBORAH A; Alexander Clemm (alex); Netconf; Susan Hares
Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol 
and I2RS interim (6/24/2015 at 10:00 - 11:30am ET)

 

 

On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit)  wrote:

 

What might be interesting for a NETCONF speaking slot is an analysis of what 
requirements from “draft-ietf-i2rs-pub-sub-requirements” are met by 
“draft-clemm-netconf-yang-push”. 

 

Susan or somebody from i2rs WG can decide whether the suggested presentation 
would help clarify i2rs requirements to NETCONF. From a personal perspective it 
would certainly help to have examples of how the requirements could be met.

 

Cheers.

 

Mahesh Jethanandani

mjethanand...@gmail.com

 

 

 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod