Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Lisa (Yi) Huang]

On 1/22/16, 4:40 AM, "netmod on behalf of Acee Lindem (acee)"
 wrote:

>
>
>On 1/22/16, 12:56 AM, "netmod on behalf of Ebben Aries"
> wrote:
>
>>
>>On 01/21/2016 12:45 AM, Qin Wu wrote:
>>> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the other
>>>is ietf-access-control-list module,
>>> I am wondering whether ietf-packet-fields module can be defined in more
>>>generic way that can be applied to other modules defined somewhere else?
>>> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is
>>>defined, I am wondering whether prefix "acl-" can be removed to make it
>>>more generic?
>>
>>What you'll likely run into here is that the header fields defined in
>>acl-*-header-fields are more or less the lowest common denominators for
>>the application of "acl" - Not all header fields are defined here.
>>
>>I suppose an approach could be to define generic groupings of all header
>>fields and create per application groupings, referencing what is
>>supported with appropriate constraints, etc...  Not sure what that buys
>>here since you're likely to have overlap but not complete parity between
>>the different consumers of these packet fields.
>
>Furthermore, this is not a generic IP packet fields YANG module. It is a
>module for matching IP packet fields using traditional ACL semantics.
>Hence, changing the container name won¹t change the content or semantics.
>If anything, the module name should be changed to include ³acl-³ and not
>imply that it is generic.
>Thanks,
>Acee

There is no intention to include all packet fields in this module but QoS
could reuse this module.

Thanks,
Lisa


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

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

Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Mahesh Jethanandani]

> On Jan 22, 2016, at 12:46 PM, Lisa (Yi) Huang  wrote:
> 
> 
> 
> On 1/22/16, 4:40 AM, "netmod on behalf of Acee Lindem (acee)"
>  on behalf of 
> a...@cisco.com > wrote:
> 
>> 
>> 
>> On 1/22/16, 12:56 AM, "netmod on behalf of Ebben Aries"
>>  wrote:
>> 
>>> 
>>> On 01/21/2016 12:45 AM, Qin Wu wrote:
 1. This draft defines two module, one is IETF-PACKET-FIELDS, the other
 is ietf-access-control-list module,
 I am wondering whether ietf-packet-fields module can be defined in more
 generic way that can be applied to other modules defined somewhere else?
 e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is
 defined, I am wondering whether prefix "acl-" can be removed to make it
 more generic?
>>> 
>>> What you'll likely run into here is that the header fields defined in
>>> acl-*-header-fields are more or less the lowest common denominators for
>>> the application of "acl" - Not all header fields are defined here.
>>> 
>>> I suppose an approach could be to define generic groupings of all header
>>> fields and create per application groupings, referencing what is
>>> supported with appropriate constraints, etc...  Not sure what that buys
>>> here since you're likely to have overlap but not complete parity between
>>> the different consumers of these packet fields.
>> 
>> Furthermore, this is not a generic IP packet fields YANG module. It is a
>> module for matching IP packet fields using traditional ACL semantics.
>> Hence, changing the container name wonąt change the content or semantics.
>> If anything, the module name should be changed to include łacl-ł and not
>> imply that it is generic.
>> Thanks,
>> Acee
> 
> There is no intention to include all packet fields in this module but QoS
> could reuse this module.

The QoS module has defined its own set of fields that packets could get 
classified on, and has no plans to use the ACL packet field definitions.

> 
> Thanks,
> Lisa
> 
> 
>> 
>> 
>>> 
>>> /ebben
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netmod 
>>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod 
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
Mahesh Jethanandani
mjethanand...@gmail.com





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

Re: [netmod] Constraining instance-identifiers

[Martin Bjorklund]

