Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

[Ladislav Lhotka]

Randy Presuhn  writes:

> Hi -
>
>>From: Juergen Schoenwaelder 
>>Sent: Sep 14, 2015 11:41 PM
>>To: Ladislav Lhotka 
>>Cc: NETMOD Working Group 
>>Subject: Re: [netmod] Fwd: New Version Notification for 
>>draft-ietf-netmod-yang-json-05.txt
> ...
>>My question is why the text is silent about the case where the data
>>model is present. Should it not say that if the data model is present,
>>the data encoded inside the anydata node must follow the rules of this
>>document? Perhaps this is the implicit assumption but I think it will
>>be useful to say this explicitly (if we agree on this).
>>
>>If the data model is not present, then I think an implementation is
>>still expected to produce an encoding that follows the rules of this
>>document as much as possible except that things that requires data
>>model knowledge may be encoded differently (e.g., numbers appearing as
>>strings or namespace names being different). I am thinking along the
>>lines of this proposed new text:
>>
>>   An anydata data node can contain an unknown set of nodes that can
>>   be modelled by YANG. A data model for anydata content may or may
>>   not exist at run time.  If the data model for anydata content is
>>   available, then the anydata content MUST be encoded according to
>>   the rules of this specification. If the data model for anydata
>>   content is not available, the encoding MUST follow the rules of
>>   this specification except for rules that require data model
>>   knowledge (and as a consequence, numbers may appear as strings or
>>   namespace qualifiers may not match module names).
>
> This leaves me wondering what it means for the data model for
> anydata content to be "available".  In the case of ASN.1's
> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> unambiguously identify the grammar (and associated semantics)
> to be used to understand the content, so tools can, if needed,
> scurry off to obtain the parsing instructions for those
> particular bits.  How does an implementation know in the case
> of "anydata" which datamodel to use?

It can be stated in the description of the anydata statement. One can
then ask though why we need two constructs - anyxml and anydata -
because a data model can be specified in the description of an anyxml
statement as well.

Lada

>
> Randy
>
> ___
> 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] YANG 1.0 behavior for leafref

[Andy Bierman]

On Tue, Sep 15, 2015 at 4:28 PM, Anees Shaikh  wrote:

> Isn't there already a verified errata for this same issue with the same
> recommendation (Errata ID: 2949) ?
>
>
yes -- sorry for bringing it up.
I should have checked there first.

-- Anees
>

Andy


>
> On Tue, Sep 15, 2015 at 3:15 PM, Andy Bierman  wrote:
>
>> Hi,
>>
>> The leafref text was changed to allow the require-instance-stmt in YANG
>> 1.1
>>
>> RFC 6020, sec. 9.9. is quite clear that this sub-statement is not allowed.
>>
>> 9.9.1.  Restrictions
>>
>>A leafref cannot be restricted.
>>
>> 9.13.1.  Restrictions
>>
>>An instance-identifier can be restricted with the "require-instance"
>>statement (Section 9.13.2).
>>
>>
>> However, the ABNF on page 149 clearly contradicts the text in 9.9.1:
>>
>>   leafref-specification =
>>  ;; these stmts can appear in any order
>>  path-stmt stmtsep
>>  [require-instance-stmt stmtsep]
>>
>>path-stmt   = path-keyword sep path-arg-str stmtend
>>
>>require-instance-stmt = require-instance-keyword sep
>> require-instance-arg-str stmtend
>>
>>
>>
>> So which normative text is correct?
>> Is instance-required-stmt allowing in YANG 1.0?
>>
>>
>> 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] YANG 1.0 behavior for leafref

[Anees Shaikh]

Isn't there already a verified errata for this same issue with the same
recommendation (Errata ID: 2949) ?

-- Anees

On Tue, Sep 15, 2015 at 3:15 PM, Andy Bierman  wrote:

> Hi,
>
> The leafref text was changed to allow the require-instance-stmt in YANG 1.1
>
> RFC 6020, sec. 9.9. is quite clear that this sub-statement is not allowed.
>
> 9.9.1.  Restrictions
>
>A leafref cannot be restricted.
>
> 9.13.1.  Restrictions
>
>An instance-identifier can be restricted with the "require-instance"
>statement (Section 9.13.2).
>
>
> However, the ABNF on page 149 clearly contradicts the text in 9.9.1:
>
>   leafref-specification =
>  ;; these stmts can appear in any order
>  path-stmt stmtsep
>  [require-instance-stmt stmtsep]
>
>path-stmt   = path-keyword sep path-arg-str stmtend
>
>require-instance-stmt = require-instance-keyword sep
> require-instance-arg-str stmtend
>
>
>
> So which normative text is correct?
> Is instance-required-stmt allowing in YANG 1.0?
>
>
> 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

[netmod] YANG 1.0 behavior for leafref

[Andy Bierman]

Hi,

The leafref text was changed to allow the require-instance-stmt in YANG 1.1

RFC 6020, sec. 9.9. is quite clear that this sub-statement is not allowed.

9.9.1.  Restrictions

   A leafref cannot be restricted.

9.13.1.  Restrictions

   An instance-identifier can be restricted with the "require-instance"
   statement (Section 9.13.2).


However, the ABNF on page 149 clearly contradicts the text in 9.9.1:

  leafref-specification =
 ;; these stmts can appear in any order
 path-stmt stmtsep
 [require-instance-stmt stmtsep]

   path-stmt   = path-keyword sep path-arg-str stmtend

   require-instance-stmt = require-instance-keyword sep
require-instance-arg-str stmtend



So which normative text is correct?
Is instance-required-stmt allowing in YANG 1.0?


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

[netmod] minutes of the NETMOD 2015-09-14 virtual interim meeting

[Juergen Schoenwaelder]

Hi,

