Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-09.txt

[Ladislav Lhotka]

Sorry, I sent my message by mistake also to internet-drafts and i-d-announce 
mailing lists. Please remove them from your reply.

Lada
 
> On 12 Dec 2015, at 08:31, Ladislav Lhotka  wrote:
> 
> Hi,
> 
> I propose an additional change to the new text in sec. 7.17, paragraph 7:
> 
> OLD
> 
>If the augmentation adds mandatory nodes…
> 
> NEW
> 
>If the augmentation adds mandatory configuration nodes…
> 
> 
> Unknown nodes appearing in state data, RPC output or notification may 
> possibly break an old client, too, but that would happen even if the nodes 
> are not defined as mandatory. Therefore, I don't see any reason for applying 
> the restriction on non-config data.
> 
> Lada
> 
>> On 11 Dec 2015, at 22:51, internet-dra...@ietf.org wrote:
>> 
>> 
>> 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   : The YANG 1.1 Data Modeling Language
>>   Author  : Martin Bjorklund
>>  Filename: draft-ietf-netmod-rfc6020bis-09.txt
>>  Pages   : 201
>>  Date: 2015-12-11
>> 
>> Abstract:
>>  YANG is a data modeling language used to model configuration data,
>>  state data, remote procedure calls, and notifications for network
>>  management protocols like the Network Configuration Protocol
>>  (NETCONF).
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-09
>> 
>> 
>> 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
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] I-D Action: draft-ietf-netmod-rfc6020bis-09.txt

[Ladislav Lhotka]

Hi,

I propose an additional change to the new text in sec. 7.17, paragraph 7:

OLD

If the augmentation adds mandatory nodes…

NEW

If the augmentation adds mandatory configuration nodes…


Unknown nodes appearing in state data, RPC output or notification may possibly 
break an old client, too, but that would happen even if the nodes are not 
defined as mandatory. Therefore, I don't see any reason for applying the 
restriction on non-config data.

Lada

> On 11 Dec 2015, at 22:51, internet-dra...@ietf.org wrote:
> 
> 
> 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   : The YANG 1.1 Data Modeling Language
>Author  : Martin Bjorklund
>   Filename: draft-ietf-netmod-rfc6020bis-09.txt
>   Pages   : 201
>   Date: 2015-12-11
> 
> Abstract:
>   YANG is a data modeling language used to model configuration data,
>   state data, remote procedure calls, and notifications for network
>   management protocols like the Network Configuration Protocol
>   (NETCONF).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-09
> 
> 
> 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

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




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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-09.txt

[Martin Bjorklund]

Hi,

This version addresses all issues reported on -08 during (and after)
the WGLC period.  We didn't reach full agreement on all these issues,
but I believe the document reflects WG consensus.


/martin


internet-dra...@ietf.org wrote:
> 
> 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   : The YANG 1.1 Data Modeling Language
> Author  : Martin Bjorklund
>   Filename: draft-ietf-netmod-rfc6020bis-09.txt
>   Pages   : 201
>   Date: 2015-12-11
> 
> Abstract:
>YANG is a data modeling language used to model configuration data,
>state data, remote procedure calls, and notifications for network
>management protocols like the Network Configuration Protocol
>(NETCONF).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-09
> 
> 
> 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
> 

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

[netmod] I-D Action: draft-ietf-netmod-rfc6020bis-09.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   : The YANG 1.1 Data Modeling Language
Author  : Martin Bjorklund
Filename: draft-ietf-netmod-rfc6020bis-09.txt
Pages   : 201
Date: 2015-12-11

Abstract:
   YANG is a data modeling language used to model configuration data,
   state data, remote procedure calls, and notifications for network
   management protocols like the Network Configuration Protocol
   (NETCONF).


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

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

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


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

Re: [netmod] Broadband Forum intention of using ietf-entity YANG module

[Nadeau Thomas]

Dependance on 1.1 should not be an issue as that is almost ready to be 
approved. You should be building your model to comply with the 1.1 rules.

—Tom


> On Dec 11, 2015:8:00 AM, at 8:00 AM, William Lupton 
>  wrote:
> 
> All,
> 
> The Broadband Forum would like to use the ietf-entity YANG module (currently 
> draft-entitydt-netmod-entity) for equipment management but we are a bit 
> concerned about its draft status and its dependence on YANG 1.1. Any advice 
> or reassurance?
> 
> Thanks,
> William
> ___
> 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] How to model a leafref in union conforming to RFC6020?

[Jernej Tuljak]

GUBALLA, JENS (JENS) je 11.12.2015 ob 14:40 napisal:

Hi Lada,


