date:20170324

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

2017-03-24 Thread Robert Wilton

On 24/03/2017 17:07, Andy Bierman wrote:

On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund > wrote:

Robert Wilton > wrote:
>
>
> On 24/03/2017 08:09, Benoit Claise wrote:
> > On 3/24/2017 2:32 AM, Kent Watsen wrote:
> >> Hi Benoit,
> >>
> >> Section 4.2 of rfc6187bis says:
> >>
> >> The "" tag SHOULD be followed by a string
> >> identifying the file name specified in Section 5.2 of
> >> [RFC7950].
> >>
> >> While Section 5.2 of RFC7950 says:
> >>
> >> The name of the file SHOULD be of the form:
> >>
> >>   module-or-submodule-name ['@' revision-date] ( '.yang'
/ '.yin' )
> >>
> >> "module-or-submodule-name" is the name of the module or
> >> submodule, and the optional "revision-date" is the latest
> >> revision of the module or submodule, as defined by the
> >> "revision" statement (Section 7.1.9).
> >>
> >> While the SHOULD statements provide a recommendation, the
> >> square-brackets "[]" impart no bias, and the text is ambiguous.
> >> That is, is the revision-date optional *only* because the
> >> revision statement is optional within the module?  What is
> >> the recommendation for when the revision statement is present?
> >> The RFC7950 text isn't clear.
> >>
> >> My opinion is that RFC7950 errata should state that the file
> >> name SHOULD include the revision-date when the revision
> >> statement appears within the module.
> > That makes sense.
> > Any other views?
>
> I don't feel strongly, but would it make more sense if instead
> rfc6187bis stated that the file name SHOULD include the revision
date?
> I.e. 7950 states what the filename is allowed to look like and
6187bis
> states what they should look like for IETF produced models.

+1

This is fine, but this there is a larger goal of library consistency 
that is

impacted by this guideline. (such as the github/YangModels/yang repo.

1) changing the filename for each revision is not git-friendly
(if one wants to track changes over releases)
Perhaps this is a difference between a development version (maybe being 
worked on in a separate directory in git) vs a published version, and by 
published I mean any draft revision.

2) many revisions are actually obsolete work-in-progress
so keeping every old file around will grow into a problem
For the YANG models in RFCs, I guess that they are effectively published 
forever in github.
But for drafts, I think that they can could be removed from github at 
the point that there is no other current draft that references them, 
which should be scriptable.

3) almost every import is import-without-revision so compiling the
old obsolete modules quickly breaks as the new work-in-progress version
makes incompatible changes.

Yes.

Perhaps YANG is missing an "import with revision X or greater" (given 
that revisions are expected to be backwards compatible)?

However, import-by-revision breaks if you only keep the latest 
revision around,

so these problems have to be managed by the YANG librarians ;-)

I agree.

/martin

Andy

___
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] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

2017-03-24 Thread t . petch

- Original Message -
From: "Martin Bjorklund" 
To: 
Cc: ; 
Sent: Friday, March 24, 2017 1:44 PM


> Robert Wilton  wrote:
> >
> >
> > On 24/03/2017 08:09, Benoit Claise wrote:
> > > On 3/24/2017 2:32 AM, Kent Watsen wrote:
> > >> Hi Benoit,
> > >>
> > >> Section 4.2 of rfc6187bis says:
> > >>
> > >> The "" tag SHOULD be followed by a string
> > >> identifying the file name specified in Section 5.2 of
> > >> [RFC7950].
> > >>
> > >> While Section 5.2 of RFC7950 says:
> > >>
> > >> The name of the file SHOULD be of the form:
> > >>
> > >>   module-or-submodule-name ['@' revision-date] ( '.yang' /
'.yin' )
> > >>
> > >> "module-or-submodule-name" is the name of the module or
> > >> submodule, and the optional "revision-date" is the latest
> > >> revision of the module or submodule, as defined by the
> > >> "revision" statement (Section 7.1.9).
> > >>
> > >> While the SHOULD statements provide a recommendation, the
> > >> square-brackets "[]" impart no bias, and the text is ambiguous.
> > >> That is, is the revision-date optional *only* because the
> > >> revision statement is optional within the module?  What is
> > >> the recommendation for when the revision statement is present?
> > >> The RFC7950 text isn't clear.
> > >>
> > >> My opinion is that RFC7950 errata should state that the file
> > >> name SHOULD include the revision-date when the revision
> > >> statement appears within the module.
> > > That makes sense.
> > > Any other views?
> >
> > I don't feel strongly, but would it make more sense if instead
> > rfc6187bis stated that the file name SHOULD include the revision
date?
> > I.e. 7950 states what the filename is allowed to look like and
6187bis
> > states what they should look like for IETF produced models.