attached are the minutes of the 2015-09-14 virtual interim meeting.
Please let me know if something needs fixing.

You can find all the virtual interim meeting minutes next to the YANG
1.1 issue list in the NETMOD WG subversion repository:

 http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
=
NETCONF Data Modeling Language WG (netmod)
21st YANG 1.1 Virtual Interim
Monday, September 14th, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=

* Participants

  AB = Andy Bierman
  BC = Benoit Claise
  JS = Juergen Schoenwaelder
  KW = Kent Watsen
  LL = Ladislav Lhotka
  MB = Martin Björklund
  TC = Tim Carey

* Coexistence Discussion

  There was some mailing list discussion around this topic since the
  last virtual interim meeting. Have we arrived at a resolution?

  LL: I think there can be issues even with a version 1 only server.
  MB: Why is there a problem with a version 1 only server?
  LL: What if client knows a 1.1 module and picks it instead?
  MB: The client must respect the modules announced by the server.
  MB: The latest revision is the latest revision advertised by the
  server, not the latest locally known revision.

  JS: We seem to have three options:

  1. If there is a 1.1 revision somewhere in the imports, the
 version 1 module is parsed as a 1.1 module.
  2. Version 1 modules are not allowed to import 1.1 modules, this
 means a server may need to announce the version of a module
 implemented and the version that may be used to resolve
 version 1 imports without revision.
  3. We allow version 1 modules to import from version 1.1
 modules.

  AB: The goal is not to break old clients. If adding 1.1 modules
  breaks clients, this is a problem for deployment.
  KW: Perhaps the problem is not big enough to worry about? This is
  just a one time software version upgrade.
  AB: What if we next do 1.2 etc? A massive upgrade without a real
  benefit may not be useful.
  AB: This problem would not exist if there would have been import by
  revision everywhere.
 
  AB: The version 1 client only knows about the hello module
  advertisements. So what about allowing an old client to continue
  with its view of world even if the server implements a 1.1
  version?
  LL: Does this not break with default statements that have changed a
  bit in YANG 1.1?
  MB: The old client will not see the default statement, I do not
  think this is a problem.
  KW: But it impacts things, e.g., when the client uses with-defaults.

  AB: It is important that the version upgrade to YANG 1.1 is a cheap
  and gradual process.
  MB: I agree.

  MB: If we upgrade ietf-interfaces to YANG 1.1, we still want to be
  able to use the YANG version 1 version of ietf-ip, which has not
  changed at all. We do not want to force a revision of ietf-ip
  just because ietf-interfaces a server implements got upgraded to
  1.1.
  
  TC: Why would a 1.0 client not utilize 1.0 data models?
  MB: Does this mean to implement multiple revisions? It depends on the
  changes whether this is expensive.
   
  TC: Does the minor version not imply nodes should be backwards
  compatible?
  JS: Lets not confuse data model version number and the version of
  the language data models are written in.

  JS: Announce YANG 1 modules via  messages and YANG 1.1
  modules via the YANG the library as long as they are
  semantically consistent, that is the YANG version 1 module
  remains a proper valid subset of the module written in YANG 1.1.

  KW: Is there an issue with get-schema?
  MB: No, there is a version input parameter that makes this clear.

  Action: Add text and examples to the guidelines document explaining
  how servers implementing YANG 1.1 modules can support
  modules written in YANG version 1 and when in which
  situations servers might need to stop supporting modules
  written in YANG version 1.

* Constraints Discussion

  LL and MB discuss something internally, they will summarize the
  proposal to the list once they conclude the discussion.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

[Andy Bierman]

On Tue, Sep 15, 2015 at 12:01 PM, Randy Presuhn <
randy_pres...@mindspring.com> wrote:

> Hi -
>
> >From: Juergen Schoenwaelder 
> >Sent: Sep 14, 2015 11:41 PM
> >To: Ladislav Lhotka 
> >Cc: NETMOD Working Group 
> >Subject: Re: [netmod] Fwd: New Version Notification for
> draft-ietf-netmod-yang-json-05.txt
> ...
> >My question is why the text is silent about the case where the data
> >model is present. Should it not say that if the data model is present,
> >the data encoded inside the anydata node must follow the rules of this
> >document? Perhaps this is the implicit assumption but I think it will
> >be useful to say this explicitly (if we agree on this).
> >
> >If the data model is not present, then I think an implementation is
> >still expected to produce an encoding that follows the rules of this
> >document as much as possible except that things that requires data
> >model knowledge may be encoded differently (e.g., numbers appearing as
> >strings or namespace names being different). I am thinking along the
> >lines of this proposed new text:
> >
> >   An anydata data node can contain an unknown set of nodes that can
> >   be modelled by YANG. A data model for anydata content may or may
> >   not exist at run time.  If the data model for anydata content is
> >   available, then the anydata content MUST be encoded according to
> >   the rules of this specification. If the data model for anydata
> >   content is not available, the encoding MUST follow the rules of
> >   this specification except for rules that require data model
> >   knowledge (and as a consequence, numbers may appear as strings or
> >   namespace qualifiers may not match module names).
>
> This leaves me wondering what it means for the data model for
> anydata content to be "available".  In the case of ASN.1's
> "ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
> unambiguously identify the grammar (and associated semantics)
> to be used to understand the content, so tools can, if needed,
> scurry off to obtain the parsing instructions for those
> particular bits.  How does an implementation know in the case
> of "anydata" which datamodel to use?
>
>
Good questions
The text "If the data model for anydata content is available" gives a hint
of just
what a hack anydata is in YANG.  The definition of anydata is that there is
no data model for the specified subtree.  The mere mention of an out-of-band
data mode is inappropriate and confusing.

I understand this is intended to support usage like in YANG Patch, where the
description-stmt of 'value' says that the child node must follow the schema
for the node in the target leaf.  More hacks to get YANG to work.