-Original Message-
From: Ladislav Lhotka [mailto:lho...@nic.cz]
Sent: Freitag, 11. Dezember 2015 11:51
To: GUBALLA, JENS (JENS)
Cc: netmod@ietf.org
Subject: Re: [netmod] How to model a leafref in union conforming to
RFC6020?



On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS) 
lucent.com> wrote:

Hi,

According to RFC6020 a leafref within a union is not allowed. This
issue is captured by Y30 of the yang1.1 issue list.

My question: how can such a construct as show below be modeled
conforming to RFC6020?

leaf the_reference {type uint8;}
leaf something {
type union {
type leafref {
path "../the_reference";
}
type enumeration {
enum "none";
enum "something-else";
}
}
}

Has anyone any ideas or can someone provide me a pointer if this has
been discussed already?

You can define the first union member simply as uint8, without being
formally coupled with "the_reference". I'd suggest to use YANG 1.1
though where that CLR was removed.

[JG] Thanks a lot for your suggestions. Replacing "type leafref" by "type
unit8" would mean to lose the semantic of the leafref type. Thus

 5
 4

would unfortunately be regarded as compliant to the model.

On the other hand the data model should be Yang1.0 compliant. So I want to
check if there is any other solution to the issue.


Add a (very specific) must constraint to the "something" leaf? Something 
along the lines of:


leaf the_reference {type uint8;}
  leaf something {
must "(not(number()) and not(. = 0)) or . = /the_reference";
type union {
  type uint8;
  type enumeration {
enum "none";
enum "something-else";
  }
}
  }

for this particular example. Ugly, yes, but (probably) works. The above 
requires "not a number or same as 'the_reference'".


Jernej



Best regards,
Jens


Lada


Thanks,
Jens

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






___
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] How to model a leafref in union conforming to RFC6020?

[Martin Bjorklund]

"GUBALLA, JENS (JENS)"  wrote:
> Hi Lada,
> 
> > -Original Message-
> > From: Ladislav Lhotka [mailto:lho...@nic.cz]
> > Sent: Freitag, 11. Dezember 2015 11:51
> > To: GUBALLA, JENS (JENS)
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] How to model a leafref in union conforming to
> > RFC6020?
> > 
> > 
> > > On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS)  > lucent.com> wrote:
> > >
> > > Hi,
> > >
> > > According to RFC6020 a leafref within a union is not allowed. This
> > > issue is captured by Y30 of the yang1.1 issue list.
> > >
> > > My question: how can such a construct as show below be modeled
> > > conforming to RFC6020?
> > >
> > >leaf the_reference {type uint8;}
> > >leaf something {
> > >type union {
> > >type leafref {
> > >path "../the_reference";
> > >}
> > >type enumeration {
> > >enum "none";
> > >enum "something-else";
> > >}
> > >}
> > >}
> > >
> > > Has anyone any ideas or can someone provide me a pointer if this has
> > > been discussed already?
> > 
> > You can define the first union member simply as uint8, without being
> > formally coupled with "the_reference". I'd suggest to use YANG 1.1
> > though where that CLR was removed.
> [JG] Thanks a lot for your suggestions. Replacing "type leafref" by "type
> unit8" would mean to lose the semantic of the leafref type. Thus
> 
> 5
> 4
> 
> would unfortunately be regarded as compliant to the model.
> 
> On the other hand the data model should be Yang1.0 compliant. So I want to
> check if there is any other solution to the issue.

Another common way to handle this is to do a choice of two leafs:

   choice s {
 leaf something-as-leafreaf { type leafreaf ... }
 leaf something-as-enum { ... }
   }


/martin

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

Re: [netmod] How to model a leafref in union conforming to RFC6020?

[GUBALLA, JENS (JENS)]

Hi Lada,

> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Freitag, 11. Dezember 2015 11:51
> To: GUBALLA, JENS (JENS)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] How to model a leafref in union conforming to
> RFC6020?
> 
> 
> > On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS)  lucent.com> wrote:
> >
> > Hi,
> >
> > According to RFC6020 a leafref within a union is not allowed. This
> > issue is captured by Y30 of the yang1.1 issue list.
> >
> > My question: how can such a construct as show below be modeled
> > conforming to RFC6020?
> >
> >leaf the_reference {type uint8;}
> >leaf something {
> >type union {
> >type leafref {
> >path "../the_reference";
> >}
> >type enumeration {
> >enum "none";
> >enum "something-else";
> >}
> >}
> >}
> >
> > Has anyone any ideas or can someone provide me a pointer if this has
> > been discussed already?
> 
> You can define the first union member simply as uint8, without being
> formally coupled with "the_reference". I'd suggest to use YANG 1.1
> though where that CLR was removed.
[JG] Thanks a lot for your suggestions. Replacing "type leafref" by "type
unit8" would mean to lose the semantic of the leafref type. Thus