Andy Bierman  wrote:
> On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Andy Bierman  wrote:
> > > Hi,
> > >
> > > I am strongly against adding more features to YANG 1.1 at this time.
> >
> > Do you refer to the proprietary extension to restrict i-is?  If so, I
> > agree (and Balazs just did in a separate email as well) that this is
> > out of scope.
> >
> >
> How would such an extension work, given that a tool MAY ignore
> this extension? A plain client thinks the instance-identifier can
> hold any valid instance, and is surprised that valid values are rejected by
> the server (which don't match the magic extension rules)

The additional validation rule is (hopefully) specified in the
description.  The extension just tells the implementation to do the
validation automatically; the alternative is for the user to write
custom code.

> Use XPath to further restrict the instance, so a plain client can see it.

How?  (note how Balazs' "hack" uses a normal "must" statement).


/martin

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

Re: [netmod] Constraining instance-identifiers

[Andy Bierman]

Hi,

The description-stmt is good enough.
Let's stop the feature-creep and get YANG 1.1 done.
Just keep using your proprietary extensions that tells
your proprietary tools how to special process the i-i value.


Andy


On Fri, Jan 22, 2016 at 10:42 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund 
> wrote:
> >
> > > Hi,
> > >
> > > Andy Bierman  wrote:
> > > > Hi,
> > > >
> > > > I am strongly against adding more features to YANG 1.1 at this time.
> > >
> > > Do you refer to the proprietary extension to restrict i-is?  If so, I
> > > agree (and Balazs just did in a separate email as well) that this is
> > > out of scope.
> > >
> > >
> > How would such an extension work, given that a tool MAY ignore
> > this extension? A plain client thinks the instance-identifier can
> > hold any valid instance, and is surprised that valid values are rejected
> by
> > the server (which don't match the magic extension rules)
>
> The additional validation rule is (hopefully) specified in the
> description.  The extension just tells the implementation to do the
> validation automatically; the alternative is for the user to write
> custom code.
>
> > Use XPath to further restrict the instance, so a plain client can see it.
>
> How?  (note how Balazs' "hack" uses a normal "must" statement).
>
>
> /martin
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Validation question

[Ladislav Lhotka]

Hi William,

YANG uses XPath 1.0, and so the equality tests mean *string
equality*. That's why 6087bis recommends in sec. 5.6.4:

   XPath expressions that contain a literal value representing a YANG
   identity SHOULD always include the declared prefix of the module
   where the identity is defined.

In YANG 1.1, the new XPath functions derived-from() and
derived-from-or-self() will alleviate this problem.

Lada

William Lupton  writes:

> All,
>
> We have been experimenting with validating XML instances along the lines 
> explained in the tutorials at 
> http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial 
>  and 
> https://github.com/mbj4668/pyang/wiki/InstanceValidation 
>  and we have hit a 
> problem with identities in XPath expressions.
>
> This is illustrated by the YANG module shown below, which is inspired by an 
> example in RFC 6020bis, and the XML instance shown below the YANG. Note that:
> The second "when" statement doesn't use a prefix on the interface type.
> Shouldn't be a problem because the interface type is defined in the current 
> module and so doesn't need a prefix?
> The XML uses a prefix name of "exaug" rather than "mymod" which is used in 
> the YANG.
> Shouldn't be a problem because prefixes should be local?
>
> Validating this instance gives the following two errors (which go away if the 
> prefix "mymod" is used in all "when" statements and in the XML).
>
> == Validating semantic constraints ...
> --- Validity error at "/nc:data/if:interfaces/if:interface":
> Found nodes that are valid only when "if:type = 'mymod:some-new-iftype'"
> --- Validity error at "/nc:data/if:interfaces-state/if:interface":
> Found nodes that are valid only when "if:type = 'some-new-iftype'"
>
> Are we doing something wrong here, or is there a problem with how identities 
> in XPath expressions are translated (per RFC 6110)? On the face of it it 
> seems that identities are being treated as literal strings (but we haven't 
> investigated this assertion).
>
> Thanks,
> William Lupton
>
> 
>
> YANG:
> module example-augment {
>   namespace "http://example.com/augment;;
>   prefix mymod;
>   
>   import ietf-interfaces {
> prefix if;
>   }
>   
>   identity some-new-iftype {
> base if:interface-type;
>   }
>   
>   augment "/if:interfaces/if:interface" {
> when "if:type = 'mymod:some-new-iftype'";
>
> container some-new-container {
> }
>   }
>
>   augment "/if:interfaces-state/if:interface" {
> when "if:type = 'some-new-iftype'";
>
> container some-new-container {
> }
>   }
> }
>
> XML:
> 
>xmlns:exaug="http://example.com/augment;>
>   
> 
>   
>   
>   exaug:some-new-iftype
>   true
>   enabled
>   http://example.com/augment;>
>   
> 
>   
>   
> 
>   
>   exaug:some-new-iftype
>   up
>   up
>   1
>   
> 2016-01-15T12:55:00Z
>   
>   http://example.com/augment;>
>   
> 
>   
> 
>
>
> ___
> 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] Constraining instance-identifiers

[Andy Bierman]

Hi,

I am strongly against adding more features to YANG 1.1 at this time.
The deadline for new features has long passed.


Andy


On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <
balazs.leng...@ericsson.com> wrote:

> Hello,
> I agree we don't need to change the encoding, but we need to define how
> that encoding is visible/available when evaluating Xpath expressions. Today
> the draft says:
> - instance-identifier does not have a canonical format
> - XPath uses the canonical format
> The two together make it impossible to use it in Xpath, even though there
> are people that would like to do that.
> - Martin mentioned a proprietary extension
> - we would like it.
>
> So I would propose to
>  change to 9.1
>
> Old: In particular, any XPath expression evaluations are done using the 
> canonical form.
>
> New:  In particular, whenever a canonical form exists, any XPath
> expression evaluations are done using the canonical form.
>
> --- add to 9.13.2
>
> For instance-identifiers XPath expression evaluations are done using the 
> lexical form.
>
>
> regards Balazs
>
>
> On 2016-01-21 18:53, Andy Bierman wrote:
>
> Hi,
>
> There is no need to change the XML encoding or YANG encoding
> of an instance-identifier.  The prefixes are completely different
> in each.  Prefixes clashes do happen, especially since
> there is no expectation that they are unique.  They are short strings
> with no naming conventions at all.  E.g., I have seen "if" for
> interfaces in multiple modules.
>
> Andy
>
>
> On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <
> balazs.leng...@ericsson.com> wrote:
>
>> Hello Martin,
>> If the RFC would define that in XPath expressions an instance identifier
>> MUST be evaluated to a string that complies to the lexical format, using
>> the rematch function, we could do everything we need. In real life prefix
>> clashes are a rare problem.
>> regards Balazs
>>
>> On 2016-01-21 16:17, Martin Bjorklund wrote:
>>
>>> Balazs Lengyel  wrote:
>>>
 Hello,
 We have some instance identifiers in our model but we want to
 contrain what they can point at. What is the best method for that?

>>> Unfortunately, there is no standard way of doing this.  (There are
>>> vendor extensions available...)
>>>
>>> [...]
>>>
>>> Some issues:
 - instance-identifiers don't have a canonical format, so what is
 their value in an XPath expression?

>>> This is not defined.
>>>
>>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?

>>> In YANG 1.1, there is a function re-match() for this purpose.  For
>>> your use case, it *may* work to match just the local names of all
>>> nodes, i.e., using wildcards for the prefixes.  It is not a generic
>>> solution though.
>>>
>>> - if I have all the needed namespace prefixes in imports, can I just
use them?

>>> No, these prefixes are local to the module that is doing the import,
>>> and they may or may not match the prefixes used by the implementation
>>> when it construct the instance-identifier value.
>>>
>>>
>>>
>>> /martin
>>>
>>>
>> --
>> Balazs Lengyel   Ericsson Hungary Ltd.
>> Senior Specialist
>> ECN: 831 7320
>> Mobile: +36-70-330-7909  email: 
>> balazs.leng...@ericsson.com
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
> --
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comparison of structural-mount and ysdl drafts

[Ladislav Lhotka]

Robert Wilton  writes:

> Hi Lada, Martin,
>
> I've reviewed both draft-bjorklund-netmod-structural-mount-00 and 
> draft-lhotka-netmod-ysdl-00.
>
> In comparing these two drafts, the main differences that I perceive are:
>
> 1) structural-mount allows the mounted data model to publish its 
> supported schema at the mount point, but ysdl requires the mounting 
> device to know and publish the schema for all mounted data models.

I am not sure what you mean by "publish" but I think really the only
difference is that structural-mount provides schema information as
regular state data and YSDL as meta-data.

In my view, the definition of a data model schema is really
meta-data. The module "ietf-yang-structural-mount" and its data would
require special treatment anyway - for example, it has to be found in a
well-known location, so it cannot itself be mounted.

> 2) A corollary of (1) is that structural-mount also allows different 
> schema data models to be published at the mount point (e.g. under a 
> list), but ysdl does not.

True, but it can be easily emulated by using either a choice (or a
"dynamic choice" using "when") and defining different sub-schemas as
different cases. I'd argue this is a more robust approach.

> 3) structural-mount has a mount node embedded directly in the schema, 
> where as for ysdl, the equivalent mount points are only specified in the 
> ysdl meta-schema.
> 4) ysdl is extensible to cover other non mount related use-cases (such 
> as anydata) where being able to dynamically make available the schema is 
> useful.
> 5) structural-mount also covers RPCs and Notifications, whereas these 
> appear to be outside the scope of ysdl.