Once again we confuse conformance to YANG with conformance to
a module written in YANG.  The YANG Patch text can make additional
requirements for conformance to YANG Patch.  This is quite different
than generic conformance to RFC6020bis.




Randy
>


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] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

[Randy Presuhn]

Hi -

>From: Juergen Schoenwaelder 
>Sent: Sep 14, 2015 11:41 PM
>To: Ladislav Lhotka 
>Cc: NETMOD Working Group 
>Subject: Re: [netmod] Fwd: New Version Notification for 
>draft-ietf-netmod-yang-json-05.txt
...
>My question is why the text is silent about the case where the data
>model is present. Should it not say that if the data model is present,
>the data encoded inside the anydata node must follow the rules of this
>document? Perhaps this is the implicit assumption but I think it will
>be useful to say this explicitly (if we agree on this).
>
>If the data model is not present, then I think an implementation is
>still expected to produce an encoding that follows the rules of this
>document as much as possible except that things that requires data
>model knowledge may be encoded differently (e.g., numbers appearing as
>strings or namespace names being different). I am thinking along the
>lines of this proposed new text:
>
>   An anydata data node can contain an unknown set of nodes that can
>   be modelled by YANG. A data model for anydata content may or may
>   not exist at run time.  If the data model for anydata content is
>   available, then the anydata content MUST be encoded according to
>   the rules of this specification. If the data model for anydata
>   content is not available, the encoding MUST follow the rules of
>   this specification except for rules that require data model
>   knowledge (and as a consequence, numbers may appear as strings or
>   namespace qualifiers may not match module names).

This leaves me wondering what it means for the data model for
anydata content to be "available".  In the case of ASN.1's
"ANY DEFINED BY" construct, there's an OBJECT IDENTIFIER to
unambiguously identify the grammar (and associated semantics)
to be used to understand the content, so tools can, if needed,
scurry off to obtain the parsing instructions for those
particular bits.  How does an implementation know in the case
of "anydata" which datamodel to use?

Randy

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

[netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

[Eric Voit (evoit)]

There was a recent thread on structuring YANG models so that application 
developers might be able to reference alternative local hierarchies/tree 
structures for certain objects.  This thread motivated Alex, Sander, and I to 
rework the YANG Mount requirements draft.  v03 is posted at:
http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/

This draft has been retitled to "Requirements for mounting of local and remote 
YANG subtrees".  This retitling was done because we have separated the thinking 
on what it takes to Mount objects from remote devices (Peer Mount) from what it 
takes to Mount within the same device (Alias Mount).

We would be interested in your thoughts.   

Eric

-Original Message-
From: Ladislav Lhotka, August 31, 2015 11:05 AM

Randy Presuhn  writes:

> Hi -
>
> It is with no little amusement that I watch this thread struggling 
> with questions that were solved fairly neatly a quarter century ago in 
> GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would like 
> to offer an observation about modeling that might help.
>
> The organization of instance data in SNMP is a direct mirror of the 
> "object" definitions.  Simple at first, but quickly becoming baroque 
> as various minds of "multiplexing" are added to compensate for post 
> hoc deficiencies in the index structures.
>
> Life is such that once a resource has been modeled, it will be 
> used/re-used/embedded in systems in ways in which its designers 
> couldn't be expected to imagine.  A consequence of this is that if 
> instance naming is completely locked down when the management 
> interface for a resource is first defined (as it is in SNMP) then all 
> sorts of peculiar hacks will be needed to deal with, for example, 
> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so 
> pervasive that folks seem to overlook that there are other ways to 
> deal with this situation.
>
> What GDMO did was to use a separate "NAME BINDING" construct to 
> specify contexts in which instances might show up, allowing instances 
> to be put in places that weren't even imagined when the original class 
> definition was written.  Name bindings could be standardized, or be 
> vendor or even product-specific, allowing the simplicity or complexity 
> of a given system's instance tree to reflect the actual simplicity or 
> complexity of that system, rather than requiring all systems to be 
> structured for the worst case.

How could this be expressed in YANG terms? (I tried to figure it out myself but 
I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recommendation 
X.722).

Thanks, Lada

>
> Yes, separating the specification of instance naming in large part 
> from class definition does have implications for how one does access 
> control, and how clients figure out how to ask a server to create 
> something, but it's not a huge deal - it's just not like VACM, and a 
> whole slew of hacky solutions and "wierd plumbing adapters" (to borrow 
> from Jeff Case) just go away.  Strangely, it makes the job of the 
> initial modeler and of the eventual user much easier.
>
> Randy
>
> ___
> 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] Y60 - coexistence with YANG 1.0

[Andy Bierman]

On Tue, Sep 15, 2015 at 6:47 AM, Ladislav Lhotka  wrote:

>
> > On 15 Sep 2015, at 15:22, Andy Bierman  wrote:
> >
> >
> >
> > On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> >
> > > On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> > > j.schoenwael...@jacobs-university.de> wrote:
> > >
> > >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> > >> >
> > >> > Sure.  The use case is for example servers that implement ietf-ip
> > >> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > >> > update ietf-interfaces to 1.1.  It should still be ok for a server
> to
> > >> > implement ietf-ip with the new ietf-interfaces.
> > >> >
> > >>
> > >> Is the confusion is between implements and imports here? The module
> > >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> > >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> > >> this not going to work?
> > >>
> > >
> > >
> > > Here is the guidance put in RFC 6020 for this occasion:
> > >
> > >Handling of the "yang-version" statement for versions other than "1"
> > >(the version defined here) is out of scope for this specification.
> > >Any document that defines a higher version will need to define the
> > >backward compatibility of such a higher version.
> > >
> > >
> > > All current Yuma based tools see the yang-version 1.1; and exit:
> > >
> > > ietf-entity.yang:54.16: error(314): wrong version
> > >
> > > Error: cannot continue with unknown YANG language version
> >
> > I don't think this has to be a strict rule for clients. After all, a
> > client can send any request and it is up to the server to decide whether
> > the request is valid and send a reply or error message.
> >
> >
> > Not sure what you mean.
> > A tool that does not claim conformance because it does not recognize the
> > YANG language does not have any rules to follow.
> >
> > We cannot make any rules whatsoever that a YANG 1.0 tool
> > must follow wrt/ other YANG language versions.  That much is rather
> clear.
>
> I don’t want to enforce classification of clients and then require that a
> 1.0 client MUST exit when seeing yang-version 1.1.
>
>