5
4

would unfortunately be regarded as compliant to the model.

On the other hand the data model should be Yang1.0 compliant. So I want to
check if there is any other solution to the issue.

Best regards,
Jens

> 
> Lada
> 
> >
> > Thanks,
> > Jens
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Broadband Forum intention of using ietf-entity YANG module

[William Lupton]

All,

The Broadband Forum would like to use the ietf-entity YANG module (currently 
draft-entitydt-netmod-entity) for equipment management but we are a bit 
concerned about its draft status and its dependence on YANG 1.1. Any advice or 
reassurance?

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

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

[Martin Bjorklund]

William Lupton  wrote:
> Thanks for the clarifications. A few follow-ups below. Cheers, W.
> 
> >> a. Extending a "when" statement so it is true for a wider set of
> >> conditions (example: realising that an RFC 7223 interface object
> >> applies to additional interface types).
> > 
> > This is allowed by:
> > 
> >  o  A "when" statement may be removed or its constraint relaxed.
> 
> OK. I see this for "must" but not for "when"; in 08 I can find only
> one instance of "relax".

Aha, I was looking at the upcomign -09 - this was already pointed out
by Andy and fixed.  Sorry for the confusion.

> >> c. Converting a leaf node to a choice (with no change to default
> >> behaviour).
> > 
> > This is not allowed, but maybe it should.  I.e., it should be ok to
> > wrap a node that is not a mandatory node (see terminology) in a choice
> > (+ case).
> 
> OK. Maybe this already happened but perhaps it would be worth checking
> whether there are any other cases that could/should be included (given
> that the list is exhaustive)?

Yes, this is why we need reviewers, so thanks for spotting this!

> > A container cannot be mandatory.
> 
> OK! I should have phrased it more loosely. But you answered the basic
> question, which was whether listing the submodules is REQUIRED. Yes it
> is.


/martin
 

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

[netmod] Broadband Forum questions on RFC 6087bis

[William Lupton]

All,

Here are some questions / comments from the Broadband Forum on RFC 6087bis-05.

Thanks,
William



1. Potentially confusing use of the term "prefix"

Section 5.1 (Module Naming Conventions) talks about prefixes but in this 
context means "strings at the beginning of module names" rather than YANG 
prefixes that are the topic of Section 5.2. This could (and did!) cause 
confusion.


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!


3. References to RPCs need also to mention actions

In most (or all?) places that RPCs are mentioned, presumably actions need to be 
mentioned?


4. Implications of adding defaults

Section 5.12 (Reusable Type Definitions) says that "If an appropriate default 
value can be associated with the desired semantics, then a default statement 
SHOULD be present". Is it correct that adding a default effectively adds a 
MANDATORY requirement for a server to support the default value for that node, 
and therefore to support the concept modelled by the node (albeit only with the 
default behaviour)? Whereas if there were no default then there would be no 
requirement at all to support the concept modelled by that node? If so, then 
adding a default seems like something that shouldn't be done lightly... or am I 
making too much of this?


5. Guidance re YANG features

6087 doesn't always refer to features consistently. For example Section 5.5 
(Conditional Statements) says "If a data definition is optional, depending on 
server support for a NETCONF protocol capability, then a YANG 'feature' 
statement SHOULD be defined" (which seems to tie the "feature" concept to 
NETCONF protocol capabilities), whereas Section 5.17 (Feature Definitions) says 
"The YANG "feature" statement is used to define a label for a set of optional 
functionality within a module". The latter description seems more in keeping 
with the spirit of 6020, so perhaps the former text could be adjusted to align 
with it?


6. Guidance re YANG deviations

The 6020 discussion of deviations is mostly about implementing LESS rather than 
MORE. Obviously the deviate statement's "add" argument is described (and there 
is an example) but there seems to be no discussion that use of deviate with 
"add" might be a GOOD thing.

The 6087 discussion of deviations says that they can be useful for documenting 
server capabilities but again the emphasis seems to be on documenting 
implementing LESS rather than MORE.

The result seems to be that deviations have a bad name. If indeed there are 
accepted good uses of deviations then it would be good if this was made 
clearer, both in 6020 and in 6087.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[William Lupton]

Thanks for the clarifications. A few follow-ups below. Cheers, W.

>> a. Extending a "when" statement so it is true for a wider set of
>> conditions (example: realising that an RFC 7223 interface object
>> applies to additional interface types).
> 
> This is allowed by:
> 
>  o  A "when" statement may be removed or its constraint relaxed.