Yes, and I would also like RFC6087bis to require the date on the file
statement, if present, to match that on the revision statement - I have
seen several I-D where this has not been the case.  Something a tool
could check.

Should the date be the most recent revision statement?  I cannot see why
not.

Will there always be a revision statement?  RFC7950 says SHOULD,
cardinality 0..n so not always.

Tom Petch


> +1
>
>
> /martin
>
> ___
> 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] Interaction of 'when' and 'default' statements

2017-03-24 Thread t . petch

- Original Message -
From: "Phil Shafer" 
Sent: Thursday, March 23, 2017 8:24 PM

> William Ivory writes:
> >Yes, I'd noticed that.  Does this make the behaviour 'undefined' in
YANG 1.0?
>
> No, this was a clarification.  The text in 6020 was reasonably clear:
>
>The "when" statement makes its parent data definition statement
>conditional.  The node defined by the parent data definition
>statement is only valid when the condition specified by the "when"
>statement is satisfied.
>
> And no default should be provided for any invalid node.  If the node
> can't exist, the default can't either.

William

Having tracked the discussions that led to RFC7950, the sense I got was
that if you can avoid using 'when' then avoid using it.  If you cannot
avoid using 'when' avoid using it.  Not something that is ever likely to
appear in an I-D but the 'when' statement does have complex interactions
that may not be intuitive and although RFC7950 does spell them out, yet
they may not be apparent; which this thread also spells out to me:-)

I would not say this of any other YANG statement.

Tom Petch

> Thanks,
>  Phil
>
> ___
> 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] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

2017-03-24 Thread Andy Bierman

On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> >
> >
> > On 24/03/2017 08:09, Benoit Claise wrote:
> > > On 3/24/2017 2:32 AM, Kent Watsen wrote:
> > >> Hi Benoit,
> > >>
> > >> Section 4.2 of rfc6187bis says:
> > >>
> > >> The "" tag SHOULD be followed by a string
> > >> identifying the file name specified in Section 5.2 of
> > >> [RFC7950].
> > >>
> > >> While Section 5.2 of RFC7950 says:
> > >>
> > >> The name of the file SHOULD be of the form:
> > >>
> > >>   module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin'
> )
> > >>
> > >> "module-or-submodule-name" is the name of the module or
> > >> submodule, and the optional "revision-date" is the latest
> > >> revision of the module or submodule, as defined by the
> > >> "revision" statement (Section 7.1.9).
> > >>
> > >> While the SHOULD statements provide a recommendation, the
> > >> square-brackets "[]" impart no bias, and the text is ambiguous.
> > >> That is, is the revision-date optional *only* because the
> > >> revision statement is optional within the module?  What is
> > >> the recommendation for when the revision statement is present?
> > >> The RFC7950 text isn't clear.
> > >>
> > >> My opinion is that RFC7950 errata should state that the file
> > >> name SHOULD include the revision-date when the revision
> > >> statement appears within the module.
> > > That makes sense.
> > > Any other views?
> >
> > I don't feel strongly, but would it make more sense if instead
> > rfc6187bis stated that the file name SHOULD include the revision date?
> > I.e. 7950 states what the filename is allowed to look like and 6187bis
> > states what they should look like for IETF produced models.
>
> +1
>

This is fine, but this there is a larger goal of library consistency that is
impacted by this guideline. (such as the github/YangModels/yang repo.

1) changing the filename for each revision is not git-friendly
(if one wants to track changes over releases)