The YANG 1.0 spec was already published.

For a YANG 1.0 implementation there are no rules for how it must deal
with a yang-version value other than '1'.

The behavior is out of scope.
Anything a YANG 1.0 tool does with 1.1, including exit right away, is
compliant.


> Lada
>
>

Andy


> >
> > >
> > >
> > >
> > > The solution outlined this morning should mostly work.
> > > A YANG 1.0 client may be able to use only revisions written in YANG
> 1.0,
> > > even if the server has upgrades some of those modules to YANG 1.1.
> > > Note that a server has total control when it introduces modules
> > > written in YANG 1.1. Not the client.
> > >
> > > If module 'foo' is upgraded to a new module revision,
> > > and the new module revision uses YANG 1.1, then
> > > the server will advertise the last YANG 1.0
> > > revision for module 'foo' in the YANG 1.0 .
> > > The YANG 1.1 library will contain both module revisions,
> > > and the server will set conformance to 'implement' for the 1.1
> > > version.
> >
> > Does this apply only to the case when the old and new revisions of "foo"
> are
> > identical except for yang-version?
> >
> >
> > It is up to the server vendor, as Martin said.
> >
> >
> > >
> > > If the data that existed in the last revision written in YANG 1.0
> > > has changed in the implemented revision written in YANG 1.1,
> > > then the server should not (or must not?) advertise the 'phantom'
> > > YANG 1.0 revision anymore.
> >
> > But then an old 1.0-only client is stuck, right?
> >
> >
> > Yep -- the version written in YANG 1.1 might diverge from the last
> revision
> > written in YANG 1.0.  Then forklift upgrades are needed.  And since YANG
> is far
> > from stable, one might expect to go through churn every year until YANG
> is stable.
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > >
> > >  Andy
> > >
> > >
> > >
> > >> > > Would it not work if an import of ietf-interfaces from a
> > >> > > version 1 module simply resolves to the latest ietf-interfaces
> > >> > > revision that is still version 1?
> > >> >
> > >> > But that would mean either that a server is stuck implementing
> version
> > >> > 1 modules, or that the server must implement both the version 1 and
> > >> > version 1.1 module - and we have already said that this isn't
> > >> > possible.
> > >>
> > >> But this seems only true if import === implemented.
> > >>
> > >> > A set of simpler rules would be:
> > >> >
> > >> >A YANG version 1.1 module MUST NOT include a version 1 module.
> > >> >A YANG version 1 module MUST NOT include a version 1.1 module.
> > >> >
> > >> >A YANG version 1.1 (sub)module MAY import a version 1 module.
> > >> >A YANG version 1 (sub)module MAY import a version 1.1 module.
> > >>
> > >> It is the last one we 

Re: [netmod] Y60 - coexistence with YANG 1.0

[Ladislav Lhotka]

> On 15 Sep 2015, at 15:54, Martin Bjorklund  wrote:
> 
> Juergen Schoenwaelder  wrote:
>> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
>>> 
>>> Sure.  The use case is for example servers that implement ietf-ip
>>> (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
>>> update ietf-interfaces to 1.1.  It should still be ok for a server to
>>> implement ietf-ip with the new ietf-interfaces.
>>> 
>> 
>> Is the confusion is between implements and imports here? The module
>> ietf-ip will _import_ an older version 1 ietf-interfaces while the
>> server _implements_ a newer version 1.1 ietf-interfaces module. Is
>> this not going to work?
>> 
 Would it not work if an import of ietf-interfaces from a
 version 1 module simply resolves to the latest ietf-interfaces
 revision that is still version 1?
>>> 
>>> But that would mean either that a server is stuck implementing version
>>> 1 modules, or that the server must implement both the version 1 and
>>> version 1.1 module - and we have already said that this isn't
>>> possible.
>> 
>> But this seems only true if import === implemented.
>> 
>>> A set of simpler rules would be:
>>> 
>>>   A YANG version 1.1 module MUST NOT include a version 1 module.
>>>   A YANG version 1 module MUST NOT include a version 1.1 module.
>>> 
>>>   A YANG version 1.1 (sub)module MAY import a version 1 module.
>>>   A YANG version 1 (sub)module MAY import a version 1.1 module.
>> 
>> It is the last one we are discussing, no? I am trying again: Why is
>> the MAY needed? Why is it not sufficient for a version 1 module to
>> work with an import for (the latest) version 1 module?
> 
> How about this:
> 
> ---
> 
> * Coexistence with YANG version 1 @coexistence@
> 
> A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
> and a YANG version 1 module MUST NOT include a YANG version 1.1
> submodule.

Does this apply only to include-by-revision? Because otherwise how can we tell?

> 
> A YANG version 1 module or submodule MUST NOT import a YANG version
> 1.1 module by revision.
> 
> A YANG version 1.1 module or submodule MAY import a YANG version
> 1 module by revision.
> 
> If a YANG version 1 module A imports module B without revision, and
> module B is updated to YANG version 1.1, a server MAY implement both

What about imports that are only for groupings/typedefs? “Implement” doesn’t 
cover this case, and such imported modules don’t appear in hello.

Lada

> these modules at the same time.  In such cases, a NETCONF server MUST
> advertise both modules using the rules defined in ^announce^, and
> SHOULD advertise module A and the latest revision of module B that is
> specified with YANG version 1 according   to the rules defined in
> ^RFC6020^.
> 
> This rule exists in order to allow implementations of existing YANG
> version 1 modules together with YANG version 1.1 modules.  Without
> this rule, updating a single module to YANG version 1.1 would have a
> cascading effect on modules that import it, requiring all of them to
> also be updated to YANG version 1.1, and so on.
> 
> 
> 
> Note that this text again talks about NETCONF in the main text...
> 
> 
> /martin
> 
> ___
> 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] Y60 - coexistence with YANG 1.0

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> > 
> > Sure.  The use case is for example servers that implement ietf-ip
> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> > update ietf-interfaces to 1.1.  It should still be ok for a server to
> > implement ietf-ip with the new ietf-interfaces.
> >
> 
> Is the confusion is between implements and imports here? The module
> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> this not going to work?
> 
> > > Would it not work if an import of ietf-interfaces from a
> > > version 1 module simply resolves to the latest ietf-interfaces
> > > revision that is still version 1?
> > 
> > But that would mean either that a server is stuck implementing version
> > 1 modules, or that the server must implement both the version 1 and
> > version 1.1 module - and we have already said that this isn't
> > possible.
> 
> But this seems only true if import === implemented.
> 
> > A set of simpler rules would be:
> > 
> >A YANG version 1.1 module MUST NOT include a version 1 module.
> >A YANG version 1 module MUST NOT include a version 1.1 module.
> > 
> >A YANG version 1.1 (sub)module MAY import a version 1 module.
> >A YANG version 1 (sub)module MAY import a version 1.1 module.
> 
> It is the last one we are discussing, no? I am trying again: Why is
> the MAY needed? Why is it not sufficient for a version 1 module to
> work with an import for (the latest) version 1 module?