OK. I see this for "must" but not for "when"; in 08 I can find only one 
instance of "relax".

>> c. Converting a leaf node to a choice (with no change to default
>> behaviour).
> 
> This is not allowed, but maybe it should.  I.e., it should be ok to
> wrap a node that is not a mandatory node (see terminology) in a choice
> (+ case).

OK. Maybe this already happened but perhaps it would be worth checking whether 
there are any other cases that could/should be included (given that the list is 
exhaustive)?

> A container cannot be mandatory.

OK! I should have phrased it more loosely. But you answered the basic question, 
which was whether listing the submodules is REQUIRED. Yes it is.

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

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

[Martin Bjorklund]

Hi,

William Lupton  wrote:
> All,
> 
> Here are a couple of questions from the Broadband Forum on RFC
> 6020bis-08 and draft-ietf-netconf-yang-library-02.
> 
> Thanks,
> William
> 
> 
> 
> 1. RFC 6020bis and updating modules
> 
> 6020bis Section 11 (Updating a Module) lists all the ways in which a
> definition can be revised, but it's not clear whether this is intended
> to be an exhaustive list or just to illustrate the principle of
> allowing the value space to be broadened. If the latter then
> presumably other changes that adhere to this principle would also be
> valid.

The former.

> For example, it seems that the following might also be permitted:
> 
> a. Extending a "when" statement so it is true for a wider set of
> conditions (example: realising that an RFC 7223 interface object
> applies to additional interface types).

This is allowed by:

  o  A "when" statement may be removed or its constraint relaxed.

> b. Re-writing a "when" statement to use a base identity rather than an
> explicit list of identities (with no change to the conditions for
> which it is true).

Same as above.

> c. Converting a leaf node to a choice (with no change to default
> behaviour).

This is not allowed, but maybe it should.  I.e., it should be ok to
wrap a node that is not a mandatory node (see terminology) in a choice
(+ case).

> 2. ietf-yang-library and reporting submodules
> 
> As we understand them, submodules have no impact on a module's
> external interface, and (6020 Section 11) "A module may be split into
> a set of submodules, or a submodule may be removed, provided the
> definitions in the module do not change in any other way than allowed
> here".
> 
> draft-ietf-netconf-yang-library-02 says (Section 1) "submodule list:
> The name and revision of each submodule used by the module MUST be
> identified" but the YANG module's "submodules" container appears not
> to be mandatory.

A container cannot be mandatory.

> Is it intended that the submodules MUST be listed? 

Yes, that's what the text "The name and revision of each submodule
used by the module MUST be identified" says.

> If so, what is the rationale for requiring this?

The module may have used include w/o revision.  Unless the submodule
is listed by the server, the client won't know which revision the
server uses.


/martin

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

[netmod] Broadband Forum questions on RFC 6020bis

[William Lupton]

All,

Here are a couple of questions from the Broadband Forum on RFC 6020bis-08 and 
draft-ietf-netconf-yang-library-02.

Thanks,
William



1. RFC 6020bis and updating modules

6020bis Section 11 (Updating a Module) lists all the ways in which a definition 
can be revised, but it's not clear whether this is intended to be an exhaustive 
list or just to illustrate the principle of allowing the value space to be 
broadened. If the latter then presumably other changes that adhere to this 
principle would also be valid.

For example, it seems that the following might also be permitted:

a. Extending a "when" statement so it is true for a wider set of conditions 
(example: realising that an RFC 7223 interface object applies to additional 
interface types).

b. Re-writing a "when" statement to use a base identity rather than an explicit 
list of identities (with no change to the conditions for which it is true).

c. Converting a leaf node to a choice (with no change to default behaviour).


2. ietf-yang-library and reporting submodules

As we understand them, submodules have no impact on a module's external 
interface, and (6020 Section 11) "A module may be split into a set of 
submodules, or a submodule may be removed, provided the definitions in the 
module do not change in any other way than allowed here".

draft-ietf-netconf-yang-library-02 says (Section 1) "submodule list: The name 
and revision of each submodule used by the module MUST be identified" but the 
YANG module's "submodules" container appears not to be mandatory.

Is it intended that the submodules MUST be listed? If so, what is the rationale 
for requiring this?
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
> 
>   This email initiates a NETMOD WG Last call for 
> draft-ietf-netmod-acl-model-06. 
> Please review the draft and make any comments to the list by Wednesday, 16 
> December, 2015
> by 8AM EST.
>

Technical

- I am not sure I personally like the acl-oper-data and ace-oper-data
  containers in the middle of the config true tree. I understand that
  operational state in this case is likely tightly bound to the
  lifetime of the config state but I also generally prefer to have a
  clean separation of config from state. But since I am not
  implementing this, I am happy to leave the decision to those who
  write the code.