This is just an omission on the part of YSDL. The approach proposed for
structural-mount can be used as well.

> 6) The ysdl meta-data language appears to be more flexible, and hence 
> also more complex, than the equivalent "mount-points" schema defined in 
> structural-mount.
> 7) For structural-mount the "mount-points" table is returned as a normal 
> oper data YANG module in the mounting device, whereas for ysdl, protocol 
> extensions would be required to NETCONF/RESTCONF to access the schema 
> meta-data.

First, structural-mount uses an extension that has to be considered
mandatory because otherwise no interoperability can take place. So I
don't think that it seamlessly integrates into NETCONF/RESTCONF.

And second, I actually considered to simply extend yang-library with the
YSDL data, but I decided to keep it separate in order to avoid
additional delays for the yang-library spec.

>
> Considering these differences:
>
> For points (1) and (2), I can think of scenarios where having a mounted 
> device being able to provide its schema via yang-library and for that 
> schema to differ for different mounted devices is probably a requirement 
> for some plausible mount scenarios.  E.g. one that I can think of is the 
> case that you have a YANG controller that is exposing an aggregated YANG 
> model for a set of devices, it seems that you would need to be 
> accommodate mounted devices that are made by different vendors and 
> running different software versions which would imply that their schema 
> may also be different.

Right, you would use a (dynamic) choice in this case.