How about this:

---

* Coexistence with YANG version 1 @coexistence@

A YANG version 1.1 module MUST NOT include a YANG version 1 submodule,
and a YANG version 1 module MUST NOT include a YANG version 1.1
submodule.

A YANG version 1 module or submodule MUST NOT import a YANG version
1.1 module by revision.

A YANG version 1.1 module or submodule MAY import a YANG version
1 module by revision.

If a YANG version 1 module A imports module B without revision, and
module B is updated to YANG version 1.1, a server MAY implement both
these modules at the same time.  In such cases, a NETCONF server MUST
advertise both modules using the rules defined in ^announce^, and
SHOULD advertise module A and the latest revision of module B that is
specified with YANG version 1 according to the rules defined in
^RFC6020^.

This rule exists in order to allow implementations of existing YANG
version 1 modules together with YANG version 1.1 modules.  Without
this rule, updating a single module to YANG version 1.1 would have a
cascading effect on modules that import it, requiring all of them to
also be updated to YANG version 1.1, and so on.



Note that this text again talks about NETCONF in the main text...


/martin

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

Re: [netmod] Y60 - coexistence with YANG 1.0

[Ladislav Lhotka]

> On 15 Sep 2015, at 15:22, Andy Bierman  wrote:
> 
> 
> 
> On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> 
> > On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> >> >
> >> > Sure.  The use case is for example servers that implement ietf-ip
> >> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> >> > update ietf-interfaces to 1.1.  It should still be ok for a server to
> >> > implement ietf-ip with the new ietf-interfaces.
> >> >
> >>
> >> Is the confusion is between implements and imports here? The module
> >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> >> this not going to work?
> >>
> >
> >
> > Here is the guidance put in RFC 6020 for this occasion:
> >
> >Handling of the "yang-version" statement for versions other than "1"
> >(the version defined here) is out of scope for this specification.
> >Any document that defines a higher version will need to define the
> >backward compatibility of such a higher version.
> >
> >
> > All current Yuma based tools see the yang-version 1.1; and exit:
> >
> > ietf-entity.yang:54.16: error(314): wrong version
> >
> > Error: cannot continue with unknown YANG language version
> 
> I don't think this has to be a strict rule for clients. After all, a
> client can send any request and it is up to the server to decide whether
> the request is valid and send a reply or error message.
> 
> 
> Not sure what you mean.
> A tool that does not claim conformance because it does not recognize the
> YANG language does not have any rules to follow.
> 
> We cannot make any rules whatsoever that a YANG 1.0 tool
> must follow wrt/ other YANG language versions.  That much is rather clear.

I don’t want to enforce classification of clients and then require that a 1.0 
client MUST exit when seeing yang-version 1.1.

Lada