- I would probably have used src-ipv4-prefix and dst-ipv4-prefix
  instead of source-ipv4-network and destination-ipv4-network and
  I would probably have used src-mac-address and src-mac-address-mask
  and dst-mac-address and dst-mac-address-mask. Generally simple
  src instead source and dst instead destination - lines up all
  much more nicely.

- I would have put the acl-name and acl-type first followed by the
  entries list.

- I also wonder why we use both the term 'entry' and 'rule', why not
  pick one of them? You have for example rule-name (which is the key
  of the list but again comes last).

- Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
  we expect that all implementations will always support all three?
  Another option would be to have the generic model completely without
  any protocol specific elements and to have separate models to
  augment in ipv4, ipv6, and ethernet specific ace types. I actually
  think this would make much more sense since you would not have a
  module 'packet fields' but instead a clear extension of the
  ietf-access-control-list module. You could also drop the examples
  how to extend the core model since the ip and ethernet extensions
  would already serve the purpose. You also would not need features
  since an implementation advertises the extension modules.

- The 'uses packet-fields:metadata' resolves to a leaf
  'input-interface' which is of type string. Is this the only metadata
  field we ever envision to be there? If so, why not make it part of
  the base model? If not, what is the extensibility model here?  And
  should the interface reference not use a more specific type than
  'string'?

- Some implementations support the action to jump or goto other
  acls. Is this not common enough to include it as a base action,
  perhaps protected by a feature?

- In the example in section 4.3, does the CLI shown really help much?
  The syntax is pretty system specific. In the XML shown, can you not
  leave out all the fields that are not set? This would remove a lot
  of noise. I do not understand what having both actions deny and
  permit at the same time means. Did you validate the example against
  the data model? (I also find the keys at the end somewhat strange
  and not that NETCONF XML serialization actually requires the keys to
  be sent first.)

- The clarification whether the boundary port numbers are included in
  a port range should be in the YANG model. The YANG model should also
  say what it means if one of the ranges is not present. We should not
  define the semantics by examples.

- I do not understand section 5. It shows some nftables syntax but
  does not really shed a light on what the example shown does or how
  that maps to the YANG data model. So I am left somewhat clueless.

- Can I trigger multiple actions from an ace? Or do I have to
  replicate the ace to do that? In general, there is extension of
  a choice (means one of several) and there are extension of a
  choice already present.

- Empty description statements or descriptions statements "(null)"
  need to be fixed.

- I am a bit surprised that we do not define how to attach an ACL to
  an interfaces or a set of interfaces given that we do have an
  interfaces YANG data model. The example given in A.3 makes me wonder
  why there should be a counter in the interfaces config tree. The
  targets/interface-name back-reference seems to indicate that I can
  attach an ACL only to a single interface.

- I do not understand A.4 at all. Defining an identity does not make
  the choice work differently.

- Has someone tried to implement this?

Organization

- Section 3 to a large extend is a repetition of section 1. Perhaps
  make section 1 shorter and leave the details to section 3?

- Some empty lines in the YANG definition would have pleased my eyes.

Editorial

- there are a couple of missing articles throughout the text
- sometimes singular/plural is at odds
- s/this draft/this document/
- you may add another 'e' to my name ;-)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

_

Re: [netmod] derived-from() and derived-from-or-self() arguments

[William Lupton]

Thanks all.

> On 11 Dec 2015, at 09:50, Jernej Tuljak  wrote:
> 
> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
>> 
>> A code that evaluating these functions needs to know a lot about the 
>> underlying YANG data model anyway, so I think it is no problem to resolve 
>> arbitrary QNames. I am thus in favour of William's proposal.

I like the idea of just thinking of it as a QName. This also suggests a general 
principle that any future functions that needed to refer to types, identities 
etc would use QNames?

> If there are no existing functions that take a prefixed string literal, why 
> not simply replace the module name argument with a prefix string? I don't see 
> why a module name needs to be used here at all either - in fact, it seems to 
> be promoting the idea of breaking out of module containment using XPath 
> instead of discouraging it - you should not be able to refer to an identity 
> if it is not defined within an imported or the enclosing module.

I assume that "module name" always meant "prefix" because otherwise how would 
one deal with namespaces and revisions? Using a QName clarifies that it's a 
prefix.

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

Re: [netmod] derived-from() and derived-from-or-self() arguments

[Ladislav Lhotka]

> On 11 Dec 2015, at 12:22, Martin Bjorklund  wrote:
> 
> Jernej Tuljak  wrote:
>> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
 On 11 Dec 2015, at 09:23, Martin Bjorklund  wrote:
 
 William Lupton  wrote:
> Martin,
> 
> Thanks for the reply and sorry for my delay in following up. Maybe I'm
> misunderstanding your point, but surely any node-set argument can be a
> prefixed string, e.g I found this example in a NETMOD "Y26 again,
> sorry" thread.
> 
>  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
>when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>   + "'TLSA')";
 But in this example there is no prefixed *string value* - the prefix
 is used in a LocationPath, not a string.
>>> Right, an identity isn't a node-set.
>>> 
> Arguably YANG authors might find it more natural always to use
> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to
> a namespace-qualified entity?
 Maybe, yes.  It would be useful to hear others opinions!
>>> A code that evaluating these functions needs to know a lot about the
>>> underlying YANG data model anyway, so I think it is no problem to
>>> resolve arbitrary QNames. I am thus in favour of William's proposal.
>> 
>> If there are no existing functions that take a prefixed string
>> literal, why not simply replace the module name argument with a prefix
>> string? I don't see why a module name needs to be used here at all
>> either - in fact, it seems to be promoting the idea of breaking out of
>> module containment using XPath instead of discouraging it - you should
>> not be able to refer to an identity if it is not defined within an
>> imported or the enclosing module.
> 
> If we're going to use the prefix, I prefer to use a single QName.  I
> agree with your comment as well.  So unless anyone objects, I will
> make this change.

+1

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] derived-from() and derived-from-or-self() arguments

[Martin Bjorklund]

Jernej Tuljak  wrote:
> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
> >> On 11 Dec 2015, at 09:23, Martin Bjorklund  wrote:
> >>
> >> William Lupton  wrote:
> >>> Martin,
> >>>
> >>> Thanks for the reply and sorry for my delay in following up. Maybe I'm
> >>> misunderstanding your point, but surely any node-set argument can be a
> >>> prefixed string, e.g I found this example in a NETMOD "Y26 again,
> >>> sorry" thread.
> >>>
> >>>   augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
> >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
> >>>+ "'TLSA')";
> >> But in this example there is no prefixed *string value* - the prefix
> >> is used in a LocationPath, not a string.
> > Right, an identity isn't a node-set.
> >
> >>> Arguably YANG authors might find it more natural always to use
> >>> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to
> >>> a namespace-qualified entity?
> >> Maybe, yes.  It would be useful to hear others opinions!
> > A code that evaluating these functions needs to know a lot about the
> > underlying YANG data model anyway, so I think it is no problem to
> > resolve arbitrary QNames. I am thus in favour of William's proposal.
> 
> If there are no existing functions that take a prefixed string
> literal, why not simply replace the module name argument with a prefix
> string? I don't see why a module name needs to be used here at all
> either - in fact, it seems to be promoting the idea of breaking out of
> module containment using XPath instead of discouraging it - you should
> not be able to refer to an identity if it is not defined within an
> imported or the enclosing module.

If we're going to use the prefix, I prefer to use a single QName.  I
agree with your comment as well.  So unless anyone objects, I will
make this change.


/martin

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

Re: [netmod] How to model a leafref in union conforming to RFC6020?

[Ladislav Lhotka]

> On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS) 
>  wrote:
> 
> Hi,
> 
> According to RFC6020 a leafref within a union is not allowed. This issue is
> captured by Y30 of the yang1.1 issue list.
> 
> My question: how can such a construct as show below be modeled conforming to
> RFC6020?
> 
>leaf the_reference {type uint8;}
>leaf something {
>type union {
>type leafref {
>path "../the_reference";
>}
>type enumeration {
>enum "none";
>enum "something-else";
>}
>}
>}
> 
> Has anyone any ideas or can someone provide me a pointer if this has been
> discussed already?

You can define the first union member simply as uint8, without being formally 
coupled with "the_reference". I'd suggest to use YANG 1.1 though where that CLR 
was removed.

Lada

> 
> Thanks,
> Jens
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] How to model a leafref in union conforming to RFC6020?

[GUBALLA, JENS (JENS)]

Hi,

According to RFC6020 a leafref within a union is not allowed. This issue is
captured by Y30 of the yang1.1 issue list.

My question: how can such a construct as show below be modeled conforming to
RFC6020?

leaf the_reference {type uint8;}
leaf something {
type union {
type leafref {
path "../the_reference";
}
type enumeration {
enum "none";
enum "something-else";
}
}
}

Has anyone any ideas or can someone provide me a pointer if this has been
discussed already?

Thanks,
Jens


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] effect of include in a submodule

[Ladislav Lhotka]

Hi Michal,