>
> For point (3), this is a matter of preference, I like that fact that the 
> mount point is explicit in the schema in structural-mount.  The ysdl

But this means using a YANG extension with all the problems regarding
conformance. And this extension is quite far-reaching.

Lada

> meta-schema appears to be more flexible because it can in effect put 
> mount points anywhere, but even with structural mount this same 
> flexibility could presumably still be achieved by augmenting with a 
> mount point.
>
> For point (4), I think that this is useful functionality, and perhaps if 
> structural-mount is to be used as the base draft going forward it might 
> be worth considering whether the solution could be able to cover, or be 
> cleanly extended, to this use case.
>
> For point (5), I definitely think that it is beneficial that 
> structural-mount has an intuitive solution for RPCs and Notifications.
>
> For points (6) and (7) my gut instinct is that the structural-mount 
> would be easier to standardize and also less work to implement.
>
>
> Some of my points above may be incorrect, and that might swing the 
> balance between the two solutions, so please correct me if I have got 
> anything wrong.  Otherwise, just considering the written drafts as they 
> stand now, my personal preference is that I would favour using 
> structural-mount as a starting point for a solution.
>
> Martin, I also have some comments/questions on the structural-mount 
> draft, I'll put these into a separate email.
>
> Thanks,
> Rob

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

___
netmod mailing list
netmod@ietf.org

Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Acee Lindem (acee)]

On 1/22/16, 12:56 AM, "netmod on behalf of Ebben Aries"
 wrote:

>
>On 01/21/2016 12:45 AM, Qin Wu wrote:
>> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the other
>>is ietf-access-control-list module,
>> I am wondering whether ietf-packet-fields module can be defined in more
>>generic way that can be applied to other modules defined somewhere else?
>> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is
>>defined, I am wondering whether prefix "acl-" can be removed to make it
>>more generic?
>
>What you'll likely run into here is that the header fields defined in
>acl-*-header-fields are more or less the lowest common denominators for
>the application of "acl" - Not all header fields are defined here.
>
>I suppose an approach could be to define generic groupings of all header
>fields and create per application groupings, referencing what is
>supported with appropriate constraints, etc...  Not sure what that buys
>here since you're likely to have overlap but not complete parity between
>the different consumers of these packet fields.

Furthermore, this is not a generic IP packet fields YANG module. It is a
module for matching IP packet fields using traditional ACL semantics.
Hence, changing the container name won’t change the content or semantics.
If anything, the module name should be changed to include “acl-“ and not
imply that it is generic.

Thanks,
Acee



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

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

Re: [netmod] Constraining instance-identifiers

[Balazs Lengyel]

  
  
Hello,
This is a clarification not a new feature. I am 100%  sure all
implementations already support the lexical representation of
instance-identifiers, otherwise they would not be able to read and
write them.
For new features I agree it is too late.
regards Balazs

On 2016-01-22 13:14, Andy Bierman
  wrote:


  
  Hi,


I am strongly against adding more features to YANG 1.1 at
  this time.
The deadline for new features has long passed.




Andy


  
  
On Fri, Jan 22, 2016 at 12:27 AM,
  Balazs Lengyel 
  wrote:
  
 Hello,
  I agree we don't need to change the encoding, but we need
  to define how that encoding is visible/available when
  evaluating Xpath expressions. Today the draft says:
  - instance-identifier does not have a canonical format
  - XPath uses the canonical format
  The two together make it impossible to use it in Xpath,
  even though there are people that would like to do that.
  - Martin mentioned a proprietary extension
  - we would like it.
  
  So I would propose to 
   change to 9.1
  Old: In particular, any XPath _expression_ evaluations are done using the canonical form.
  New:  In particular, whenever a canonical form exists, any
  XPath _expression_ evaluations are done using the canonical
  form. 
  
  --- add to 9.13.2
  For instance-identifiers XPath _expression_ evaluations are done using the lexical form.
  
  regards Balazs
  
  
  On 2016-01-21 18:53, Andy Bierman wrote:
  
  
