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

2015-12-11 Thread 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


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

2015-12-11 Thread 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

2015-12-11 Thread 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

2015-12-11 Thread 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