> 
> >
> >
> >
> > The solution outlined this morning should mostly work.
> > A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
> > even if the server has upgrades some of those modules to YANG 1.1.
> > Note that a server has total control when it introduces modules
> > written in YANG 1.1. Not the client.
> >
> > If module 'foo' is upgraded to a new module revision,
> > and the new module revision uses YANG 1.1, then
> > the server will advertise the last YANG 1.0
> > revision for module 'foo' in the YANG 1.0 .
> > The YANG 1.1 library will contain both module revisions,
> > and the server will set conformance to 'implement' for the 1.1
> > version.
> 
> Does this apply only to the case when the old and new revisions of "foo" are
> identical except for yang-version?
> 
> 
> It is up to the server vendor, as Martin said.
>  
> 
> >
> > If the data that existed in the last revision written in YANG 1.0
> > has changed in the implemented revision written in YANG 1.1,
> > then the server should not (or must not?) advertise the 'phantom'
> > YANG 1.0 revision anymore.
> 
> But then an old 1.0-only client is stuck, right?
> 
> 
> Yep -- the version written in YANG 1.1 might diverge from the last revision
> written in YANG 1.0.  Then forklift upgrades are needed.  And since YANG is 
> far
> from stable, one might expect to go through churn every year until YANG is 
> stable.
> 
> 
> Lada
> 
> 
> Andy
>  
> 
> >
> >
> >  Andy
> >
> >
> >
> >> > > Would it not work if an import of ietf-interfaces from a
> >> > > version 1 module simply resolves to the latest ietf-interfaces
> >> > > revision that is still version 1?
> >> >
> >> > But that would mean either that a server is stuck implementing version
> >> > 1 modules, or that the server must implement both the version 1 and
> >> > version 1.1 module - and we have already said that this isn't
> >> > possible.
> >>
> >> But this seems only true if import === implemented.
> >>
> >> > A set of simpler rules would be:
> >> >
> >> >A YANG version 1.1 module MUST NOT include a version 1 module.
> >> >A YANG version 1 module MUST NOT include a version 1.1 module.
> >> >
> >> >A YANG version 1.1 (sub)module MAY import a version 1 module.
> >> >A YANG version 1 (sub)module MAY import a version 1.1 module.
> >>
> >> It is the last one we are discussing, no? I am trying again: Why is
> >> the MAY needed? Why is it not sufficient for a version 1 module to
> >> work with an import for (the latest) version 1 module?
> >>
> >> /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] Y60 - coexistence with YANG 1.0

[Andy Bierman]

On Tue, Sep 15, 2015 at 2:31 AM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> >> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
> >> >
> >> > Sure.  The use case is for example servers that implement ietf-ip
> >> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
> >> > update ietf-interfaces to 1.1.  It should still be ok for a server to
> >> > implement ietf-ip with the new ietf-interfaces.
> >> >
> >>
> >> Is the confusion is between implements and imports here? The module
> >> ietf-ip will _import_ an older version 1 ietf-interfaces while the
> >> server _implements_ a newer version 1.1 ietf-interfaces module. Is
> >> this not going to work?
> >>
> >
> >
> > Here is the guidance put in RFC 6020 for this occasion:
> >
> >Handling of the "yang-version" statement for versions other than "1"
> >(the version defined here) is out of scope for this specification.
> >Any document that defines a higher version will need to define the
> >backward compatibility of such a higher version.
> >
> >
> > All current Yuma based tools see the yang-version 1.1; and exit:
> >
> > ietf-entity.yang:54.16: error(314): wrong version
> >
> > Error: cannot continue with unknown YANG language version
>
> I don't think this has to be a strict rule for clients. After all, a
> client can send any request and it is up to the server to decide whether
> the request is valid and send a reply or error message.
>
>
Not sure what you mean.
A tool that does not claim conformance because it does not recognize the
YANG language does not have any rules to follow.

We cannot make any rules whatsoever that a YANG 1.0 tool
must follow wrt/ other YANG language versions.  That much is rather clear.

>
> >
> >
> > The solution outlined this morning should mostly work.
> > A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
> > even if the server has upgrades some of those modules to YANG 1.1.
> > Note that a server has total control when it introduces modules
> > written in YANG 1.1. Not the client.
> >
> > If module 'foo' is upgraded to a new module revision,
> > and the new module revision uses YANG 1.1, then
> > the server will advertise the last YANG 1.0
> > revision for module 'foo' in the YANG 1.0 .
> > The YANG 1.1 library will contain both module revisions,
> > and the server will set conformance to 'implement' for the 1.1
> > version.
>
> Does this apply only to the case when the old and new revisions of "foo"
> are
> identical except for yang-version?
>


It is up to the server vendor, as Martin said.


>
> >
> > If the data that existed in the last revision written in YANG 1.0
> > has changed in the implemented revision written in YANG 1.1,
> > then the server should not (or must not?) advertise the 'phantom'
> > YANG 1.0 revision anymore.
>
> But then an old 1.0-only client is stuck, right?
>
>
Yep -- the version written in YANG 1.1 might diverge from the last revision
written in YANG 1.0.  Then forklift upgrades are needed.  And since YANG is
far
from stable, one might expect to go through churn every year until YANG is
stable.


Lada
>


Andy


>
> >
> >
> >  Andy
> >
> >
> >
> >> > > Would it not work if an import of ietf-interfaces from a
> >> > > version 1 module simply resolves to the latest ietf-interfaces
> >> > > revision that is still version 1?
> >> >
> >> > But that would mean either that a server is stuck implementing version
> >> > 1 modules, or that the server must implement both the version 1 and
> >> > version 1.1 module - and we have already said that this isn't
> >> > possible.
> >>
> >> But this seems only true if import === implemented.
> >>
> >> > A set of simpler rules would be:
> >> >
> >> >A YANG version 1.1 module MUST NOT include a version 1 module.
> >> >A YANG version 1 module MUST NOT include a version 1.1 module.
> >> >
> >> >A YANG version 1.1 (sub)module MAY import a version 1 module.
> >> >A YANG version 1 (sub)module MAY import a version 1.1 module.
> >>
> >> It is the last one we are discussing, no? I am trying again: Why is
> >> the MAY needed? Why is it not sufficient for a version 1 module to
> >> work with an import for (the latest) version 1 module?
> >>
> >> /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
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
___

Re: [netmod] Y60 - coexistence with YANG 1.0

[Ladislav Lhotka]

Andy Bierman  writes:

> On Mon, Sep 14, 2015 at 8:02 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> On Mon, Sep 14, 2015 at 03:54:59PM +0200, Martin Bjorklund wrote:
>> >
>> > Sure.  The use case is for example servers that implement ietf-ip
>> > (which imports ietf-interfaces), and ietf-interfaces.  Suppose we
>> > update ietf-interfaces to 1.1.  It should still be ok for a server to
>> > implement ietf-ip with the new ietf-interfaces.
>> >
>>
>> Is the confusion is between implements and imports here? The module
>> ietf-ip will _import_ an older version 1 ietf-interfaces while the
>> server _implements_ a newer version 1.1 ietf-interfaces module. Is
>> this not going to work?
>>
>
>
> Here is the guidance put in RFC 6020 for this occasion:
>
>Handling of the "yang-version" statement for versions other than "1"
>(the version defined here) is out of scope for this specification.
>Any document that defines a higher version will need to define the
>backward compatibility of such a higher version.
>
>
> All current Yuma based tools see the yang-version 1.1; and exit:
>
> ietf-entity.yang:54.16: error(314): wrong version
>
> Error: cannot continue with unknown YANG language version

I don't think this has to be a strict rule for clients. After all, a
client can send any request and it is up to the server to decide whether
the request is valid and send a reply or error message.

>
>
>
> The solution outlined this morning should mostly work.
> A YANG 1.0 client may be able to use only revisions written in YANG 1.0,
> even if the server has upgrades some of those modules to YANG 1.1.
> Note that a server has total control when it introduces modules
> written in YANG 1.1. Not the client.
>
> If module 'foo' is upgraded to a new module revision,
> and the new module revision uses YANG 1.1, then
> the server will advertise the last YANG 1.0
> revision for module 'foo' in the YANG 1.0 .
> The YANG 1.1 library will contain both module revisions,
> and the server will set conformance to 'implement' for the 1.1
> version.

Does this apply only to the case when the old and new revisions of "foo" are
identical except for yang-version? 

>
> If the data that existed in the last revision written in YANG 1.0
> has changed in the implemented revision written in YANG 1.1,
> then the server should not (or must not?) advertise the 'phantom'
> YANG 1.0 revision anymore.

But then an old 1.0-only client is stuck, right?

Lada

>
>
>  Andy
>
>
>
>> > > Would it not work if an import of ietf-interfaces from a
>> > > version 1 module simply resolves to the latest ietf-interfaces
>> > > revision that is still version 1?
>> >
>> > But that would mean either that a server is stuck implementing version
>> > 1 modules, or that the server must implement both the version 1 and
>> > version 1.1 module - and we have already said that this isn't
>> > possible.
>>
>> But this seems only true if import === implemented.
>>
>> > A set of simpler rules would be:
>> >
>> >A YANG version 1.1 module MUST NOT include a version 1 module.
>> >A YANG version 1 module MUST NOT include a version 1.1 module.
>> >
>> >A YANG version 1.1 (sub)module MAY import a version 1 module.
>> >A YANG version 1 (sub)module MAY import a version 1.1 module.
>>
>> It is the last one we are discussing, no? I am trying again: Why is
>> the MAY needed? Why is it not sufficient for a version 1 module to
>> work with an import for (the latest) version 1 module?
>>
>> /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
>>
> ___
> 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-rfc6087bis-04.txt

[Ladislav Lhotka]

Jernej Tuljak  writes:

> Hi,
>
> current text in 6087bis-04 (Section 5.6.4):
>
> XPath expressions for 'when' statements SHOULD NOT reference the
> context node or any descendant nodes of the context node.  They MAY
> reference descendant nodes if the 'when' statement is contained
> within an 'augment' statement, and the referenced nodes are not
> defined within the 'augment' statement.
>
> This is OK. But the text never mentions an analogous case, which is when 
> a when-stmt is defined for a uses-stmt. I think this should be 
> corrected. Note that finding the initial context node for the expression 
> uses an algorithm that is virtually equal to the 'augment' case (first 
> data node ancestor), therefore the first sentence in the above text 
> discourages use of 'when' statements within a 'uses' statement, which I 
> don't think was the intention.
>
>grouping special-params {
>  leaf param1 {
>type string;
>  }
>  leaf param2 {
>type string;
>  }
>}
>
>container foo {
>  leaf enable-special {
>type boolean;
>  }
>  uses special-params {
>when "enable-special = 'true'";
>  }
>}
>
> In my example the expression references a descendant of the initial 
> context node, which should be OK. What would be problematic is 
> referencing descendants that are defined in the grouping.
>
> OLD:
>
> XPath expressions for 'when' statements SHOULD NOT reference the
> context node or any descendant nodes of the context node.  They MAY
> reference descendant nodes if the 'when' statement is contained
> within an 'augment' statement, and the referenced nodes are not
> defined within the 'augment' statement.
>
> NEW:
>
> XPath expressions for 'when' statements SHOULD NOT reference the
> context node or any descendant nodes of the context node.  They MAY
> reference descendant nodes if the 'when' statement is contained
> within an 'augment' statement, and the referenced nodes are not
> defined within the 'augment' statement. They MAY also reference
> descendant nodes if the 'when' statement is contained within a
> 'uses' statement, and the referenced nodes are not defined within
> the 'grouping' statement being referred to by the 'uses' statement.
>

+1

Lada