Hi,
  
  
  There is no need to change the XML encoding or
YANG encoding
  of an instance-identifier.  The prefixes are
completely different
  in each.  Prefixes clashes do happen, especially
since
  there is no expectation that they are unique. 
They are short strings
  with no naming conventions at all.  E.g., I have
seen "if" for
  interfaces in multiple modules.
  
  
  Andy
  
  
  

  On Thu, Jan 21, 2016 at
8:51 AM, Balazs Lengyel 
wrote:
Hello Martin,
  If the RFC would define that in XPath
  expressions an instance identifier MUST be
  evaluated to a string that complies to the
  lexical format, using the rematch function, we
  could do everything we need. In real life
  prefix clashes are a rare problem.
  regards Balazs
  
  On 2016-01-21 16:17, Martin Bjorklund wrote:
   Balazs Lengyel


wrote:
 Hello,
  We have some instance identifiers in our
  model but we want to
  contrain what they can point at. What is
  the best method for that?

Unfortunately, there is no standard way of
doing this.  (There are
vendor extensions available...)

[...]

 Some issues:
  - instance-identifiers don't have a
  canonical format, so what is
  their value in an XPath _expression_?

This is not defined.

 - I didn't
  find a way to evaluate a regexp in XPath
  1.0. Is there a way?

In YANG 1.1, there is a function re-match()
for this purpose.  For
your use case, it *may* work to match just
the local names of all

Re: [netmod] Validation question

[William Lupton]

Lada,

Thanks for drawing my attention to this section. I hadn't noticed this advice.

Perhaps corresponding things need to be said about the XML?
Always use a prefix on identity values, even if the default namespace (YANG 
module) is the module that defined the identity.
When importing a namespace (YANG module) that contains identities that are 
referenced in the XML, always use the same prefix that was used within the 
imported module.

The need for the first of the above XML-related statements wasn't illustrated 
by the YANG and XML in my first message but it's illustrated by the fragments 
shown below.

I guess the point about derived-from() and derived-from-or-self() is that, 
although they still specify the identities as strings, the strings are known to 
be identities, so prefixes can be processed (applying defaults etc)?

Finally, I think perhaps this is a separate point (because not related to 
string values), but seems to be necessary to use the same prefixes for imported 
modules as were used within those modules. For example, if (in my example) I 
change the ietf-interfaces prefix from if to ifx, validation fails with an 
"undefined namespace prefix" error.

Cheers,
William

YANG fragment:
  identity sub-type;

  identity sub-type-a {
base sub-type;
  }

  augment "/if:interfaces/if:interface" {
when "if:type = 'mymod:some-new-iftype'";

container some-new-container {
  leaf sub-type {
type identityref {
  base sub-type;
}
  }
  container sub-container {
when "../mymod:sub-type = 'mymod:sub-type-a'";
  }
}
  }

XML fragment (mymod prefix is necessary in order for XML to validate):
  http://example.com/augment;>
mymod:sub-type-a

  