2) many revisions are actually obsolete work-in-progress
so keeping every old file around will grow into a problem

3) almost every import is import-without-revision so compiling the
old obsolete modules quickly breaks as the new work-in-progress version
makes incompatible changes.

However, import-by-revision breaks if you only keep the latest revision
around,
so these problems have to be managed by the YANG librarians ;-)



>
> /martin
>
>
Andy


> ___
> 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] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

2017-03-24 Thread Martin Bjorklund

Robert Wilton  wrote:
> 
> 
> On 24/03/2017 08:09, Benoit Claise wrote:
> > On 3/24/2017 2:32 AM, Kent Watsen wrote:
> >> Hi Benoit,
> >>
> >> Section 4.2 of rfc6187bis says:
> >>
> >> The "" tag SHOULD be followed by a string
> >> identifying the file name specified in Section 5.2 of
> >> [RFC7950].
> >>
> >> While Section 5.2 of RFC7950 says:
> >>
> >> The name of the file SHOULD be of the form:
> >>
> >>   module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
> >>
> >> "module-or-submodule-name" is the name of the module or
> >> submodule, and the optional "revision-date" is the latest
> >> revision of the module or submodule, as defined by the
> >> "revision" statement (Section 7.1.9).
> >>
> >> While the SHOULD statements provide a recommendation, the
> >> square-brackets "[]" impart no bias, and the text is ambiguous.
> >> That is, is the revision-date optional *only* because the
> >> revision statement is optional within the module?  What is
> >> the recommendation for when the revision statement is present?
> >> The RFC7950 text isn't clear.
> >>
> >> My opinion is that RFC7950 errata should state that the file
> >> name SHOULD include the revision-date when the revision
> >> statement appears within the module.
> > That makes sense.
> > Any other views?
> 
> I don't feel strongly, but would it make more sense if instead
> rfc6187bis stated that the file name SHOULD include the revision date?
> I.e. 7950 states what the filename is allowed to look like and 6187bis
> states what they should look like for IETF produced models.

+1


/martin

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

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

2017-03-24 Thread Robert Wilton




On 24/03/2017 08:09, Benoit Claise wrote:

On 3/24/2017 2:32 AM, Kent Watsen wrote:

Hi Benoit,

Section 4.2 of rfc6187bis says:

The "" tag SHOULD be followed by a string
identifying the file name specified in Section 5.2 of
[RFC7950].

While Section 5.2 of RFC7950 says:

The name of the file SHOULD be of the form:

  module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

"module-or-submodule-name" is the name of the module or
submodule, and the optional "revision-date" is the latest
revision of the module or submodule, as defined by the
"revision" statement (Section 7.1.9).

While the SHOULD statements provide a recommendation, the
square-brackets "[]" impart no bias, and the text is ambiguous.
That is, is the revision-date optional *only* because the
revision statement is optional within the module?  What is
the recommendation for when the revision statement is present?
The RFC7950 text isn't clear.

My opinion is that RFC7950 errata should state that the file
name SHOULD include the revision-date when the revision
statement appears within the module.

That makes sense.
Any other views?


I don't feel strongly, but would it make more sense if instead 
rfc6187bis stated that the file name SHOULD include the revision date?  
I.e. 7950 states what the filename is allowed to look like and 6187bis 
states what they should look like for IETF produced models.


Thanks,
Rob




Regards, Benoit


Kent // contributor


-ORIGINAL MESSAGE-

Dear all,

[Preparing the IETF hackathon]

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2 


What is the guideline regarding:
   file "ietf-...@2016-03-20.yang"
  versus
   file "ietf-foo.yang"

Right now, we have a mix of behaviors.
This implies that the extracted YANG modules sometimes contains the
revision, but not always.

Regards, Benoit

___
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] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

2017-03-24 Thread Benoit Claise


On 3/24/2017 2:32 AM, Kent Watsen wrote:

Hi Benoit,

Section 4.2 of rfc6187bis says:

The "" tag SHOULD be followed by a string
identifying the file name specified in Section 5.2 of
[RFC7950].

While Section 5.2 of RFC7950 says:

The name of the file SHOULD be of the form:

  module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

"module-or-submodule-name" is the name of the module or
submodule, and the optional "revision-date" is the latest
revision of the module or submodule, as defined by the
"revision" statement (Section 7.1.9).

While the SHOULD statements provide a recommendation, the
square-brackets "[]" impart no bias, and the text is ambiguous.
That is, is the revision-date optional *only* because the
revision statement is optional within the module?  What is
the recommendation for when the revision statement is present?
The RFC7950 text isn't clear.

My opinion is that RFC7950 errata should state that the file
name SHOULD include the revision-date when the revision
statement appears within the module.

That makes sense.
Any other views?

Regards, Benoit


Kent // contributor


-ORIGINAL MESSAGE-

Dear all,

[Preparing the IETF hackathon]

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2
What is the guideline regarding:
   file "ietf-...@2016-03-20.yang"
  versus
   file "ietf-foo.yang"

Right now, we have a mix of behaviors.
This implies that the extracted YANG modules sometimes contains the
revision, but not always.

Regards, Benoit

___
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] uses and augment

2017-03-24 Thread Juergen Schoenwaelder

On Thu, Mar 23, 2017 at 08:50:48PM -0400, Dale R. Worley wrote:
> Martin Bjorklund  writes:
> >> I notice that "augment" is not allowed to target a "grouping", despite
> >> that naively seems to be an operation that a module designer might like
> >> to do.  I expect that there is a reason why this is not allowed.
> >
> > There were lots of debate over this one when we first designed YANG.
> > The main reason for not allowing this is that it can easily have
> > unintended consequences.  Module A uses a grouping G b/c it fits the
> > purpose.  Later someone augments G with some nodes; at this point it
> > is not at all clear that the additional nodes are suitable for module
> > A.
> 
> True...  But assuming that the grouping G has clean semantics, it
> corresponds to some facility in the device, which in some way or another
> appears in multiple places in the device's data model.  And a module
> that augments G adds semantics about that facility, and would only be
> implemented by a device for which the facility uniformly has that
> additional semantics.  So it would be suitable for every place where the
> grouping is used.

But this is an assumption and it is not generally true.

[...]
 
> But what I'm considering is a modification of
> the grouping which implicitly applies to all "uses" of that grouping --
> because you don't want to have duplicate declarations of the added nodes
> in every place the grouping is used.

There may be cases where this may appear useful but I see also cases
where people will get largely suprised by the result if such wildcard
augmentations would be possible.

> > Augments are restricted to things that have a well defined name in the
> > data tree because this makes it clear what is being augmented. One
> > would have to create additional language constructs to make
> > augmentations of groupings work.
> 
> It's clear that *groupings* have well-defined names, because "uses"
> statements can refer to them.

I wrote 'name in the data tree' and I meant 'name in the schema tree'
(sorry). Augments apply to something that has a name in the schema
tree, groupings do not have that.

   The "grouping" statement is not a data definition statement and, as
   such, does not define any nodes in the schema tree.

> RFC 7950 section 7.13 isn't particularly
> clear about how the argument string of the statement is to be
> interpreted, but going back over 7950, I'm getting the idea that the
> names of groupings are not descendant-schema-nodeid's, that is, named
> based on where the grouping statement sits in the syntactic hierarchy,
> but are in a separate namespace which is flat regarding equality and
> inequality comparisons, but has elaborate scoping rules regarding which
> groupings are visible in which locations.

Yes.

> OK, that clarifies why you can't apply "augment" to a grouping --
> groupings (and thus the things defined within them) don't have names
> that can be expressed by descendant-schema-nodeid's.

Yes. This is how things were defined.

/js

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

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

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

Re: [netmod] Interaction of 'when' and 'default' statements

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

Re: [netmod] file "ietf-...@2016-03-20.yang" or file "ietf-foo.yang"

Re: [netmod] uses and augment

8 matches

Site Navigation

Mail list logo

Footer information