> Or something similar.
>
> Jernej
>
>
> internet-dra...@ietf.org je 6.7.2015 ob 19:14 napisal:
>> 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   : Guidelines for Authors and Reviewers of YANG Data 
>> Model Documents
>>  Author  : Andy Bierman
>>  Filename: draft-ietf-netmod-rfc6087bis-04.txt
>>  Pages   : 52
>>  Date: 2015-07-06
>>
>> Abstract:
>> This memo provides guidelines for authors and reviewers of Standards
>> Track specifications containing YANG data model modules.  Applicable
>> portions may be used as a basis for reviews of other YANG data model
>> documents.  Recommendations and procedures are defined, which are
>> intended to increase interoperability and usability of Network
>> Configuration Protocol (NETCONF) implementations that utilize YANG
>> data model modules.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-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
>>
>
> ___
> 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] Y26 again, sorry

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Thu, Sep 10, 2015 at 06:19:20PM -0700, Randy Presuhn wrote:
>  
>> >> Let's look at a slightly more complex hypothetical case to tease
>> >> out how folks *want* things to work.  Assume the following have
>> >> been defined:
>> >>
>> >>   - base module M
>> >>   - augmentation Q
>> >>   - augmentation R
>> >>
>> >> On a server claiming to supporting the modules containing M, Q,
>> >> and R, respectively, which of the following might one encounter
>> >> concurrently?
>> >>
>> >>  - plain M
>> >>  - M+Q
>> >>  - M+R
>> >>  - M+Q+R
>> >
>> >It depends on what you mean by "encounter" but in terms of datastore
>> >validity the only possible answer IMO is M+Q+R.
>> 
>> By "encounter" I mean if a client asks the server for all of its Ms,
>> and the server also supports Q and R, are all of the Ms *guaranteed*
>> to be M+Q+R, or is it possible that some of the Ms might lack Q or
>> lack R of lack both?  If what netmod gives us is strictly M+Q+R,
>> how would one model a system inhabited by a mixture of the four
>> kinds of Ms?
>
> Retrieval is easy since a client is going to ignore data it does not
> understand and the server is expected to report what makes sense from
> the server's perspective. The question is relevant for writing: Is a
> client programmed based on M going to work even if a server supports
> M+Q, M+R, or M+Q+R? I believe the rule stated in section 7.15 of RFC
> 6020 wanted to achieve this by forbidding mandatory nodes in
> augmentations.
>
> Y26-02 says that a presence container may be used to avoid breaking an
> old client. Frankly, it seems not totally clear to me what the
> sentence in section 7.15 of RFC 6020 really means:
>
> If the target node is in another module, then nodes added by the
> augmentation MUST NOT be mandatory nodes (see Section 3.1).
>
> Does this rule only apply to nodes directly added under the target
> node or does it apply to the whole hierarchy added? In the later case,
> this would still cause a problem with the presence container work
> around.

Yes, it's unclear but IMO it is about mandatory nodes directly below the
target node - a similar rule for module updates is in sec. 11.

>
> The recent suggestion to replace MUST NOT with SHOULD NOT in this
> sentence may be seen as a softer variant of Y26-01. However, I think
> we would, in addition, have to describe when it is OK to have
> mandatory nodes in augmentations and when not. Simply saying SHOULD
> NOT instead of MUST NOT will not help people to understand the issues
> around this.

The definition in RFC 2119 is:

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

I think it should suffice if data model designers are aware of the
fact that certain augments may break old clients, and give some
reasoning if they use them anyway. 

>
> When this issue was discussed in the past, it turned out to be
> difficult to find someone to write the necessary text explaining when
> augmenting mandatory nodes is safe and when not. Are we doing better
> now?

I don't think we can enumerate all cases where it is allowed because
YANG doesn't follow any rigid structure and there may be a variety of
different designs.

I'd prefer to explain the ramifications of defining mandatory nodes in
augments (and also in module updates) and leave it to the model designer
to judge whether there are valid reasons to override the "SHOULD NOT" -
and YANG doctors should verify it in IETF models.

I think the point is that parameters are mandatory not because a
spiteful module author defines them so but rather because the system
cannot work without them.

Lada


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

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

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

Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-05.txt

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Thu, Sep 10, 2015 at 10:46:10AM +0200, Ladislav Lhotka wrote:
>> Hi,
>> 
>> this revision introduces no changes to the encoding rules. The text was 
>> modified, and hopefully improved, in quite a few places, mainly due to 
>> Juergen’s review of -04, thanks Juergen.
>>
>
> Lada, a suggestion and a question concerning anydata. The text
> currently says:
>
>Anydata data node is a new feature in YANG 1.1.  It serves as a
>container for an unknown set of nodes that however appear as normal
>YANG-modeled data.  A data model for anydata content may or may not
>exist at run time.  In the latter case, no universal mapping between
>JSON- and XML-encoded instances is available.
>
> The suggestion is to rewrite the text to be more inline with the YANG
> 1.1 definition of anydata (and I do not think it matters to highlight
> that anydata is a YANG 1.1 thing, the document also mentions actions
> without saying this is a YANG 1.1 feature).
>
>An anydata data node can contain an unknown set of nodes that
>can be modelled by YANG. A data model for anydata content may or may not
>exist at run time.  In the latter case, no universal mapping between
>JSON- and XML-encoded instances is available.
>
> My question is why the text is silent about the case where the data
> model is present. Should it not say that if the data model is present,
> the data encoded inside the anydata node must follow the rules of this
> document? Perhaps this is the implicit assumption but I think it will
> be useful to say this explicitly (if we agree on this).

If we do agree on this, then IMO 6020bis is the right place to state it
because this rule should hold for any encoding. 

>
> If the data model is not present, then I think an implementation is
> still expected to produce an encoding that follows the rules of this
> document as much as possible except that things that requires data

I tried to specify these rules in the four bullets in sec. 5.5. Do you
think something else is needed?

Lada

> model knowledge may be encoded differently (e.g., numbers appearing as
> strings or namespace names being different). I am thinking along the
> lines of this proposed new text:
>
>An anydata data node can contain an unknown set of nodes that can
>be modelled by YANG. A data model for anydata content may or may
>not exist at run time.  If the data model for anydata content is
>available, then the anydata content MUST be encoded according to
>the rules of this specification. If the data model for anydata
>content is not available, the encoding MUST follow the rules of
>this specification except for rules that require data model
>knowledge (and as a consequence, numbers may appear as strings or
>namespace qualifiers may not match module names).
>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

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

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