> On 22 Jan 2016, at 09:32, Ladislav Lhotka  wrote:
> 
> Hi William,
> 
> YANG uses XPath 1.0, and so the equality tests mean *string
> equality*. That's why 6087bis recommends in sec. 5.6.4:
> 
>   XPath expressions that contain a literal value representing a YANG
>   identity SHOULD always include the declared prefix of the module
>   where the identity is defined.
> 
> In YANG 1.1, the new XPath functions derived-from() and
> derived-from-or-self() will alleviate this problem.
> 
> Lada
> 
> William Lupton  writes:
> 
>> All,
>> 
>> We have been experimenting with validating XML instances along the lines 
>> explained in the tutorials at 
>> http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial 
>>  and 
>> https://github.com/mbj4668/pyang/wiki/InstanceValidation 
>>  and we have hit a 
>> problem with identities in XPath expressions.
>> 
>> This is illustrated by the YANG module shown below, which is inspired by an 
>> example in RFC 6020bis, and the XML instance shown below the YANG. Note that:
>> The second "when" statement doesn't use a prefix on the interface type.
>> Shouldn't be a problem because the interface type is defined in the current 
>> module and so doesn't need a prefix?
>> The XML uses a prefix name of "exaug" rather than "mymod" which is used in 
>> the YANG.
>> Shouldn't be a problem because prefixes should be local?
>> 
>> Validating this instance gives the following two errors (which go away if 
>> the prefix "mymod" is used in all "when" statements and in the XML).
>> 
>> == Validating semantic constraints ...
>> --- Validity error at "/nc:data/if:interfaces/if:interface":
>>Found nodes that are valid only when "if:type = 'mymod:some-new-iftype'"
>> --- Validity error at "/nc:data/if:interfaces-state/if:interface":
>>Found nodes that are valid only when "if:type = 'some-new-iftype'"
>> 
>> Are we doing something wrong here, or is there a problem with how identities 
>> in XPath expressions are translated (per RFC 6110)? On the face of it it 
>> seems that identities are being treated as literal strings (but we haven't 
>> investigated this assertion).
>> 
>> Thanks,
>> William Lupton
>> 
>> 
>> 
>> YANG:
>> module example-augment {
>>  namespace "http://example.com/augment;;
>>  prefix mymod;
>> 
>>  import ietf-interfaces {
>>prefix if;
>>  }
>> 
>>  identity some-new-iftype {
>>base if:interface-type;
>>  }
>> 
>>  augment "/if:interfaces/if:interface" {
>>when "if:type = 'mymod:some-new-iftype'";
>> 
>>container some-new-container {
>>}
>>  }
>> 
>>  augment "/if:interfaces-state/if:interface" {
>>when "if:type = 'some-new-iftype'";
>> 
>>container some-new-container {
>>}
>>  }
>> }
>> 
>> XML:
>> 
>> >  xmlns:exaug="http://example.com/augment;>
>>  
>>
>>  
>>  
>>  exaug:some-new-iftype
>>  true
>>  enabled
>>  http://example.com/augment;>
>>  
>>
>>  
>>  
>>
>>  
>>  exaug:some-new-iftype
>>  up
>>  up
>>  1
>>  
>>2016-01-15T12:55:00Z
>>  

Re: [netmod] Comparison of structural-mount and ysdl drafts

[Robert Wilton]

Hi Lada,

Please see inline ...

On 22/01/2016 12:41, Ladislav Lhotka wrote:

Robert Wilton  writes:


Hi Lada, Martin,

I've reviewed both draft-bjorklund-netmod-structural-mount-00 and
draft-lhotka-netmod-ysdl-00.

In comparing these two drafts, the main differences that I perceive are:

1) structural-mount allows the mounted data model to publish its
supported schema at the mount point, but ysdl requires the mounting
device to know and publish the schema for all mounted data models.

I am not sure what you mean by "publish" but I think really the only
difference is that structural-mount provides schema information as
regular state data and YSDL as meta-data.
I was really referring to the inline-yang-library option in structural 
mount that allows the actual YANG schema to be deferred to the mounted 
device implementing yang-library (and which is available at the mount 
point).  This is the option that I would anticipate would be used in the 
LNE model.




In my view, the definition of a data model schema is really
meta-data. The module "ietf-yang-structural-mount" and its data would
require special treatment anyway - for example, it has to be found in a
well-known location, so it cannot itself be mounted.
Yes, I can see how it is meta-data, but I'm not sure that it is 
significantly different from the information provided in yang-library 
which is represented a s regular YANG operational module.


For structural-mount: A mounted model should be able to make the 
mount-points structure available at the mount point if required. I.e. 
the solution is able to naturally recurse (as Martin confirmed in reply 
to Robert Varga's email).





2) A corollary of (1) is that structural-mount also allows different
schema data models to be published at the mount point (e.g. under a
list), but ysdl does not.

True, but it can be easily emulated by using either a choice (or a
"dynamic choice" using "when") and defining different sub-schemas as
different cases. I'd argue this is a more robust approach.
I don't think that emulating this with a choice is going to be 
particularly clean.  In addition, the device that is doing the mounting 
doesn't necessarily know what models the mounted device actual 
implements.  For ysdl to work for this scenario, the mounting device 
would probably need to query the yang-library (and/or ysdl 
meta-information to allow the solution to recurse) for each mounted 
device to construct the meta-data for it.  At this point I would argue 
that it is easier to just provide direct access to the yang-library for 
the mounted device (as structural-mount solution proposes).





3) structural-mount has a mount node embedded directly in the schema,
where as for ysdl, the equivalent mount points are only specified in the
ysdl meta-schema.
4) ysdl is extensible to cover other non mount related use-cases (such
as anydata) where being able to dynamically make available the schema is
useful.
5) structural-mount also covers RPCs and Notifications, whereas these
appear to be outside the scope of ysdl.

This is just an omission on the part of YSDL. The approach proposed for
structural-mount can be used as well.

OK.