submodule stuff was considerably simplified in draft-ietf-netmod-rfc6020bis, I 
think it would be better to use the new logic everywhere. Essentially, in YANG 
1.1 includes are only effective in the main module, and the result is the same 
as if the submodule definition were placed in the main module, so they can be 
used in the main module and all submodules without further includes.

Lada

> On 11 Dec 2015, at 10:22, Michal Vaško  wrote:
> 
> Hi,
> I want to make sure I understand the effect of including a submodule in 
> another submodule (of the same belongs-to parent, naturally).
> 
> RFC 6020 sec. 7.1.6 says:
> 
> "When a module includes a submodule, it incorporates the contents of
> the submodule into the node hierarchy of the module.  When a
> submodule includes another submodule, the target submodule's
> definitions are made available to the current submodule."
> 
>> From the first sentence I understand that include in a module has the effect 
>> of both the definitions (typedefs, indentities, ..., as defined in the 
>> bullets in the sec. 7.1.5) and the data (containers, lists, and the rest) 
>> being part of the module. This means one can refer in the module to both the 
>> definitions and the data from the submodule without using any prefix or the 
>> prefix of the module. From the second sentence I gather that including a 
>> submodule2 in submodule1 makes only the definitions from submodule2 
>> available in submodule1 and they can be referred to without any prefix or 
>> the belongs-to prefix from submodule1. My understanding of the second 
>> sentence is supported by the first sentence of the sec. 7.1.5:
> 
> "The "import" statement makes definitions from one module available
> inside another module or submodule."
> 
> With import you make only the definitions available and the import prefix 
> must be specified to use them.
> 
> My actual question then is, does the effect of include in a submodule differ 
> from the effect of include in a module? Is it actually an import (but you 
> cannot import a submodule) in the former, while a C-style #include in the 
> latter? Thank you.
> 
> Regards,
> Michal Vasko
> 
> ___
> 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] derived-from() and derived-from-or-self() arguments

[Jernej Tuljak]

Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:

On 11 Dec 2015, at 09:23, Martin Bjorklund  wrote:

William Lupton  wrote:

Martin,

Thanks for the reply and sorry for my delay in following up. Maybe I'm
misunderstanding your point, but surely any node-set argument can be a
prefixed string, e.g I found this example in a NETMOD "Y26 again,
sorry" thread.

  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
   + "'TLSA')";

But in this example there is no prefixed *string value* - the prefix
is used in a LocationPath, not a string.

Right, an identity isn't a node-set.


Arguably YANG authors might find it more natural always to use
prefixed strings such as 'iana-dns-parameters:TLSA' when referring to
a namespace-qualified entity?

Maybe, yes.  It would be useful to hear others opinions!

A code that evaluating these functions needs to know a lot about the underlying 
YANG data model anyway, so I think it is no problem to resolve arbitrary 
QNames. I am thus in favour of William's proposal.


If there are no existing functions that take a prefixed string literal, 
why not simply replace the module name argument with a prefix string? I 
don't see why a module name needs to be used here at all either - in 
fact, it seems to be promoting the idea of breaking out of module 
containment using XPath instead of discouraging it - you should not be 
able to refer to an identity if it is not defined within an imported or 
the enclosing module.


Jernej



Lada



/martin



William

PS, The current definitions perhaps need to be tightened up wrt
module-name (MUST be valid prefix) and identity-name (MUST NOT be
qualified)?


On 16 Nov 2015, at 19:51, Martin Bjorklund  wrote:

Hi,

William Lupton  wrote:

Hi,

I'm sure there's an obvious reason for this, but could someone explain
why
these functions need a separate module-name argument rather than just
using
that module's prefix on the identity-name argument?

The only reason is that there are no existing functions that take a
prefixed string as an argument.  I think it would be possible to
change these functions to take just two arguments, but I am not sure
it is worth it?

/martin


For example, I saw derived-from(x, "ex-module", "foo") in a recent
message
but (assuming that "ex" is the prefix for "ex-module") will this
always be
the same as derived-from(x, "ex:foo")?

Thanks,
William

___
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



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

[netmod] effect of include in a submodule

[Michal Vaško]

Hi,
I want to make sure I understand the effect of including a submodule in another 
submodule (of the same belongs-to parent, naturally).

RFC 6020 sec. 7.1.6 says:

"When a module includes a submodule, it incorporates the contents of
the submodule into the node hierarchy of the module.  When a
submodule includes another submodule, the target submodule's
definitions are made available to the current submodule."