6) The ysdl meta-data language appears to be more flexible, and hence
also more complex, than the equivalent "mount-points" schema defined in
structural-mount.
7) For structural-mount the "mount-points" table is returned as a normal
oper data YANG module in the mounting device, whereas for ysdl, protocol
extensions would be required to NETCONF/RESTCONF to access the schema
meta-data.

First, structural-mount uses an extension that has to be considered
mandatory because otherwise no interoperability can take place. So I
don't think that it seamlessly integrates into NETCONF/RESTCONF.
I think that only clients and devices that need to mount other models 
would need to support it.  Whether this means it becomes mandatory would 
presumable depend on how widely the mount node used in standard YANG models.




And second, I actually considered to simply extend yang-library with the
YSDL data, but I decided to keep it separate in order to avoid
additional delays for the yang-library spec.


Considering these differences:

For points (1) and (2), I can think of scenarios where having a mounted
device being able to provide its schema via yang-library and for that
schema to differ for different mounted devices is probably a requirement
for some plausible mount scenarios.  E.g. one that I can think of is the
case that you have a YANG controller that is exposing an aggregated YANG
model for a set of devices, it seems that you would need to be
accommodate mounted devices that are made by different vendors and
running different software versions which would imply that their schema
may also be different.

Right, you would use a (dynamic) choice in this case.

As per above, I'm not really convinced that this works as a solution.




For point (3), this is a matter of preference, I like 

Re: [netmod] Constraining instance-identifiers

[Andy Bierman]

On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund  wrote:

> Hi,
>
> Andy Bierman  wrote:
> > Hi,
> >
> > I am strongly against adding more features to YANG 1.1 at this time.
>
> Do you refer to the proprietary extension to restrict i-is?  If so, I
> agree (and Balazs just did in a separate email as well) that this is
> out of scope.
>
>
How would such an extension work, given that a tool MAY ignore
this extension? A plain client thinks the instance-identifier can
hold any valid instance, and is surprised that valid values are rejected by
the server (which don't match the magic extension rules)

Use XPath to further restrict the instance, so a plain client can see it.



>
> /martin
>


Andy


>
>
> > The deadline for new features has long passed.
> >
> >
> > Andy
> >
> >
> > On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <
> > balazs.leng...@ericsson.com> wrote:
> >
> > > Hello,
> > > I agree we don't need to change the encoding, but we need to define how
> > > that encoding is visible/available when evaluating Xpath expressions.
> Today
> > > the draft says:
> > > - instance-identifier does not have a canonical format
> > > - XPath uses the canonical format
> > > The two together make it impossible to use it in Xpath, even though
> there
> > > are people that would like to do that.
> > > - Martin mentioned a proprietary extension
> > > - we would like it.
> > >
> > > So I would propose to
> > >  change to 9.1
> > >
> > > Old: In particular, any XPath expression evaluations are done using
> the canonical form.
> > >
> > > New:  In particular, whenever a canonical form exists, any XPath
> > > expression evaluations are done using the canonical form.
> > >
> > > --- add to 9.13.2
> > >
> > > For instance-identifiers XPath expression evaluations are done using
> the lexical form.
> > >
> > >
> > > regards Balazs
> > >
> > >
> > > On 2016-01-21 18:53, Andy Bierman wrote:
> > >
> > > Hi,
> > >
> > > There is no need to change the XML encoding or YANG encoding
> > > of an instance-identifier.  The prefixes are completely different
> > > in each.  Prefixes clashes do happen, especially since
> > > there is no expectation that they are unique.  They are short strings
> > > with no naming conventions at all.  E.g., I have seen "if" for
> > > interfaces in multiple modules.
> > >
> > > Andy
> > >
> > >
> > > On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <
> > > balazs.leng...@ericsson.com> wrote:
> > >
> > >> Hello Martin,
> > >> If the RFC would define that in XPath expressions an instance
> identifier
> > >> MUST be evaluated to a string that complies to the lexical format,
> using
> > >> the rematch function, we could do everything we need. In real life
> prefix
> > >> clashes are a rare problem.
> > >> regards Balazs
> > >>
> > >> On 2016-01-21 16:17, Martin Bjorklund wrote:
> > >>
> > >>> Balazs Lengyel  wrote:
> > >>>
> >  Hello,
> >  We have some instance identifiers in our model but we want to
> >  contrain what they can point at. What is the best method for that?
> > 
> > >>> Unfortunately, there is no standard way of doing this.  (There are
> > >>> vendor extensions available...)
> > >>>
> > >>> [...]
> > >>>
> > >>> Some issues:
> >  - instance-identifiers don't have a canonical format, so what is
> >  their value in an XPath expression?
> > 
> > >>> This is not defined.
> > >>>
> > >>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a
> way?
> > 
> > >>> In YANG 1.1, there is a function re-match() for this purpose.  For
> > >>> your use case, it *may* work to match just the local names of all
> > >>> nodes, i.e., using wildcards for the prefixes.  It is not a generic
> > >>> solution though.
> > >>>
> > >>> - if I have all the needed namespace prefixes in imports, can I just
> > use them?
> > 
> > >>> No, these prefixes are local to the module that is doing the import,
> > >>> and they may or may not match the prefixes used by the implementation
> > >>> when it construct the instance-identifier value.
> > >>>
> > >>>
> > >>>
> > >>> /martin
> > >>>
> > >>>
> > >> --
> > >> Balazs Lengyel   Ericsson Hungary Ltd.
> > >> Senior Specialist
> > >> ECN: 831 7320
> > >> Mobile: +36-70-330-7909  email: <
> balazs.leng...@ericsson.com>
> > >> balazs.leng...@ericsson.com
> > >>
> > >> ___
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >>
> > >
> > >
> > > --
> > > Balazs Lengyel   Ericsson Hungary Ltd.
> > > Senior Specialist
> > > ECN: 831 7320
> > > Mobile: +36-70-330-7909  email:
> balazs.leng...@ericsson.com
> > >
> > >
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Broadband Forum questions on RFC 6087bis

[Andy Bierman]

Hi,

I never liked submodules. IMO just more IETF over-engineering.
They have always confused customers into thinking they
are just modules within modules. Wrong.  They merely partition YANG
modules into multiple syntactic bundles.  There is only 1 module namespace.

Actually I think it doesn't matter if the submodule name changes, so I
should
remove the text in question.  One can remove all the submodules from
rev N to N+1 if they want, and add different names back (as you pointed
out).
If it doesn't change the module namespace contents it's OK.


Andy



On Fri, Jan 22, 2016 at 9:16 AM, William Lupton  wrote:

> It probably wouldn't (unless the tool implements an algorithm similar to
> the Git algorithm that detects "move" rather than "delete" + "add"). But
> given that you could delete it in one revision and then add it back with a
> different name in a subsequent revision should it really be forbidden? As I
> said... a minor point! W.
>
> On 22 Jan 2016, at 16:38, Andy Bierman  wrote:
>
> Hi,
>
> The changed submodule name looks like
> a new name and the old submodule was deleted.
> How does a tool determine it is some old submodule
> but the name was changed?
>
> Andy
>
>
>
>
> On Fri, Jan 22, 2016 at 6:33 AM, William Lupton <
> wlup...@broadband-forum.org> wrote:
>
>> Thanks for the responses. One clarification below on what is definitely a
>> minor point!
>>
>> On 22 Jan 2016, at 00:18, Andy Bierman  wrote:
>> On Wed, Jan 20, 2016 at 6:45 AM, William Lupton <
>> wlup...@broadband-forum.org> wrote:
>>>
>>> > 2. Rules re changing submodule names
>>> >
>>> > Section 5.7 (Lifecycle Management) says that "The [...] submodule name
>>> MUST NOT be changed, once the document containing the module or submodule
>>> is published" but this might contradict RFC 6020 Section 11, which says "A
>>> module may be split into a set of submodules, or a submodule may be
>>> removed...".
>>> >
>>> > More specifically, 6020 doesn't mention renaming a submodule (so
>>> presumably that's not permitted), but the mention of both splitting modules
>>> into submodules AND removing submodules suggests that arbitrary
>>> module/submodule refactoring is permitted. And if I'm being pedantic,
>>> revision #1 could have submodule A1, revision #2 could remove it, and
>>> revision #3 could reintroduce it as submodule A2, so that's effectively a
>>> rename!
>>>
>>
>> I do not see any issue here.
>> Moving an object does not change the submodule name.
>>
>>
>> My point was to question why renaming submodules is forbidden when in
>> fact it seems that submodule rename can be achieved via other means. It's
>> not that I actually want to do it, just that 6087 and 6020 don't seem quite
>> consistent on this topic.
>>
>> William
>>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group 
of the IETF.

Title   : Terminology and Requirements for Enhanced Handling of 
Operational State
Authors : Kent Watsen
  Thomas Nadeau
Filename: draft-ietf-netmod-opstate-reqs-04.txt
Pages   : 6
Date: 2016-01-22

Abstract:
   This document primarily regards the difference between the intended
   configuration and the applied configuration of a device and how
   intended and applied configuration relate to the operational state of
   a device.  This document defines requirements for the applied
   configuration's data model and its values, as well as for enabling a
   client to know when a configuration has been fully applied or not,
   how to access operational state, and how to relate intended
   configuration nodes to applied configuration and derived state nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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