>From the first sentence I understand that include in a module has the effect 
>of both the definitions (typedefs, indentities, ..., as defined in the bullets 
>in the sec. 7.1.5) and the data (containers, lists, and the rest) being part 
>of the module. This means one can refer in the module to both the definitions 
>and the data from the submodule without using any prefix or the prefix of the 
>module. From the second sentence I gather that including a submodule2 in 
>submodule1 makes only the definitions from submodule2 available in submodule1 
>and they can be referred to without any prefix or the belongs-to prefix from 
>submodule1. My understanding of the second sentence is supported by the first 
>sentence of the sec. 7.1.5:

"The "import" statement makes definitions from one module available
inside another module or submodule."

With import you make only the definitions available and the import prefix must 
be specified to use them.

My actual question then is, does the effect of include in a submodule differ 
from the effect of include in a module? Is it actually an import (but you 
cannot import a submodule) in the former, while a C-style #include in the 
latter? Thank you.

Regards,
Michal Vasko

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

Re: [netmod] derived-from() and derived-from-or-self() arguments

[Ladislav Lhotka]

> On 11 Dec 2015, at 09:23, Martin Bjorklund  wrote:
> 
> William Lupton  wrote:
>> Martin,
>> 
>> Thanks for the reply and sorry for my delay in following up. Maybe I'm
>> misunderstanding your point, but surely any node-set argument can be a
>> prefixed string, e.g I found this example in a NETMOD "Y26 again,
>> sorry" thread.
>> 
>>  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
>>when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>>   + "'TLSA')";
> 
> But in this example there is no prefixed *string value* - the prefix
> is used in a LocationPath, not a string.

Right, an identity isn't a node-set.

> 
>> Arguably YANG authors might find it more natural always to use
>> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to
>> a namespace-qualified entity?
> 
> Maybe, yes.  It would be useful to hear others opinions!

A code that evaluating these functions needs to know a lot about the underlying 
YANG data model anyway, so I think it is no problem to resolve arbitrary 
QNames. I am thus in favour of William's proposal.

Lada

> 
> 
> /martin
> 
> 
>> William
>> 
>> PS, The current definitions perhaps need to be tightened up wrt
>> module-name (MUST be valid prefix) and identity-name (MUST NOT be
>> qualified)?
>> 
>>> On 16 Nov 2015, at 19:51, Martin Bjorklund  wrote:
>>> 
>>> Hi,
>>> 
>>> William Lupton  wrote:
 Hi,
 
 I'm sure there's an obvious reason for this, but could someone explain
 why
 these functions need a separate module-name argument rather than just
 using
 that module's prefix on the identity-name argument?
>>> 
>>> The only reason is that there are no existing functions that take a
>>> prefixed string as an argument.  I think it would be possible to
>>> change these functions to take just two arguments, but I am not sure
>>> it is worth it?
>>> 
>>> /martin
>>> 
 For example, I saw derived-from(x, "ex-module", "foo") in a recent
 message
 but (assuming that "ex" is the prefix for "ex-module") will this
 always be
 the same as derived-from(x, "ex:foo")?
 
 Thanks,
 William
>> 
> 
> ___
> 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] derived-from() and derived-from-or-self() arguments

[Martin Bjorklund]

William Lupton  wrote:
> Martin,
> 
> Thanks for the reply and sorry for my delay in following up. Maybe I'm
> misunderstanding your point, but surely any node-set argument can be a
> prefixed string, e.g I found this example in a NETMOD "Y26 again,
> sorry" thread.
> 
>   augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
>+ "'TLSA')";

But in this example there is no prefixed *string value* - the prefix
is used in a LocationPath, not a string.

> Arguably YANG authors might find it more natural always to use
> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to
> a namespace-qualified entity?

Maybe, yes.  It would be useful to hear others opinions!


/martin


> William
> 
> PS, The current definitions perhaps need to be tightened up wrt
> module-name (MUST be valid prefix) and identity-name (MUST NOT be
> qualified)?
> 
> > On 16 Nov 2015, at 19:51, Martin Bjorklund  wrote:
> > 
> > Hi,
> > 
> > William Lupton  wrote:
> >> Hi,
> >> 
> >> I'm sure there's an obvious reason for this, but could someone explain
> >> why
> >> these functions need a separate module-name argument rather than just
> >> using
> >> that module's prefix on the identity-name argument?
> > 
> > The only reason is that there are no existing functions that take a
> > prefixed string as an argument.  I think it would be possible to
> > change these functions to take just two arguments, but I am not sure
> > it is worth it?
> > 
> > /martin
> > 
> >> For example, I saw derived-from(x, "ex-module", "foo") in a recent
> >> message
> >> but (assuming that "ex" is the prefix for "ex-module") will this
> >> always be
> >> the same as derived-from(x, "ex:foo")?
> >> 
> >> Thanks,
> >> William
> 

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