Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

[Martin Bjorklund]

Hi,

Joel Jaeggli  wrote:
> Greetings,
> 
> This was supposed to get processed shortly after IETF 106, however I lost 
> track of it. We are therefore running a 2 week WGLC on 
> draft-ietf-netmod-nmda-diff-03.
> 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/
> 
> the 02 - 03 diff is available here:
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-nmda-diff-02=draft-ietf-netmod-nmda-diff-03
> 
> Please send email to the list indicating your support or concerns.


I have reviewed draft-ietf-netmod-nmda-diff-03 and have some comments.

o  Section 4

  (The filter dow not contain expressions that
  would match values data nodes, as this is not required by most use
  cases and would complicate the scheme, from implementation to
  dealing with race conditions.)

  I don't think it is a good idea to reject filters that match
  values.  For example, suppose I want to compare the config for a
  specific interface.  I could do /interfaces/interfac[name='eth0'],
  or a subtree filter.  Why should this not be possible?

  Besides, the mechanism of rejecting such filters is not defined.
  The only text we have is this sentence within parentheses.


o  leaf all in the YANG module

   s/Specifically, if one/For example, if one/


o  leaf xpath-filter

  The description needs to specify the XPath context, see RFC 6991.


o  container differences

  It is not clear what the YANG patch records reflect.  Is it the
  patches that are required to go from "source" to "target"?  Or the
  other way around?


o  anydata source-value

  This description needs work.  The current text isn't correct
  ('value' is not present when the operation is 'move').

  The description should explain what this is supposed to contain.


o  Section 6

  The example is confusing.  It seems the diff is the patches required
  to go from target to source.  And the source-value contains the
  origin present in the target, is that correct?  And the value
  contains an origin that isn't present in neither the source nor the
  target.



/martin

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

Re: [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf

[Martin Bjorklund]

Oscar González de Dios  wrote:
> 
> 
> -Mensaje original-----
> De: Martin Bjorklund 
> Enviado el: martes, 11 de febrero de 2020 11:00
> Para: Oscar González de Dios 
> CC: ops...@ietf.org; netmod@ietf.org
> Asunto: Re: [netmod] Question on how to design a Yang model to reflect
> auto-asignment of a give leaf
> 
> Hi,
> 
> Oscar González de Dios  wrote:
> > Dear OPSAWG and Netmod colleagues,
> >
> > During last IETF Opsawg meeting we raised a question (and
> > there was some discussion during the meeting) that we have
> > found yet no good answer and we would like to discuss it
> > with
> > operations and Yang experts.
> >
> > The use case is the following: We have a yang module which
> > holds certain optional leafs. The behaviors that we would
> > like
> > to have (and distinguish between them) are:
> >
> >
> > a) The user does not provide the value and such value is auto-assigned
> > by the system (a device (if it is a device module) or a controller (if
> > it is a network/service module)).
> 
> I assume that this value not a static default value?
> 
> [Oscar] True. Should the leaf have a default value, it implies that
> "if the value is not set, the default value is taken".
> 
> > b) The user does not provide a value and wants that such value IS NOT
> > set by the system (as assigning a value has implications). That is,
> > intentionally it is aimed at being left "empty" and should not be
> > expanded. So, either the value is set or should remain empty
> 
> Do you mean that you want (a) and (b) at the same time for the same
> leaf?
> 
> [Oscar] No. Depending on the leaf, we would like to specify behavior a
> or behavior b. Behavior a is ok for most of the cases.  The problem is
> that in some cases, assigning a value has way more implications and
> the service will not work properly. Those case are the ones we wanted
> to specifically tackle.

Ok.  See below.

> > What is the best way to model this behavior? I see that some yang
> > modules have added an "auto-assignment" leaf to express if
> > auto-assignment is desired or not. (hence, auto-assignment false, and
> > leaf not set, would do not assign).
> >
> > Which is the "default" rule for a leaf that is not set? It is that the
> > system is free to create it (via template or any means of
> > auto-assignment) or should leave it as is, that is, empty?
> >
> > In NMDA, the system is allowed to expand a given configuration. This
> > fact, in my personal view, implies that by "default" any system could
> > implement the "auto-assignment" behavior being compliant with
> > Neconf/Restconf/NMDA rules (but I am not sure if the interpretation is
> > correct).
> 
> There are (at least) three ways to interpret "auto-assign".  The
> client writes to running, and then the server auto-assigns X:
> 
>   (a) in running
>   (b) in intended
>   (c) in the operational state
> 
> (c) is uncontroversial and simple to implement in all servers, and
> simple to understand.
> [Oscar] agree
> 
> (b) is allowed by NMDA but requires more of the server implementation;
> specifically it requires the server to support that intended is
> different from running.
> [Oscar] Agree . "Theoretically speaking" this is the behavior I would
> consider strictly follows NMDA guidelines. Reality is implementations
> are yet far from this...
> 
> (a) is not recommended in general; running should be fully owned by
> the client(s) and not modified by the server.
> [Oscar] Agree.
> 
> [Oscar] So... what would be the best way to specify the behavior?
> Explicitly adding an auto-assign leaf to identify the behavior? Just
> "obey" NMDA rules?

For your "auto-assignment" case, I would describe the behaviour in the
description statement.  Something like: "If this leaf has not been
configured, the server will calculate a value [... specify how ... ]
and use that value operationally.  This calculated value is available
in the operational state."  

For your other case (the user really doesn't want a value) I also
would document this in the description (unless it's obvious).



/martin





> 
> 
> /martin
> 
> 
> 
> >
> > Best Regards,
> >
> > Óscar
> >
> > 
> >
> > Este mensaje y sus adjuntos se dirigen exclusivamente a su
> > destinatario, puede contener informa

Re: [netmod] Question on how to design a Yang model to reflect auto-asignment of a give leaf

[Martin Bjorklund]

Hi,

Oscar González de Dios  wrote:
> Dear OPSAWG and Netmod colleagues,
> 
> During last IETF Opsawg meeting we raised a question (and
> there was some discussion during the meeting) that we have
> found yet no good answer and we would like to discuss it with
> operations and Yang experts.
> 
> The use case is the following: We have a yang module which
> holds certain optional leafs. The behaviors that we would like
> to have (and distinguish between them) are:
> 
> 
> a) The user does not provide the value and such value is auto-assigned
> by the system (a device (if it is a device module) or a controller (if
> it is a network/service module)).

I assume that this value not a static default value?

> b) The user does not provide a value and wants that such value IS NOT
> set by the system (as assigning a value has implications). That is,
> intentionally it is aimed at being left "empty" and should not be
> expanded. So, either the value is set or should remain empty

Do you mean that you want (a) and (b) at the same time for the same
leaf?

> What is the best way to model this behavior? I see that some yang
> modules have added an "auto-assignment" leaf to express if
> auto-assignment is desired or not. (hence, auto-assignment false, and
> leaf not set, would do not assign).
> 
> Which is the "default" rule for a leaf that is not set? It is that the
> system is free to create it (via template or any means of
> auto-assignment) or should leave it as is, that is, empty?
> 
> In NMDA, the system is allowed to expand a given configuration. This
> fact, in my personal view, implies that by "default" any system could
> implement the "auto-assignment" behavior being compliant with
> Neconf/Restconf/NMDA rules (but I am not sure if the interpretation is
> correct).

There are (at least) three ways to interpret "auto-assign".  The
client writes to running, and then the server auto-assigns X:

  (a) in running
  (b) in intended
  (c) in the operational state

(c) is uncontroversial and simple to implement in all servers, and
simple to understand.

(b) is allowed by NMDA but requires more of the server implementation;
specifically it requires the server to support that intended is
different from running.

(a) is not recommended in general; running should be fully owned by
the client(s) and not modified by the server.



/martin



> 
> Best Regards,
> 
> Óscar
> 
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y
> es para uso exclusivo de la persona o entidad de destino. Si no es
> usted. el destinatario indicado, queda notificado de que la lectura,
> utilización, divulgación y/o copia sin autorización puede estar
> prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual
> or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly
> prohibited. If you have received this transmission in error, do not
> read it. Please immediately reply to the sender that you have received
> this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição

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

Re: [netmod] Schema mount and Network Instance model

[Martin Bjorklund]

Hi,

Mahesh Jethanandani  wrote:
> The network-instances YANG model [RFC8529] gives an example in
> Appendix A.1  of how
> to use schema mount to mount the routing protocol. An example modeled
> along those lines for the BGP YANG model, and enclosed herewith fails
> validation using yanglint with the following error. What am I doing
> wrong?
> 
> Validating yang/example-bgp-configuration-a.1.3.xml
> err : Unknown element
> "routing". 
> (/ietf-network-instance:network-instances/network-instance[name='vrf-red']/vrf-root)
> failed (error code: 0)
> 
> With confdc it fails as follows:
> 
> Loading Data for example a.1.3
> confd_load: 666: maapi_load_config(sock, tid, flags, abspath(argv[0]))
> failed: external error (19): Error on line 9: unknown element: routing
> in
> /ni:network-instances/ni:network-instance[ni:name='vrf-red']/ni:vrf-root/rt:routing
> 
> If what I have is not an error, it raises two questions. Is schema
> mount supported? Supported from a validation perspective. I can
> imagine that not everyone (or anyone) may have actually implemented
> schema mount.

Schema mount is (i) a generic mechanism for composing models at
specific mount points and (ii) a way for a server to report to clients
how this composition is done in the specific server (this may vary
dynamically over time).

The network-instance model is generic; it just defines a mount point
in the data model.  A specific server might be implemented to mount
the "ietf-routing" model under the mount point, and in that case it
will be able to validate the instance document you provided.

However, a generic YANG validator tool does not know (*) which models
are supposed to be mounted under any given mount point, and thus it
will probably raise an error (as you saw).

(*) unless you also pass it additional information about this in some
way (this could e.g. in the form of an instance document that contains
the /schema-mounts subtree and the ietf-yang-library contents for the
mount point)

As for implmentation support, we have implemented YANG schema mount in
NSO.

> And the second and more important question is how are routing
> protocols supposed to support VRF if the two models, network instance
> and routing protocol, do not work together? What needs to change to
> get them to work?

I think they do work together!


/martin

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

Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented

[Martin Bjorklund]

Hi

I agree w/ Andy and others that we should not add this to the import's
description.  I don't think this kind of conformance text belongs to
the import's description.  If you think it is important to state this,
the best place is probably as plain text in the document itself.



/martin


Balázs Lengyel  wrote:
> As a draft author who was asked to add text about the imports IMHO
> 
> * it would be easy for me to remove the description from the import. 
> Actually I really just want to know what is acceptable to the group, so I can 
> proceed
> * I also think that adding this text is in most cases easy and it does 
> not need updates later.
> * The rules in some cases might not be trivial.
> 
> * Imported YAMs need to be implemented if
> 
> * Imported parts are included in Xpath (augment, when, must, 
> require-instance)
> 
> * Imported YAMs do not need to be implemented if only the following are 
> used
> 
> * Types
> * Features
> * extensions
> 
> * Ambiguous if
> 
> * groupings are used
> * if the dependency is not formally defined by YANG, but functionally 
> needed. (E.g. notification-capabilities does not formally need YANG-Push to 
> be implemented, however there is no sense in defining capabilities if 
> YANG-Push is itself not implemented.)
> * deviation ?
> * other cases ?
> 
> Regards Balazs
> 
>  
> 
> From: netmod  On Behalf Of Andy Bierman
> Sent: 2019. december 19., csütörtök 17:23
> To: Ladislav Lhotka 
> Cc: NetMod WG 
> Subject: Re: [netmod] Text in import to indicate whether a module is needed 
> as import-only or as implemented
> 
>  
> 
>  
> 
>  
> 
> On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka   > wrote:
> 
> On Thu, 2019-12-19 at 07:52 +, Schönwälder, Jürgen wrote:
> > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka wrote:
> > > I don't see how YANG syntax defines this. If a module imports 
> > > ietf-netconf-
> > > acm, it could be because
> > > 
> > > - it just uses a typedef, such as "node-instance-identifier", and then
> > >   ietf-netconf-acm needn't be implemented (but can be),
> > > 
> > > or
> > > 
> > > - it augments ietf-netconf-acm, which makes sense only if the latter
> > >   module is implemented.
> > > 
> > > It it the YANG library that specifies whether a module is implemented or
> > > not, but the "import" statement itself doesn't tell you anything.
> > > 
> > 
> > Can we not assume that an implementor will figure out the difference?
> 
> An implementor should be able to figure it out, but other potential module 
> users
> may not. For example, if somebody is evaluating whether to use a module for
> their device or not, it is important to know that NACM has to be implemented 
> (or
> not).
> 
>  
> 
> You seem to be talking about a new conformance documentation procedure
> 
> that attempts to solve the problem "to use modules A, B, and C together
> 
> to achieve some functionality X, all these conditions need to be met".
> 
> (Sounds more like a problem for YANG Packages to solve)
> 
>  
> 
> IMO this is a much harder problem than something that can be solved
> 
> with extra description-stmt text. The writer is likely to get it wrong or not
> 
> keep it up to date, so a tool to analyze the file seems like a better 
> solution.
> 
>  
> 
> Lada
> 
>  
> 
>  
> 
> Andy
> 
>  
> 
> 
> > Or someone writes a pyang plugin to determine from the schema tree the
> > kind of imports there are (for a given set of features).
> > 
> > /js
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] Query about must statement syntax

[Martin Bjorklund]

Hi,

"Ivory, William"  wrote:
> Hi,
> 
> I've got a must statement that causes a compilation error on a Cisco NCS 
> device (admittedly ancient (NCS version 3.4.4), but can't update it), as 
> follows:
> 
> must "(../../packets * current()) <= (../../interval * 1000)";
> 
> Error is 'error: XPath syntax error: 40: unknown operator current'
> 
> However, our internal XPATH compiler thinks this is valid, and if I change 
> the order in the must statement to the following, the NCS is happy:
> 
> must "(current() * ../../packets) <= (../../interval * 1000)";
> 
> Can anyone confirm if there is a genuine error in the original must
> statement, or is it valid XPATH? 

The XPath expression is legal.


/martin

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

Re: [netmod] Question on YANG 'fraction-digit' statement

[Martin Bjorklund]

Hi,

"Ivory, William"  wrote:
> Hi,
> 
> I've got a question about the 'fraction-digit' statement which I'm
> hoping someone can clarify. I know it is used to specify the range of
> valid values, as shown (in part) in the table below:
> 
> 
>  ++---+--+
>  | fraction-digit | min   | max  |
>  ++---+--+
>  | 1  | -922337203685477580.8 | 922337203685477580.7 |
>  | 2  | -92233720368547758.08 | 92233720368547758.07 |
>  | 3  | -9223372036854775.808 | 9223372036854775.807 |
> 
> 
> 
> My question is whether it implicitly imposes any restriction on the
> number of digits that can follow the decimal point for a valid value,
> ie for 'fraction-digits 2', is 123.45678 valid, or only 123.45?

If fraction-digits is 2, it means, according to section 9.3 in RFC
7950, that the value space consists of the real numbers that are
expressible as "i x 10^-2", where "i" is a 64-bit integer.  123.45678
cannot be expressed in this way, which means that it is not a valid
value for this type.


/martin

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

Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-08.txt

[Martin Bjorklund]

Hi,

"Joe Clarke (jclarke)"  wrote:
>  On Dec 4, 2019, at 22:37, Qin Wu  wrote:
> 
>  v-08 is posted to address comments received from YANG doctor review and
>  additional comments from Joe.
>  The diff is:
>  https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-08
> 
> Thanks, Qin. But this isn’t actually what I had in mind. I was suggesting 
> text targeted at
> implementors but also warning operators along the lines of:
> 
> Operators should be aware that since all read-write datastores are
> immediately reset to 
> factor default, the device will become unreachable on the network.

s/will/may/

( and s/factor/factory/ )


> One should
> understand how a given vendor’s device will behave after the RPC is executed.

Perhaps s/One should/It is important to/?

> Implementors SHOULD reboot the device or otherwise restart processes needed to
> bootstrap it.
> 
> I realize Jürgen(?) or others had problems with calling out
> bootstrapping, but I do think
> some explicit advice is required so all parties are aware what the
> impact of executing the 
> RPC would have.

I had concerns with the previous text about bootstrapping, but I think
that your proposed text above is fine.


/martin



> 
> Joe
> 
>  -Qin
>  -邮件原件-
>  发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
>  internet-dra...@ietf.org
>  发送时间: 2019年12月5日 11:36
>  收件人: i-d-annou...@ietf.org
>  抄送: netmod@ietf.org
>  主题: I-D Action: draft-ietf-netmod-factory-default-08.txt
> 
>  A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Network Modeling WG of the IETF.
> 
>  Title : Factory Default Setting
>  Authors : Qin Wu
>  Balazs Lengyel
>  Ye Niu
>  Filename : draft-ietf-netmod-factory-default-08.txt
>  Pages : 11
>  Date : 2019-12-04
> 
>  Abstract:
>  This document defines a method to reset a server to its factory-
>  default content. The reset operation may be used, e.g., when the
>  existing configuration has major errors so re-starting the
>  configuration process from scratch is the best option.
> 
>  A new factory-reset RPC is defined. When resetting a datastore, all
>  previous configuration settings will be lost and replaced by the
>  factory-default content.
> 
>  A new optional "factory-default" read-only datastore is defined, that
>  contains the data that will be copied over to the running datastore
>  at reset.
> 
>  The IETF datatracker status page for this draft is:
>  https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/
> 
>  There are also htmlized versions available at:
>  https://tools.ietf.org/html/draft-ietf-netmod-factory-default-08
>  https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-08
> 
>  A diff from the previous version is available at:
>  https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-08
> 
>  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/
> 
>  ___
>  I-D-Announce mailing list
>  i-d-annou...@ietf.org
>  https://www.ietf.org/mailman/listinfo/i-d-announce
>  Internet-Draft directories: http://www.ietf.org/shadow.html or
>  ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>  ___
>  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] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

Hi,

See one more reply inline.

Martin Bjorklund  wrote:
> Hi,
> 
> Benjamin Kaduk via Datatracker  wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-yang-data-ext-04: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/
> > 
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > Section 1
> > 
> >The "yang-data" extension from [RFC8040] has been copied here,
> >renamed to "structure", and updated to be more flexible.  There is no
> > 
> > The Gen-Art reviewer had a good comment on this that should be acted
> > upon.
> 
> Yes. This is now changed to:
> 
>   This document defines a new YANG extension statement called
>   "structure", which is similar to but more flexible than the
>   "yang-data" extension from [RFC8040].
> 
> 
> > Section 2
> > 
> >This does not mean a YANG data structure has to be used as a top-
> >level protocol message or other top-level data structure.
> > 
> > I was confused by this until I got through Section 4, which (I think!)
> > clarified that I need a top-level extension directive to "declare the
> > named structure", but this is saying that once the structure is
> > declared, it can be placed anywhere in the tree as a "node of structure
> > type".
> 
> It means that once a structure is defined, we don't put any limitations
> on how / where it is used.  It might be used to define some kind of
> message that is used on its own, or it might be used to define a
> structure that can be nested within some other data.  
> 
> An example of the latter is given in A.5.
> 
> > Perhaps we could add a few words here to clarify, e.g., "YANG
> > data structure, once defined," or "A YANG data structure can be used as
> > any other data type, in the rest of the module"?
> 
> Yes, the former is better.  The sentence now reads:
> 
>   This does not mean a YANG data structure, once defined, has to be
>   used as a top-level protocol message or other top-level data
>   structure.
> 
> > Section 3
> > 
> > Do we need to say anything about how the child s under
> > structure/augment-structure get printed?  (I assume they get the same
> > handling as for the datastore tree, but could be wrong.)
> 
> They do.  Perhaps we can add:
> 
>Nodes in YANG data structures are printed according to the rules
>defined in section 2.6 in [RFC8340].
> 
> 
> > 
> >The new sections, including spaces conventions is:
> > 
> >structure :
> > 
> > (I see four spaces between the column the paragraph starts in and the
> > column the "structure" keyword starts in, not two.)
> 
> Thanks, fixed.
> 
> >[augment-structure]
> >[...]
> >  The sub-statements of this extension MUST follow the ABNF
> >   rules below, where the rules are defined in RFC 7950:
> > 
> > [status-stmt]
> > [description-stmt]
> > [reference-stmt]
> > 1*(data-def-stmt / case-stmt)
> > 
> > Comparing to RFC 7950's augment-stmt, we see that when-stmt and
> > if-feature-stmt are not present; would those be used externally to the
> > augment-structure declaration if needed?
> 
> I will discuss this with my co-author and get back.  It might be an
> oversight.

If you need "if-feature" or "when" in this situation you can put it on
the nodes inside the "augment-structure".  For example, instead of:

  augment-structure ... {
if-feature x;
container y;
  }

you would do:

  augment-structure ... {
container y {
  if-feature x;
}
  }

and similar for "when".



/martin


> 
> > Section 6
> > 
> > I might consider adding a note that the data being modelled might have
> > its own security considerations, but there's a pretty good case that
> > this is alrea

Re: [netmod] Roman Danyliw's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

Roman Danyliw via Datatracker  wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netmod-yang-data-ext-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Section 6. Recommend staying consistent with the standard YANG
> security considerations
> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and
> at least include this following subset (or something like it) of the
> boiler plate language:
> 
>The YANG module in this document defines an extension in the YANG data
>modeling language that will be imported and used by other modules.  When
>imported and used, the resultant schema will have data nodes that can
>be writable, or readable.  The access to such data nodes may be
>considered sensitive or vulnerable in some network environments.
>Write operations (e.g., edit-config) to these data nodes without
>proper protection can have a negative effect on network operations.

Hmm, I can't find this text in the boilerplate.  As discussed with
Benjamin Kaduk, we believe that the reference to 7950 is sufficient.

> Section 7.3.  What purpose will this section serve when published?  Is seems
> like it could be removed.  The only use of the [1] reference is Appendix C
> which is supposed to be removed before publication.

I have removed both 7.3 and Appendix C from my local copy.


/martin

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

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

Hi,

Benjamin Kaduk via Datatracker  wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netmod-yang-data-ext-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Section 1
> 
>The "yang-data" extension from [RFC8040] has been copied here,
>renamed to "structure", and updated to be more flexible.  There is no
> 
> The Gen-Art reviewer had a good comment on this that should be acted
> upon.

Yes. This is now changed to:

  This document defines a new YANG extension statement called
  "structure", which is similar to but more flexible than the
  "yang-data" extension from [RFC8040].


> Section 2
> 
>This does not mean a YANG data structure has to be used as a top-
>level protocol message or other top-level data structure.
> 
> I was confused by this until I got through Section 4, which (I think!)
> clarified that I need a top-level extension directive to "declare the
> named structure", but this is saying that once the structure is
> declared, it can be placed anywhere in the tree as a "node of structure
> type".

It means that once a structure is defined, we don't put any limitations
on how / where it is used.  It might be used to define some kind of
message that is used on its own, or it might be used to define a
structure that can be nested within some other data.  

An example of the latter is given in A.5.

> Perhaps we could add a few words here to clarify, e.g., "YANG
> data structure, once defined," or "A YANG data structure can be used as
> any other data type, in the rest of the module"?

Yes, the former is better.  The sentence now reads:

  This does not mean a YANG data structure, once defined, has to be
  used as a top-level protocol message or other top-level data
  structure.

> Section 3
> 
> Do we need to say anything about how the child s under
> structure/augment-structure get printed?  (I assume they get the same
> handling as for the datastore tree, but could be wrong.)

They do.  Perhaps we can add:

   Nodes in YANG data structures are printed according to the rules
   defined in section 2.6 in [RFC8340].


> 
>The new sections, including spaces conventions is:
> 
>structure :
> 
> (I see four spaces between the column the paragraph starts in and the
> column the "structure" keyword starts in, not two.)

Thanks, fixed.

>[augment-structure]
>[...]
>  The sub-statements of this extension MUST follow the ABNF
>   rules below, where the rules are defined in RFC 7950:
> 
> [status-stmt]
> [description-stmt]
> [reference-stmt]
> 1*(data-def-stmt / case-stmt)
> 
> Comparing to RFC 7950's augment-stmt, we see that when-stmt and
> if-feature-stmt are not present; would those be used externally to the
> augment-structure declaration if needed?

I will discuss this with my co-author and get back.  It might be an
oversight.

> Section 6
> 
> I might consider adding a note that the data being modelled might have
> its own security considerations, but there's a pretty good case that
> this is already covered in RFC 7950 and thus would be redundant here.

Yes I think that since we specifically refer to the text in 7950 we
shouldn't just repeat that text.  I guess we could repeat the text
from 7950 and remove the reference, but I think I would prefer to keep
the ref.

> Appendix A.1
> 
> Using last+first as the only naming options (and the list keys) is
> perhaps a bit unfortunate, given, e.g.,
> https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> (which has been popularized several times on varous social-media sites
> over the years).
> I suppose it still suffices for the purposes of this example, though.

I was going to suggest to use a single key "name", but that would
break his issues 1-4...  So hopefully the current list is ok; it is
just an example.

> Appendix A.3, A.4
> 
> As Alexey notes, maybe have two address entries in the example so
> that the reader sees
> the encoding of the list structure?

Ok, it doesn't hurt to add it, although I don't think that this
document is the right place to show examples of standard YANG encoding
rules.  I'll add one more address.


/martin

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

Re: [netmod] Question about schema-mount

[Martin Bjorklund]

Hi,


"Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> Hi Martin,
> 
> -Original Message-----
> From: Martin Bjorklund  
> Sent: Thursday, November 28, 2019 9:28 AM
> To: Bogaert, Bart (Nokia - BE/Antwerp) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question about schema-mount
> 
> Hi,
> 
> "Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> > Hi,
> > 
> > We're trying to figure out whether it is possible to define a module 
> > in the parent schema which would use a node being a leafref to a node 
> > in a model under a mount point.
> 
> In order for this to work, the leafref target would have to be present
> at compile time / design time.  RFC 8528 defines Design time,
> Implementation time, and Run time mounts, and says: "Design-time
> mounts are outside the scope of this document" (see section 1).
> 
> Another alternative would be some new kind of "leafref-like" construct
> that supported this.
> 
> What you can do though is to ensure the leaf in the parent module is
> of the same type as the mounted node you want to refer to, and explain
> in text what the semantics is.
> 
> [Bogaert, Bart] Thanks for this feedback.  The use case we're looking
> into is the following:
> [Bogaert, Bart] A forwarder contains references to interfaces which
> are defined as leafref with path /interfaces/interface/name.  In the
> scope of this question the path would be
> /logical-network/elements/logical-network-element/interfaces/interface/name.
> Question is: will this work with leafref?

No, since a YANG compiler that sees this leafref will fail to find the
target and thus throw an error.

[side note: a single leafref wouldn't work anyway, since you would the
name of both the lne and the name of the interface]

> What will the [Bogaert,
> Bart] NETCONF server do in such a case, in other word: is it able to
> resolve this leafref or do we have to define this as a some kind of
> string that includes the name of the logical-network-element and the
> name of the interface?

Yes, a single string or two leafs, 'lne-name' and 'if-name'.


/martin


> > I don't seem to find any statement
> > that would prohibit this but RFC 8530, referred to from the schema 
> > mount RFC, uses a leafref to a node in a module which is still in the 
> > list of YANG modules of the parent (and consequently in the YANG 
> > library of the parent).
> > 
> > So, using RFC8530 as example:
> > 
> > Instead of lne:bind-lne-name being a leafref to 
> > /logical-network-elements/logical-network-element/name we would point 
> > to 
> > /logical-network-elements/logical-network-element/interfaces/interface/name.
> > 
> > The interfaces YANG module is also part of the YANG library of the 
> > parent but I'm not so sure whether above construction would work well 
> > as the information related to the mounted YANG modules is in a YANG 
> > library different from the parent's YANG library.
> > 
> > Note that there is also some confusion with the examples in RFC8530:
> > while the bind-lne-name in the YANG module is a leafref as syntax, the
> > examples work with a string as syntax for that same leaf.
> 
> Do you mean the tree diagram?
> 
> [Bogaert, Bart] Correct.
> 
> Best regards, Bart
> 
>module: ietf-interfaces
>  +--rw interfaces
> +--rw interface* [name]
>+--rw namestring
>+--rw lne:bind-lne-name?  string
> 
> This looks like a bug to me; it should be a leafref.
> 
> 
> /martin
> 

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

Re: [netmod] Question about schema-mount

[Martin Bjorklund]

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> Hi,
> 
> We're trying to figure out whether it is possible to define a module
> in the parent schema which would use a node being a leafref to a node
> in a model under a mount point.

In order for this to work, the leafref target would have to be present
at compile time / design time.  RFC 8528 defines Design time,
Implementation time, and Run time mounts, and says: "Design-time
mounts are outside the scope of this document" (see section 1).

Another alternative would be some new kind of "leafref-like" construct
that supported this.

What you can do though is to ensure the leaf in the parent module is
of the same type as the mounted node you want to refer to, and explain
in text what the semantics is.


> I don't seem to find any statement
> that would prohibit this but RFC 8530, referred to from the schema
> mount RFC, uses a leafref to a node in a module which is still in the
> list of YANG modules of the parent (and consequently in the YANG
> library of the parent).
> 
> So, using RFC8530 as example:
> 
> Instead of lne:bind-lne-name being a leafref to
> /logical-network-elements/logical-network-element/name we would point
> to
> /logical-network-elements/logical-network-element/interfaces/interface/name.
> 
> The interfaces YANG module is also part of the YANG library of the
> parent but I'm not so sure whether above construction would work well
> as the information related to the mounted YANG modules is in a YANG
> library different from the parent's YANG library.
> 
> Note that there is also some confusion with the examples in RFC8530:
> while the bind-lne-name in the YANG module is a leafref as syntax, the
> examples work with a string as syntax for that same leaf.

Do you mean the tree diagram?

   module: ietf-interfaces
 +--rw interfaces
+--rw interface* [name]
   +--rw namestring
   +--rw lne:bind-lne-name?  string

This looks like a bug to me; it should be a leafref.


/martin

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

Re: [netmod] IANA registries and YANG

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> I would like to discuss the issue of developing YANG modules that
> mirror IANA registries. The main objection, raised in DNSOP WG in
> relation to draft-lhotka-dnsop-iana-class-type-yang-02, was that the
> RFC containing the initial revision of the module doesn't get updated
> along with the IANA registry (IANA is expected to keep the module in
> sync without updating the RFC). As a result implementors can use the
> obsolete snapshot from the RFC.
> 
> I am aware of three solution proposals:
> 
> 1. use some kind of template instead of a YANG module
> 
> 2. include only two or three entries of the registry as examples so
>that it is clear that it is not the complete list
> 
> 3. keep the module in the document during the whole I-D stage but
>instruct the RFC Editor to remove it just before it becomes RFC.

Do you mean that the RFC editor removes it and the RFC just points to
the IANA registry?  And then the RFC editor hands it over to IANA so
that they can use it as an initial version to be published?

As long as the instructions to the RFC editor are clear, I think this
can work.



/martin


> 
> I am personally in favour of #3. According to Randy Presuhn, who
> proposed it, this procedure was used during the preparation of BCP
> 47. It would require some extra coordination with with IANA but, apart
> from that, it should IMO work well and avoid the problem mentioned
> above.
> 
> Thanks, Lada
> 
> -- 
> Ladislav Lhotka 
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Balázs Lengyel  wrote:
> 
> 
> -Original Message-
> From: Martin Bjorklund  
> Sent: 2019. november 18., hétfő 0:53
> To: Balázs Lengyel 
> Cc: a...@yumaworks.com; netmod@ietf.org
> Subject: Re: [netmod] comments on
> draft-ietf-netmod-yang-instance-file-format-04
> 
> > > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  > > <mailto:m...@tail-f.com> > wrote:
> > > 
> > > 
> > >   o  leaf-list module
> > > 
> > > The type of this leaf-list is a string with:
> > > 
> > >   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> > > 
> > > I think the revision needs to be optional, and the suffix ".yang"
> > > dropped, since it doesn't add any value:
> > > 
> > >   pattern '.+(@\d{4}-\d{2}-\d{2})?';
> > > 
> > >(same for inline-spec).
> > > 
> > >  
> > > 
> > > IMO the filespec SHOULD follow the pattern in
> > > https://tools.ietf.org/html/rfc7950#section-5.2
> > > 
> > > BALAZS: It does follow the pattern except that I made the revision
> > > date mandatory. It is needed to properly understand the instance data.
> > > 
> > >  
> > > 
> > > Except a new file extension SHOULD be used.
> > > 
> > > Suggest: .yif == YANG Instance File
> > > 
> > >  
> > > 
> > > Obviously it would be a horrible idea to use .yang since that 
> > > extension
> > > 
> > > is already used to identify a YANG schema file.
> > > 
> > > BALAZS: The leaf-list lists not the instance data files but the
> > > content defining YANG modules, so IMO “.yang” is an appropriate
> > > extension. It is really a YANG schema file we are listing.
> > 
> > No, you are not listing a file name, you are listing the name and,
> > optionally, the revision of a YANG *module*.  It can internally be
> > stored as a .yang file a .yin file, or as a blob in a database.
> > 
> > Hence, we should not have the ".yang" suffix here.
> > BALAZS2:
> > OK, I will add the '.yin' possibility.
> 
> IMO this is even worse.  Which suffix should I use?  What difference
> does it make?
> 
> > I would like to keep the file extension because 
> > ietf-yang-t...@2015-12-07.yang looks more familiar
> 
> I think it is a bad idea to use something that looks familiar but
> change the meaning of it.  It is *not* a filename, it is a pair
> modulename + optional revision; an identifier for the module.
> 
> , will be easier to understand, than just
> > ietf-yang-types@2019-12-07
> > IMHO in practice systems might very well use it for file lookup.
> 
> But if I use this for file lookup, and I use YIN, and I try to use an
> instance file that lists the modules as ".yang", this won't work.
> 
> 
> Perhaps solve this by changing the leaf-list into:
> 
>   container inline-modules {
> list module {
>   key name;
>   leaf name { ... }
>   leaf revision { ... }
> }
>   }
> 
> /martin
> 
> BALAZS3: People explicitly asked for a short, simple solution, so
> reusing the well-known module-file-naming format seemed logical, and
> nobody misunderstood it till now.
> I would really like to avoid creating a list with 2 separate leaf's:
> longer, more complex. It goes against the express wishes of other
> group members.
> If you prefer we can drop the file extension.

Yes I think this is better.

> IMHO it will look strange.

Perhaps this document will set the standard for future references to
modules, so that this short-hand notation is used in more places,
rather than separate name / revision leafs...

BTW, you mentioned in your presentation of
draft-ietf-netconf-notification-capabilities that this doc will be
impacted by changes in draft-ietf-netmod-yang-instance-file-format.  I
think that this is ok and we continue the process for this document.
The RFC editor won't publish it until instance-file-format is done, so
there is time to fix the examples.


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

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Hi,

Balázs Lengyel  wrote:
> See below BALAZS2.
> -Original Message-
> From: Martin Bjorklund  
> Sent: 2019. november 7., csütörtök 16:17
> To: Balázs Lengyel 
> Cc: a...@yumaworks.com; netmod@ietf.org
> Subject: Re: [netmod] comments on 
> draft-ietf-netmod-yang-instance-file-format-04
> 
> Balázs Lengyel  wrote:
> > See below!Balazs
> > 
> >  
> > 
> > From: netmod  On Behalf Of Andy Bierman
> > Sent: 2019. október 10., csütörtök 17:34
> > To: Martin Bjorklund 
> > Cc: NetMod WG 
> > Subject: Re: [netmod] comments on 
> > draft-ietf-netmod-yang-instance-file-format-04
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  > <mailto:m...@tail-f.com> > wrote:
> > 
> > 
> >   o  leaf-list module
> > 
> > The type of this leaf-list is a string with:
> > 
> >   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> > 
> > I think the revision needs to be optional, and the suffix ".yang"
> > dropped, since it doesn't add any value:
> > 
> >   pattern '.+(@\d{4}-\d{2}-\d{2})?';
> > 
> >(same for inline-spec).
> > 
> >  
> > 
> > IMO the filespec SHOULD follow the pattern in  
> > https://tools.ietf.org/html/rfc7950#section-5.2
> > 
> > BALAZS: It does follow the pattern except that I made the revision date 
> > mandatory. It is needed to properly understand the instance data.
> > 
> >  
> > 
> > Except a new file extension SHOULD be used.
> > 
> > Suggest: .yif == YANG Instance File
> > 
> >  
> > 
> > Obviously it would be a horrible idea to use .yang since that 
> > extension
> > 
> > is already used to identify a YANG schema file.
> > 
> > BALAZS: The leaf-list lists not the instance data files but the content 
> > defining YANG modules, so IMO “.yang” is an appropriate extension. It is 
> > really a YANG schema file we are listing.
> 
> No, you are not listing a file name, you are listing the name and, 
> optionally, the revision of a YANG *module*.  It can internally be stored as 
> a .yang file a .yin file, or as a blob in a database.
> 
> Hence, we should not have the ".yang" suffix here.
> BALAZS2:
> OK, I will add the '.yin' possibility.

IMO this is even worse.  Which suffix should I use?  What difference
does it make?

> I would like to keep the file extension because
> ietf-yang-t...@2015-12-07.yang
> looks more familiar

I think it is a bad idea to use something that looks familiar but
change the meaning of it.  It is *not* a filename, it is a pair
modulename + optional revision; an identifier for the module.

, will be easier to understand, than just
> ietf-yang-types@2019-12-07
> IMHO in practice systems might very well use it for file lookup.

But if I use this for file lookup, and I use YIN, and I try to use an
instance file that lists the modules as ".yang", this won't work.


Perhaps solve this by changing the leaf-list into:

  container inline-modules {
list module {
  key name;
  leaf name { ... }
  leaf revision { ... }
}
  }


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

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Nov 6, 2019 at 2:40 PM Balázs Lengyel 
> wrote:
> 
> > See below!Balazs
> >
> >
> >
> > *From:* netmod  *On Behalf Of *Andy Bierman
> > *Sent:* 2019. október 10., csütörtök 17:34
> > *To:* Martin Bjorklund 
> > *Cc:* NetMod WG 
> > *Subject:* Re: [netmod] comments on
> > draft-ietf-netmod-yang-instance-file-format-04
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  wrote:

[...]

> >   o  Data node naming.
> >
> > The current structure of the model is:
> >
> > +--rw (content-schema-spec)?
> > |  +--:(simplified-inline)
> > | +--rw module* string
> > |  +--:(inline)
> > |  |  +--rw inline-spec*string
> > |  |  +--rw inline-content-schema   
> > |  +--:(uri)
> > | +--rw schema-uri?   inet:uri
> > ...
> > +--rw content-data? 
> >
> >
> > To make the instance document more understandable, I suggest the
> > following structure, which adds a wrapping container for the
> > schema, and renames the inline and uri nodes:
> >
> > +--rw content-schema
> >+--rw (content-schema-spec)?
> >|  +--:(simplified-inline)
> >| +--rw module* string
> >|  +--:(inline)
> >|  |  +--rw inline-module*  string
> >|  |  +--rw inline-schema   
> >|  +--:(uri)
> >| +--rw same-schema-as-file?inet:uri
> > ...
> > +--rw content-data? 
> >
> >
> >
> > +1, except not in favor of so many ways to specify schema.
> >
> > That means the file reader MUST support all of them.
> >
> >
> >
> > BALAZS: All 3 formats have been explicitly requested by earlier
> > commenters. I see a rational for each:
> >
> > Simplified-inline: it is simple and usually enough
> >
> > Inline: if you need to specify not just the modules but also the supported
> > features and deviations you need this full format
> >
> > Uri: if you don’t really want to specify the content-schema in detail,
> > e.g., because you are generating many files with the same schema, all you
> > need is reference that identifies the content-schema
> >
> >
> >
> > Which one would you like to implementing? Maybe we could make the inline
> > method optional with a feature (feature if-feature),
> >
> >
> >
> 
> I will just deviate out the stuff not worth implementing. ;-)
> I prefer the schema-uri approach but simplified-inline is probably easiest
> to implement.
> 
> The schema-uri looks standard but the contents of the referenced YANG
> instance file can be
> anything (as opposed to a pre-defined YANG template like /yang-library).

Note that the name of this leaf is misleading (see my ealrier
comments).  It is really 'same-schema-as-file', which means that it
point to another YANG instance data file, which must specify its
schema in one of the three ways.  Which may be another schema-uri, but
in the end the recursion must stop and you must find a YANG instance
data file that usses 'simplified-inline' or 'inline'.

> The inline-content-schema object looks broken because a YANG file is a text
> string.

It is supposed to be data nodes for /yang-library or perhaps
/module-sets, or perhaps something else.  See the examples in section
3.2.


/martin


> How does one use anydata to encode a text string? (It must be a container
> of YANG data nodes).
> Even the YIN representation is not a set of YANG data nodes, so anydata
> encoding seems wrong.
> Including all the YANG modules in this file seems especially heavyweight.
> (I have no intention of supporting this mode.)
> 
> 
> 
> > Andy
> >
> 
> 
> 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] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Balázs Lengyel  wrote:
> See below!Balazs
> 
>  
> 
> From: netmod  On Behalf Of Andy Bierman
> Sent: 2019. október 10., csütörtök 17:34
> To: Martin Bjorklund 
> Cc: NetMod WG 
> Subject: Re: [netmod] comments on 
> draft-ietf-netmod-yang-instance-file-format-04
> 
>  
> 
>  
> 
>  
> 
> On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund  <mailto:m...@tail-f.com> > wrote:
> 
> 
>   o  leaf-list module
> 
> The type of this leaf-list is a string with:
> 
>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> 
> I think the revision needs to be optional, and the suffix ".yang"
> dropped, since it doesn't add any value:
> 
>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
> 
>(same for inline-spec).
> 
>  
> 
> IMO the filespec SHOULD follow the pattern in  
> https://tools.ietf.org/html/rfc7950#section-5.2
> 
> BALAZS: It does follow the pattern except that I made the revision date 
> mandatory. It is needed to properly understand the instance data.
> 
>  
> 
> Except a new file extension SHOULD be used.
> 
> Suggest: .yif == YANG Instance File
> 
>  
> 
> Obviously it would be a horrible idea to use .yang since that extension
> 
> is already used to identify a YANG schema file.
> 
> BALAZS: The leaf-list lists not the instance data files but the content 
> defining YANG modules, so IMO “.yang” is an appropriate extension. It is 
> really a YANG schema file we are listing.

No, you are not listing a file name, you are listing the name and,
optionally, the revision of a YANG *module*.  It can internally be
stored as a .yang file a .yin file, or as a blob in a database.

Hence, we should not have the ".yang" suffix here.


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

Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Hi,

Balázs Lengyel  wrote:
> Hello Martin,
> I will update the draft following most of your comments. See details below.
> Regards Balazs
> 
> -Original Message-
> From: netmod  On Behalf Of Martin Bjorklund
> Sent: 2019. október 10., csütörtök 14:05
> To: netmod@ietf.org
> Subject: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04
> 
> Hi,
> 
> I have some mostly cosmetic comments on this draft.
>   o  "YANG" should be spelled "YANG".  Not Yang etc.
> BALAZS: OK
>   o  "NETCONF" should be spelled "NETCONF".
> BALAZS: OK
>   o  leaf-list module
> The type of this leaf-list is a string with:
>   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
> I think the revision needs to be optional, and the suffix ".yang"
> dropped, since it doesn't add any value:
>   pattern '.+(@\d{4}-\d{2}-\d{2})?';
>(same for inline-spec).
> BALAZS: I disagree, IMHO we need the revision date. We want to know the 
> exact version the data was produced against. If the version would be 
> unknown it might become very hard to understand whether the instance 
> data is correct or not.

The point is that the revision statement is optional in YANG.  If the
module doesn't have a revision statement I can't list it here.

> 
>   o  schema-uri
> The description says:
>   A reference to another YANG instance data file.
>   This instance data file will use the same set of target
>   YANG modules, revisions, supported features and deviations
>   as the referenced YANG instance data file.
> 
>I don't understand what this means.  Does it mean that the schema
>for this document is the same as the schema defined in the
>schema-uri file, or that the schema-uri file defines the schema in
>its content-data?
> 
>I *think* it is the former.  In either case, the name of the leaf
>can perhaps be changed to reflect the semantics, rather than the
>syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
>Perhaps 'same-schema-as-file'.
> BALAZS:  OK, I changed the description hope it is easier to understand now.
> description
>   "A reference to another YANG instance data file.
>This instance data file will use the same
>content schema as the referenced file.";

Thanks, better.  Perhaps: s/will use/uses/

>   o  Data node naming.
> The current structure of the model is:
> +--rw (content-schema-spec)?
> |  +--:(simplified-inline)
> | +--rw module* string
> |  +--:(inline)
> |  |  +--rw inline-spec*string
> |  |  +--rw inline-content-schema   
> |  +--:(uri)
> | +--rw schema-uri?   inet:uri
> ...
> +--rw content-data? 
> 
> 
> To make the instance document more understandable, I suggest the
> following structure, which adds a wrapping container for the
> schema, and renames the inline and uri nodes:
> 
> +--rw content-schema
>+--rw (content-schema-spec)?
>|  +--:(simplified-inline)
>| +--rw module* string
>|  +--:(inline)
>|  |  +--rw inline-module*  string
>|  |  +--rw inline-schema   
>|  +--:(uri)
>| +--rw same-schema-as-file?inet:uri
> ...
> +--rw content-data? 
> BALAZS: OK, accepted
> 
>   o  Format the YANG module
> I suggest you run the YANG module through:
>   pyang -f yang --keep-comments --yang-line-length 69
> BALAZS: OK (I will do it, but I don't agree with a number of its formatting
> changes.
> 
>   o  3.2
> The element "" needs a namespace declaration.
> BALAZS: OK


/martin

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

[netmod] Fw: WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05

[Martin Bjorklund]

Hi Rob,

You haven't replied to my WGLC email below, and it seems the issues I
brought up are not fixed in -06.  Did you miss this email?


/martin
--- Begin Message ---
Hi,

Here is my (late) review of draft-ietf-netmod-sub-intf-vlan-model-05.

o  1

  The YANG module names are not correct; they are listed as:

  if-l3-vlan.yang - Defines the model for basic classification of
  VLAN tagged traffic to L3 transport services

  flexible-encapsulation.yang - Defines the model for flexible
  classification of Ethernet/VLAN traffic to L2 transport services

   Should be "ietf-if-l3-vlan" and "ietf-flexible-encapsulation".

   Or "ietf-if-l3-vlan" and "ietf-if-flexible-encapsulation".

   But I also wonder if these names should somehow be changed.  What
   is a "l3-vlan"?  And "flexible-encapsulation" sound a bit too
   generic.


o  1.1

  The text says:

   Sub-interface: A sub-interface is a small augmentation of a regular
   interface in the standard YANG module for Interface Management that
   represents a subset of the traffic handled by its parent interface.

  I think the augmentation is the YANG-realization of a sub-interface,
  but it is not what a sub-interface is.  Also, this definition is
  mis-leading; it doesn't mention that a sub-interface has its own
  interface type and is represented as one separate entry in the
  interface list.  I think it is better to import this term from
  draft-ietf-netmod-intf-ext-yang (section 3.6)

o  3

  The text says:

   The L3 Interface VLAN model provides appropriate leaves for
   termination of an 802.1Q VLAN tagged segment to a sub-interface based
   L3 service.

  There is a comment in the YANG model that says the same thing.

  But the YANG model itself augments not only to sub-interface-based
  interface, but also to ethernet-like interfaces.


o  YANG modules

  Both modules lack the IETF Trust Copyright statement.

  We don't list WG Chairs anymore.

  The revision statements should be on the form: "RFC : "

  Many descriptions are full sentences w/o the ending ".".

  The modules should be indented properly; a starting point can be
  pyang -f yang --yang-line-length 69


o  ietf-if-l3-vlan

  There is a comment:

/*
 * Matches a single VLAN Id, or a pair of VLAN Ids to classify
 * traffic into an L3 service.
 */

  This should be moved into a description clause.

o  ietf-if-l3-vlan / container dot1q-vlan

  The must statement has:

 count(../../if-cmn:forwarding-mode) = 0

  This can be changed to not(../../if-cmn:forwarding-mode) which is
  more direct imo.

  The must statement's description statement seems to be a
  copy-and-paste error.


o  ietf-if-l3-vlan / container dot1q-vlan

  The descriptions talk about "matching frames" and "classifying
  traffic", but it is not described anywhere how the matching and
  classifying is used.

  (also applies to ietf-flexible-encapsulation)


o  ietf-if-l3-vlan / outer-tag / second-tag

  These names are a bit inconsistent.  The description describes them
  as "outermost tag" and "second outermost tag".  Perhaps use these
  names instead?

  (same names are found in ietf-flexible-encapsulation)



o  ietf-flexible-encapsulation / all features

  The features are described as:

  "This feature indicates whether the network element supports
specifying flexible rewrite operations";

  Should this be s/whether/that ?


o  ietf-flexible-encapsulation

  There is some descriptive text in comments that should be moved to
  description statements.


o  ietf-flexible-encapsulation

  The descriptions for pop/push are a bit terse.  It seems to assume
  that readers already know what this (from somewhere) is so it
  doesn't need to be described.  If this is intended, perhaps add a
  reference to where this is described.



/martin

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

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

Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt

[Martin Bjorklund]

Qin Wu  wrote:
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> 发送时间: 2019年11月6日 3:27
> 收件人: john heasley 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-04.txt
> 
> 
> 
> Yes, I'm suggesting that this "clearing" be a requirement, even if the
> operator has the choice between clear "only the configuration" and
> "everything."  "might" -> "MUST".
> 
> The fine line between too vague and too much detail must be found. >>>
> 
> In addition,the "factory-reset" RPC MUST
> restore storage to factory condition, including
> remove log files,
> remove temporary files,
> remove certificates, keys, etc
> zero passwords,
> 
> 
> The process (SHOULD|MUST) zero/pattern-write then remove sensitive files
> such as the TLS keys, configuration stores, etc.
> 
> [Qin]: Okay, here is the my proposed change:
> OLD TEXT:
> “
> In addition, the "factory-reset" RPC might also be used to trigger
> some other restoring and resetting tasks such as files cleanup,
> restarting the node or some of the SW processes, or setting some
> security data/passwords to the default value, removing logs, removing
> any temporary data (from datastore or elsewhere) etc.  When and why
> these tasks are triggered is not the scope of this document.
> ”
> NEW TEXT:
> “
> In addition, the "factory-reset" RPC MUST restore storage to factory 
> condition,
> including remove log files, remove temporary files (from datastore or 
> elsewhere).
> It MUST also remove security credentials and restoring default security 
> settings including
> remove certificates, keys, zero passwords, etc. The process invoked by the 
> "factory-reset"
> RPC SHOULD zero/pattern-write than remove sensitive files such as the TLS 
> keys, configuration
> stores, etc. The RPC MAY also be used to trigger some other resetting tasks 
> such as restarting
> the node or some of the software processes, activating the factory-default 
> config which in turn
> enables zero touch provision (ZTP).
> ”
> If you have better text, feel free to share.

I think your previously proposed text that didn't mention ZTP was
better.  Also, "MAY also be used to" sounds like it is the client's
decision, so I suggest changing the last sentence to:

  The RPC MAY also trigger some other resetting tasks such as
  restarting the node or some of the software processes.


/martin



> 
> The RPC MAY provide an option to limit the actions to factory reset of
> the configuration.
> [Qin]: we have add  nacm:default-deny-all on RPC we proposed. Security 
> section will be enhanced
> Based on Andy’s comment in the separate email.
> 
> Strongly agree.
> 
> Kent // contributor
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Default choice case with only empty leaf - Is this allowed ?

[Martin Bjorklund]

Hi,

"Beauville, Yves (Nokia - BE/Antwerp)"  wrote:
> Hello,
> 
> In the example provided in section 7.9.3 of RFC7950, is it legal to 
> redefine the default case like below?
> 
>   container transfer {
>     choice how {
>   default manual; // redefined
>   case interval {
>     leaf interval {
>   type uint16;
>   units minutes;
>   default 30;
>     }
>   }
>   case daily {
>     leaf daily {
>   type empty;
>     }
>     leaf time-of-day {
>   type string;
>   units 24-hour-clock;
>   default "01.00";
>     }
>   }
>   case manual {
>     leaf manual {
>   type empty;
>     }
>   }
>     }
>   }

Section 7.9.3 says:

   The default case is only important when considering the "default"
   statements of nodes under the cases (i.e., default values of leafs
   and leaf-lists, and default cases of nested choices).  The default
   values and nested default cases under the default case are used if
   none of the nodes under any of the cases are present.

So, yes it is legal, but doesn't mean anything.

> What is expected to happen when an  request creates the 
> 'transfer' container without providing any data for the choice 'how'?

The behaviour is the same as if you didn't have the default statement
in the choice.

> Since an empty leaf conveys information by its presence or absence, and 
> cannot have a default value, is it correct to assume that the 'manual' 
> leaf will be present, even though it was not explicitly created by the 
>  request?

No.

> Can someone clarify?



/martin

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

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> >> First, let me demote (2) from a SHOULD to a MAY, since there is a
> >> workaround.
> >> 
> >> The thinking is that it may be common for deployments to use the same
> >> "cert-to-name" strategy everywhere (e.g., IDevID certificates), and
> >> hence there is no need to specify a "fingerprint" in order to lookup
> >> what strategy to use.  For these cases, it would be better to not
> >> specify a fingerprint at all.  If this remains "mandatory true", the
> >> best fallback would be to specify the fingerprint for the *root* CA
> >> certs spanning the end-entity certs connecting to that endpoint.
> > 
> > Are we still talking about the usage of cert-to-name in
> > ietf-netconf-server?  
> 
> ...and ietf-restconf-server, yes.
> 
> 
> 
> > If so we have (as one example):
> > 
> >  +--rw netconf-server
> > +--rw listen! {ssh-listen or tls-listen}?
> >...
> >+--rw endpoint* [name]
> >   ...
> >   +--rw (transport)
> >  ...
> >  +--:(tls) {tls-listen}?
> > +--rw tls
> >...
> >+--rw netconf-server-parameters
> >   +--rw client-identification
> >  +--rw cert-maps
> > +--rw cert-to-name* [id]
> >+--rw id   uint32
> >+--rw fingerprint  x509c2n:tls-fingerprint
> >+--rw map-type identityref
> >+--rw name string
> > 
> > [we can discuss if this is the best structure, but that's another
> > thread]
> > 
> > What would a "cert-to-name" entry mean if the fingerprint isn't
> > present?
> 
> 
> Your snippet excludes "tis-server-perameters".  Here is a more
> complete view:
> 
>   +--rw restconf-server
>  +--rw listen! {http-listen or https-listen}?
> +--rw endpoint* [name]
>+--rw name   string
>+--rw (transport)
>   +--:(http)
>   |  +--rw http
>   | ...
>   +--:(https)
>  +--rw https
> +--rw tcp-server-parameters
> |  ...
> +--rw tls-server-parameters
> |  +--rw server-identity
> |  |  ...
> |  +--rw client-authentication!
> |  |  +--rw (required-or-optional)
> |  |  |  ...
> |  |  +--rw (local-or-external)
> |  | +--:(local)
> |  | |  +--rw ca-certs!  
> |  | |  |  ...
> |  | |  +--rw client-certs!
> |  | | ...
> |  | +--:(external)
> |  |...
> |  +--rw hello-params
> |  |  ...
> +--rw http-server-parameters
> |  +--rw server-name? string
> |  +--rw protocol-versions
> |  |  +--rw protocol-version*   enumeration
> |  +--rw client-authentication!
> | ...
> +--rw restconf-server-parameters
>+--rw client-identification
>   +--rw cert-maps
>  +--rw cert-to-name* [id]
> +--rw id uint32
> +--rw fingerprint
> |   x509c2n:tls-fingerprint
> +--rw map-type   identityref
> +--rw name   string
> 
> 
> The "tls-server-parameters" container defines the certificates used to
> authenticate the client's cert.  In many deployments, regardless how
> the client cert is authenticated, the "client-identification" section
> only needs to explain extract the "name" from the cert, a fingerprint
> isn't needed to identify either the client's end-entity or some
> intermediate cert.

Ok.  To me this sounds like you need a more complex^wsophisticated
client identification mechansim than what a plain cert-to-name gives
you.  I don't think there is anything wrong with the current
cert-to-name grouping.  So let's continue this discussion in the
netconf ML, where this model is being developed.


/martin




> 
> 
> 
> 
> > 
> >> New issue.  Why isn't "list cert-to-name" order-by user given:
> >> 
> >>  "The id specifies the order in which the entries in the
> >>   cert-to-name list are searched.  Entries with lower
> >>   numbers are searched first.";
> >> 
> >> I suspect that this is for SNMP compatibility, but then your earlier
> >> response on this thread said regarding "mandatory true" and empty
> >> fingerprint values suggested that more appropriate YANG-isms 

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> Hi Martin,
> 
> > I have now filed an errata for this issue.
> 
> Ack.
> 
> > However, I remember that we had a discussion on whether we should
> > accept erratas on YANG modules or not.  The YANG module exist in
> > various places outside of the RFC, such as the IANA site, and it won't
> > be corrected there.
> 
> Yes, two thoughts:
>- this erratum could marked as document update required.
>- we may want to publish a -biz soon
> 
> 
> 
> >> In that case, there might be two issues:
> >> 
> >>1) the description statement excluding CA certs (mentioned before)
> >>2) `mandatory true` should be `mandatory false` ?
> > 
> > I don't understand 2), can you elaborate?
> 
> 
> First, let me demote (2) from a SHOULD to a MAY, since there is a
> workaround.
> 
> The thinking is that it may be common for deployments to use the same
> "cert-to-name" strategy everywhere (e.g., IDevID certificates), and
> hence there is no need to specify a "fingerprint" in order to lookup
> what strategy to use.  For these cases, it would be better to not
> specify a fingerprint at all.  If this remains "mandatory true", the
> best fallback would be to specify the fingerprint for the *root* CA
> certs spanning the end-entity certs connecting to that endpoint.

Are we still talking about the usage of cert-to-name in
ietf-netconf-server?  If so we have (as one example):

  +--rw netconf-server
 +--rw listen! {ssh-listen or tls-listen}?
...
+--rw endpoint* [name]
   ...
   +--rw (transport)
  ...
  +--:(tls) {tls-listen}?
 +--rw tls
...
+--rw netconf-server-parameters
   +--rw client-identification
  +--rw cert-maps
 +--rw cert-to-name* [id]
+--rw id   uint32
+--rw fingerprint  x509c2n:tls-fingerprint
+--rw map-type identityref
+--rw name string

[we can discuss if this is the best structure, but that's another
thread]

What would a "cert-to-name" entry mean if the fingerprint isn't present?

> New issue.  Why isn't "list cert-to-name" order-by user as opposed to:
> 
>   "The id specifies the order in which the entries in the
>cert-to-name list are searched.  Entries with lower
>numbers are searched first.";
> 
> I suspect that this is for SNMP compatibility, but then your earlier
> response on this thread said regarding "mandatory true" and empty
> fingerprint values suggested that more appropriate YANG-isms should be
> used, in general.  "ordered-by user" vs "ordered by id" seems like
> such a case.

Yes I agree.  I don't recall but I also suspect the motivation was
simple mapping to the MIB.  (mapping a zero-length string to/from an
optional leaf is straightforward).


/martin

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

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Randy Presuhn  wrote:
> Hi -
> 
> On 10/28/2019 2:22 AM, Martin Bjorklund wrote:
> 
> > No, in many SMIv2 objects, a zero-length value is used for optional
> > nodes (due to the way the protocol (SNMP) works).
> 
> This comes as a complete surprise to me.  References?

I don't have any references at hand, so let me re-phrase:

  No, in many SMIv2 objects, a zero-length value is used for optional
  nodes.

(where "optional" means optional to set, not optional to implement)



/martin

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

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Hi,


Kent Watsen  wrote:
> Hi Martin,
> 
> 
> > I'll check with my co-author and get back.
> 
> Thanks.

I have now filed an errata for this issue.

However, I remember that we had a discussion on whether we should
accept erratas on YANG modules or not.  The YANG module exist in
various places outside of the RFC, such as the IANA site, and it won't
be corrected there.

> > No, in many SMIv2 objects, a zero-length value is used for optional
> > nodes (due to the way the protocol (SNMP) works).  In YANG we don't do
> > this, since the protocls (NETCONF etc) can handle non-existing
> > optional leafs.
> 
> In that case, there might be two issues:
> 
>   1) the description statement excluding CA certs (mentioned before)
>   2) `mandatory true` should be `mandatory false` ?

I don't understand 2), can you elaborate?


/martin

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

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> 
> > On Oct 23, 2019, at 4:18 AM, Martin Bjorklund  wrote:
> > 
> > Hi,
> > 
> > Since this is a problem with ietf-x509-cert-to-name I reply to this
> > question here, rather than buried in a reply to another issue for
> > another document ;-)
> > 
> > Kent Watsen  wrote:
> >> Separately, I just noticed an issue with the
> >> `ietf-[net/rest]conf-server` modules using x509c2n:cert-to-name.
> >> 
> >> ```
> >> leaf fingerprint {
> >>   type x509c2n:tls-fingerprint;
> >>   mandatory true;
> >>   description
> >> "Specifies a value with which the fingerprint of the
> >>  full certificate presented by the peer is compared.  If
> >>  the fingerprint of the full certificate presented by the
> >>  peer does not match the fingerprint configured, then the
> >>  entry is skipped, and the search for a match continues.";
> >> ```
> >> 
> >> This definition seems to exclude authenticating client certificates
> >> via a trust anchor certificate as, if one can configure a fingerprint,
> >> then one could also configure the whole certificate (e.g.,
> >> `tls-server-parameters/client-authentication/client-certs`), thus
> >> obviating the need for
> >> `tls-server-parameters/client-authentication/ca-certs`.
> > 
> > [...]
> > 
> >> A better definition (I think) would've been:
> >> 
> >> ```
> >> OLD: full certificate presented by the peer 
> >> NEW: full certificate of the certificate used to authenticate the
> >> certificate presented by the peer, which MAY be the peer's end-entity
> >> certificate.
> >> ```
> > 
> > Hmm, I think you found an inconsisteny in this module.  Note that the
> > description of the list itself has:
> > 
> > The cert-to-name entry's fingerprint
> > determines whether the list entry is a match:
> > 
> > 1) If the cert-to-name list entry's fingerprint value
> >matches that of the presented certificate, then consider
> >the list entry a successful match.
> > 
> > 2) If the cert-to-name list entry's fingerprint value
> >matches that of a locally held copy of a trusted CA
> >certificate, and that CA certificate was part of the CA
> >certificate chain to the presented certificate, then
> >consider the list entry a successful match.
> > 
> > Also note:
> > 
> >Security administrators are encouraged to make use of
> >certificates with subjectAltName fields that can be mapped to
> >names so that a single root CA certificate can allow all
> >child certificates' subjectAltName fields to map directly to
> >a name via a 1:1 transformation.
> > 
> > So I think this is a bug in the description of "leaf fingerprint".
> 
> I'd rather it be that than a bug in "list cert-to-name".  Would an
> erratum be appropriate here?  While the fix effectively changes the
> meaning of "fingerprint", it only would do so in order to resolve the
> inconsistency, and thus seems necessary.
> 
> Martin, if you agree, would to like to propose text or go straight to
> submitting an erratum?

I'll check with my co-author and get back.

> >> I note that `fingerprint` may be 0 characters in length, which is what
> >> netconf/restconf servers wanting to support authenticating clients via
> >> a trust anchor will need to do in their configurations.  I'll update
> >> the examples in those drafts to include an empty `fingerprint` node.
> > 
> > But 0-length fingerprint won't match anything, which means you won't
> > get a user name and the client can't be authenticated, and the session
> > dropped.
> 
> Actually, I thought that this was on purpose, as SnmpTLSFingerprint in
> RFC 6353 (referenced by "typedef tls-fingerprint" says (note the 3rd
> paragraph):
> 
> SnmpTLSFingerprint ::= TEXTUAL-CONVENTION
> DISPLAY-HINT "1x:1x"
> STATUS   current
> DESCRIPTION
>"A fingerprint value that can be used to uniquely reference
>other data of potentially arbitrary length.
> 
>An SnmpTLSFingerprint value is composed of a 1-octet hashing
>algorithm identifier followed by the fingerprint value.  The
>octet value encoded is taken from the IANA TLS HashAlgorithm
>   

Re: [netmod] Effect of ordered by user on state(config false) list

[Martin Bjorklund]

Hi,

Tarek Saad  wrote:
> Hi,
> 
> We are wondering if “ordered by user” has any effect on a (config
> false)/state list?
> Given RFC6020 specifies “ordered by system” as the default order, does
> this mean it is the order assumed for a state list with “ordered by
> user”?

There is no effect "on the wire"; the entries are sent in the order
determined by the server in both cases.  But it informs to the
consumer of the data model that the order of the list entries carries
some meaning.


/martin

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

[netmod] x509c2n:cert-to-name problem [WAS: [netconf-wg/https-notif] What is the user-id of the entity sending the notification? (#3)]

[Martin Bjorklund]

Hi,

Since this is a problem with ietf-x509-cert-to-name I reply to this
question here, rather than buried in a reply to another issue for
another document ;-)

Kent Watsen  wrote:
> Separately, I just noticed an issue with the
> `ietf-[net/rest]conf-server` modules using x509c2n:cert-to-name.
> 
> ```
>  leaf fingerprint {
>type x509c2n:tls-fingerprint;
>mandatory true;
>description
>  "Specifies a value with which the fingerprint of the
>   full certificate presented by the peer is compared.  If
>   the fingerprint of the full certificate presented by the
>   peer does not match the fingerprint configured, then the
>   entry is skipped, and the search for a match continues.";
> ```
> 
> This definition seems to exclude authenticating client certificates
> via a trust anchor certificate as, if one can configure a fingerprint,
> then one could also configure the whole certificate (e.g.,
> `tls-server-parameters/client-authentication/client-certs`), thus
> obviating the need for
> `tls-server-parameters/client-authentication/ca-certs`.

[...]

> A better definition (I think) would've been:
> 
> ```
> OLD: full certificate presented by the peer 
> NEW: full certificate of the certificate used to authenticate the
> certificate presented by the peer, which MAY be the peer's end-entity
> certificate.
> ```

Hmm, I think you found an inconsisteny in this module.  Note that the
description of the list itself has:

 The cert-to-name entry's fingerprint
 determines whether the list entry is a match:

 1) If the cert-to-name list entry's fingerprint value
matches that of the presented certificate, then consider
the list entry a successful match.

 2) If the cert-to-name list entry's fingerprint value
matches that of a locally held copy of a trusted CA
certificate, and that CA certificate was part of the CA
certificate chain to the presented certificate, then
consider the list entry a successful match.

Also note:

Security administrators are encouraged to make use of
certificates with subjectAltName fields that can be mapped to
names so that a single root CA certificate can allow all
child certificates' subjectAltName fields to map directly to
a name via a 1:1 transformation.

So I think this is a bug in the description of "leaf fingerprint".


> I note that `fingerprint` may be 0 characters in length, which is what
> netconf/restconf servers wanting to support authenticating clients via
> a trust anchor will need to do in their configurations.  I'll update
> the examples in those drafts to include an empty `fingerprint` node.

But 0-length fingerprint won't match anything, which means you won't
get a user name and the client can't be authenticated, and the session
dropped.


/martin

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

Re: [netmod] [Technical Errata Reported] RFC7950 (5879)

[Martin Bjorklund]

Hi,

The problem is that it is not clear that we can use this new
definition with the rest of the text in the RFC that uses this term.
For example, section 7.1.5 talks about "the imported module's schema
tree", and this doesn't really work if the schema tree is not tied to
a module.

Also the proposed definition is recursive since it is defined in
terms of "schema node", and a "schema node" is already defined as "a
node in the schema tree".

So it probably makes sense to look at this definition (and the text
and other definitions) if we do a document update, but as it is
currently written I think it should be rejected.


/martin



RFC Errata System  wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5879
> 
> --
> Type: Technical
> Reported by: Ladislav Lhotka 
> 
> Section: 3
> 
> Original Text
> -
> o  schema tree: The definition hierarchy specified within a module.
> 
> 
> Corrected Text
> --
> o  schema tree: The hierarchy of schema nodes defined in the set of all 
> modules 
>implemented by a server, as specified in the YANG library data [RFC7895].
> 
> 
> 
> Notes
> -
> The original definition of the term has two problems:
> 
> 1. Schema tree is not limited to a single module. Some YANG constructs, such 
> as augment and leafref type, may refer to a schema node that is defined in 
> another module.
> 
> 2. Apart from schema nodes, YANG modules contain definitions that do not 
> contribute to the schema tree: groupings, typedefs, identities etc.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 

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

Re: [netmod] A reworking of RFC8343

[Martin Bjorklund]

tom petch  wrote:
> Martin
> 
> I am wondering how much you know about a module that says
>   WG List:  <mailto:netmod@ietf.org>
>   Editor:   Martin Bjorklund
> <mailto:m...@tail-f.com>";
> 
> The module is
>   module ietf-ucpe-interfaces {
> in
>   draft-shytyi-opsawg-vysm-04

Haha!  I don't know anything about it.

> The author appears to have taken RFC8343, changed the module and prefix
> name (but not the Editor) and added, at the top level,
>augment "/ietf-vysm:ucpe" {
> (ucpe also appears in this I-D).  I have commented on the OPSAWG list
> about this approach not being one I have seen before and the response is
> that the yang validator is fine with it.
> 
> Thoughts?

Clearly unacceptable.  Unclear why a ucpe can't implement
ietf-interfaces from 8343.

> An earlier version of this module had
>   import tailf-ncs
> which also had me wondering.

Hmm.



/martin

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

Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

"Alexey Melnikov"  wrote:
> Hi Martin,
> 
> On Mon, Oct 21, 2019, at 8:33 AM, Martin Bjorklund wrote:
> 
> > > This is a fine document.
> > > 
> > > Can you show and example similar to what in A.3 with 2 addressbook
> > > entries?
> > 
> > The example isn't really written to handle more than one address
> > book.  The structure defines one single address book.  But perhaps I
> > misunderstood your question?
> 
> The example in A.1 contains "list address". Can this list contain more
> than one element in it?

Aha, I see.  Yes it can.

> If yes, can you provide an example with
> multiple elements?

In XML it would be:

  
 
   Flintstone
   Fred
   301 Cobblestone Way
   Bedrock
   70777
 
 
   Root
   Charlie
   4711 Cobblestone Way
   Bedrock
   70777
 
   


> I am trying to figure out how multiple elements
> would be represented in XML (In JSON it seems more obvious to me). My
> YANG knowledge is limited, so I don't know whether or not there is an
> issue. But I couldn't tell until I see an example.

Also see section 4.2.2.4 in RFC 7950 for another example of multiple
list entries.



/martin

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

Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

[Martin Bjorklund]

Jernej Tuljak  wrote:
> Should I clarify my question?
> 
> Jernej
> 
> On 10/10/2019 10:36, Jernej Tuljak wrote:
> > Hi,
> >
> > there is at least one YANG 1.0 standard module that imports and uses
> > groupings from a YANG 1.1 standard module and at least one such
> > grouping contains must/when statements referencing XPath functions
> > that are not available in 1.0 XPath context.
> >
> > The modules I'm referring to are part of RFC8533 [1] and RFC8532
> > [2]. ietf-connectionless-oam-methods (a 1.0 module) uses
> > cl-oam:tp-address from ietf-connectionless-oam (a 1.1 module), which
> > calls "derived-from-or-self" in a when expression of a used
> > node. These RFCs were published in April.
> >
> > Our tools complain about "derived-from-or-self" not being defined in
> > ietf-connectionless-oam-methods's XPath context:
> >
> > [Error];
> > ietf-connectionless-oam-methods@2019-04-16:/cloam-methods:continuity-check/cloam-methods:input/cloam-methods:destination-tp/cloam-methods:mac-address/cloam-methods:when;
> > XPath function "derived-from-or-self" is not defined in the XPath
> > context
> >
> > Is this correct? Or are XPath functions expected to be resolved
> > statically, like types?

I don't think it is correct to reject this construct.  The definition
is done in a 1.1 module and can only be implemented in a server that
supports 1.1.

It seems a bit odd that "ietf-connectionless-oam-methods" is defined
in YANG 1.0 though, but that's a different issue...


/martin

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

Re: [netmod] leafref and identityref

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Mon, 2019-10-21 at 13:40 +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > Ladislav Lhotka  wrote:
> > > Hi,
> > > 
> > > consider the following situation:
> > > 
> > > module A {
> > >   ...
> > >   prefix a
> > >   identity X;
> > >   leaf foo {
> > > type identityref {
> > >   base X;
> > > }
> > >   }
> > > }
> > > 
> > > module B {
> > >   ...
> > >   import A {
> > > prefix a;
> > >   }
> > >   leaf fooref {
> > > type leafref {
> > >   path "/a:foo";
> > > }
> > >   }
> > > }
> > > 
> > > What is now a correct lexical form of fooref's value? Could it be just
> > > 'X', or is the prefix required, i.e. 'a:X'?
> > > 
> > > This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am
> > > inclined to require the prefix.
> > 
> > 9.10.3 says:
> > 
> >If the prefix is not
> >present, the namespace of the identityref is the default namespace
> >in effect on the element that contains the identityref value.
> > 
> > 
> > so the interpretation of a missing prefix in "fooref" is that the
> > identity is defined in module B.
> > 
> > (a missing prefix in "foo" means that the identity is defined in
> > module A)
> 
> To be more specific, here is an example instance:
> 
> X
> X
> 
> It can be argued that this is correct because (sec. 9.9.4):
> 
>A leafref value is lexically represented the same way as the leaf it
>references represents its value.
> 
> That is, the same lexical representation is assumed, which is exactly what we
> have in the example.

It doesn't say that the lexical value is exactly the same, but
"represented the same way" - so when the lexical representation is
context dependent we have this situation.

> It seems that we agree that it is incorrect, but then sec. 9.9.4 should be
> clarified.




/martin

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

Re: [netmod] leafref and identityref

[Martin Bjorklund]

Hi,

Ladislav Lhotka  wrote:
> Hi,
> 
> consider the following situation:
> 
> module A {
>   ...
>   prefix a
>   identity X;
>   leaf foo {
> type identityref {
>   base X;
> }
>   }
> }
> 
> module B {
>   ...
>   import A {
> prefix a;
>   }
>   leaf fooref {
> type leafref {
>   path "/a:foo";
> }
>   }
> }
> 
> What is now a correct lexical form of fooref's value? Could it be just
> 'X', or is the prefix required, i.e. 'a:X'?
> 
> This is not very clear from RFC 7950 (sections 9.9.4 and 9.10.3). I am
> inclined to require the prefix.

9.10.3 says:

   If the prefix is not
   present, the namespace of the identityref is the default namespace
   in effect on the element that contains the identityref value.


so the interpretation of a missing prefix in "fooref" is that the
identity is defined in module B.

(a missing prefix in "foo" means that the identity is defined in
module A)



/martin

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

Re: [netmod] Genart telechat review of draft-ietf-netmod-yang-data-ext-04

[Martin Bjorklund]

Hi,

Brian Carpenter via Datatracker  wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Nits
> 
> Gen-ART Last Call & telechat review of draft-ietf-netmod-yang-data-ext-04
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-netmod-yang-data-ext-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2019-10-20
> IETF LC End Date: TBD
> IESG Telechat date: 2019-10-31
> 
> Summary: Ready with nits
> 
> 
> Comments: 
> -
> 
> This was accidentally put on the IESG agenda without an IETF Last Call,
> so this review serves both purposes.
> 
> The draft seems very clear and I have no technical comments.
> 
> Nits:
> -
> 
> > Updates: 8340 (if approved)
> > Intended status: Standards Track
> 
> RFC 8340 is a BCP, so can this really be Standards Track?
> Shouldn't it also be BCP, extending BCP 215? It's tricky,
> because it also effectively extends RFC 8040, which is
> Standards Track rather than BCP. Sadly it doesn't seem that
> a document can be both BCP and Standards Track.

Hmm, the main contribution in this document (the "structure"
extension), is not suitable as a BCP.  It is really just section 3
that updates 8340.  I don't know to to resolve this, and will look at
the document shepard for guidance!

> Also, this draft says:
> 
> >   The "yang-data" extension from [RFC8040] has been copied here,
> >   renamed to "structure", and updated to be more flexible.
> 
> That reads as if RFC 8040 is also updated, and it leaves the
> status of "yang-data" unclear. Is it now deprecated? Perhaps the
> sentence would be clearer like this:
> 
>   This document defines a new YANG extension statement called
>   "structure", which is similar to but more flexible than the
>   "yang-data" extension from [RFC8040].


Thank you, this is better!


/martin

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

Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

Alexey Melnikov via Datatracker  wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-netmod-yang-data-ext-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/
> 
> 
> 
> --
> COMMENT:
> --
> 
> This is a fine document.
> 
> Can you show and example similar to what in A.3 with 2 addressbook entries?

The example isn't really written to handle more than one address
book.  The structure defines one single address book.  But perhaps I
misunderstood your question?


/martin

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

Re: [netmod] Barry Leiba's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

[Martin Bjorklund]

Hi,

Barry Leiba via Datatracker  wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-netmod-yang-data-ext-04: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/
> 
> 
> 
> --
> COMMENT:
> --
> 
> A fine extension.  Just three editorial nits:
> 
> -- Section 1 —
> 
>There is no
>assumption that a YANG data structure can only be used as a top-level
>abstraction, instead of nested within some other data structure.
> 
> It’s a little odd to use “instead of” after “there is no assumption”; I can’t
> explain it fully, but it feels odd to this native English speaker.  I suggest
> this:
> 
> NEW
>There is no
>assumption that a YANG data structure can only be used as a top-level
>abstraction, and it may also be nested within some other data structure.
> END
> 
>similar to the existing YANG "augment" statement.
> 
> Make it “similarly”.
> 
> — Section 1.1.1 —
> 
>The following terms are defined in the Network Management Datastore
>Architecture (NMDA) [RFC8342].  and are not redefined here:
> 
> The period after the citation should be a comma.

Thanks for these suggestions, I have applied them all.


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

Re: [netmod] IANA registries

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> some of you have probably seen the discussions around
> 
> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
> 
> We proposed to adopt it as a work item in the DNSOP WG, but despite
> some support this is probably not going to happen. The substantial
> objections are:
> 
> 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
> because future implementors will use the module from that RFC and implement
> registry entries that may have been deprecated in the mean time. 
> 
> 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC
> 8126) differs from the definition in RFC 7950.
> 
> I already raised #2 in this mailing list, and I think it should be
> addressed in the next version of YANG.
> 
> Regarding #1, I tried to explain that the RFC is only intended to contain an
> initial revision of the corresponding YANG module, but it didn't help. One
> suggestion was to avoid representing the registries as enumerations or sets of
> identities, and use only integers.

That's a bit odd.  But perhaps it can be solved by actually not
filling in all values in this module, but rather make it a template
and instruct IANA to fill it in with the contents of the registry at
the time of publication.



/martin


> I wonder if we can come up with a reasonable solution. Without
> having the important registries as YANG modules, it is difficult to
> work on other modules - for DNS, in this case, but it could apply to
> other areas, too.
> 
> Thanks, Lada
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] comments on draft-ietf-netmod-yang-instance-file-format-04

[Martin Bjorklund]

Hi,

I have some mostly cosmetic comments on this draft.

  o  "YANG" should be spelled "YANG".  Not Yang etc.


  o  "NETCONF" should be spelled "NETCONF".


  o  leaf-list module

The type of this leaf-list is a string with:

  pattern '.+@\d{4}-\d{2}-\d{2}\.yang';

I think the revision needs to be optional, and the suffix ".yang"
dropped, since it doesn't add any value:

  pattern '.+(@\d{4}-\d{2}-\d{2})?';

   (same for inline-spec).


  o  schema-uri

The description says:

  A reference to another YANG instance data file.
  This instance data file will use the same set of target
  YANG modules, revisions, supported features and deviations
  as the referenced YANG instance data file.

   I don't understand what this means.  Does it mean that the schema
   for this document is the same as the schema defined in the
   schema-uri file, or that the schema-uri file defines the schema in
   its content-data?

   I *think* it is the former.  In either case, the name of the leaf
   can perhaps be changed to reflect the semantics, rather than the
   syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
   Perhaps 'same-schema-as-file'.


  o  Data node naming.

The current structure of the model is:

+--rw (content-schema-spec)?
|  +--:(simplified-inline)
| +--rw module* string
|  +--:(inline)
|  |  +--rw inline-spec*string
|  |  +--rw inline-content-schema   
|  +--:(uri)
| +--rw schema-uri?   inet:uri
...
+--rw content-data? 


To make the instance document more understandable, I suggest the
following structure, which adds a wrapping container for the
schema, and renames the inline and uri nodes:

+--rw content-schema
   +--rw (content-schema-spec)?
   |  +--:(simplified-inline)
   | +--rw module* string
   |  +--:(inline)
   |  |  +--rw inline-module*  string
   |  |  +--rw inline-schema   
   |  +--:(uri)
   | +--rw same-schema-as-file?inet:uri
...
+--rw content-data? 


  o  Format the YANG module

I suggest you run the YANG module through:

  pyang -f yang --keep-comments --yang-line-length 69

  o  3.2

The element "" needs a namespace declaration.



/martin





/martin

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

Re: [netmod] ?==?utf-8?q? PYANG refine fault ?

[Martin Bjorklund]

Michal Vaško  wrote:
> Hi,
> 
> yanglint actually validates the module just fine (at least the latest
> version) once the grammar errors are fixed. Namely, the spaces before
> ";" on lines 191 and 199 are removed.

These are not errors.  You are allowed to have any number of
whitespace (and comments) before the ';'.


/martin


> 
> Regards,
> Michal
> 
> On Wednesday, October 9, 2019 23:13 CEST, Mahesh Jethanandani
>  wrote:
>  
> > Hi Balasz,
> > 
> > In general support of unions is poor across the tool sets that I have
> > used. It does not help that yanglint gives a completely different
> > error.
> > 
> > I did try yanger, and that did not result in an error.
> > 
> > The other option is to move the default statement inside the grouping,
> > which seems to make the error go away.
> > 
> > Cheers.
> > 
> > > On Oct 9, 2019, at 8:01 AM, Balázs Lengyel
> > >  wrote:
> > > 
> > > Hello,
> > > I was trying to validate the attached model. However pyang keeps
> > > complaining about refining a default for a leaf-list:
> > >  
> > > ietf-notification-capabilit...@2019-10-10.yang
> > > :184: error:
> > > "leaf-list" node
> > > "ietf-notification-capabilities::supported-excluded-change-type"
> > > cannot be refined with "default"
> > >  
> > > Why? According to https://tools.ietf.org/html/rfc7950#section-7.13.2
> > >  “A leaf-list node
> > > may get a set of default values ...”
> > > .
> > > Confdc accepts this. Could this be a bug in pyang ?
> > > Regards Balazs
> > >  
> > > -- 
> > > Balazs Lengyel Senior Specialist Ericsson Hungary Ltd.
> > > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> > > 
> > >  
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org 
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > Mahesh Jethanandani
> > mjethanand...@gmail.com
> > 
> > 
> > 
>  
>  
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] PYANG refine fault ?

[Martin Bjorklund]

Hi,

Balázs Lengyel  wrote:
> Hello,
> 
> I was trying to validate the attached model. However pyang keeps complaining
> about refining a default for a leaf-list:
> 
>  
> 
> ietf-notification-capabilit...@2019-10-10.yang:184: error: "leaf-list" node
> "ietf-notification-capabilities::supported-excluded-change-type" cannot be
> refined with "default"
> 
>  
> 
> Why? According to https://tools.ietf.org/html/rfc7950#section-7.13.2 “A
> leaf-list node may get a set of default values ...” 
> 
> ..
> 
> Confdc accepts this. Could this be a bug in pyang ?

Yes, now fixed.


/martin

  
> 
> Regards Balazs
> 
>  
> 
> -- 
> 
> Balazs LengyelSenior Specialist
> Ericsson Hungary Ltd. 
> 
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> 
>  
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] References to the "tags" typedef

[Martin Bjorklund]

"Rob Wilton (rwilton)"  wrote:
> [Copying Balazs because this discussion is moving to instance-data
> document schema definitions.]
> 
> > -Original Message-
> > From: Schönwälder, Jürgen 
> > Sent: 04 October 2019 10:36
> > To: Rob Wilton (rwilton) 
> > Cc: Christian Hopps ; Mahesh Jethanandani
> > ; netmod@ietf.org
> > Subject: Re: [netmod] References to the "tags" typedef
> > 
> > On Fri, Oct 04, 2019 at 08:17:33AM +, Rob Wilton (rwilton) wrote:
> > >
> > > To use the "tags:tag" typedef, ietf-yang-package had an import on
> > > "ietf-
> > module-tags" which both defines a tags type and also a "module-tags"
> > container as well.  I want the typedef, but not the container, because
> > I
> > don't want the schema for the package file to be:
> > >   +--ro yang-package  <-- I do want this
> > >   |  +--ro name  yang:yang-identifier
> > >   |  ...
> > >   +--ro module-tags   <--  I don't want this
> > >  +- ...
> > >
> > 
> > Isn't import-only-module in YANG library take care of this?
> [RW] 
> Yes, that is one solution.
> 
> The instance data document (probably in JSON, but I've given an XML
> snippet below) could use the "inline-spec" for specifying the schema.
> 
> But this means that every package instance file, needs to have some
> boilerplate like this before the actual package definition.:
> 
> 
>  "urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
>   some-yang-package
>   ietf-yang-libr...@2019-01-04.yang
>   
> 
>   
> all
> 
>   ietf-yang-package
>   2019-09-11
> 
> 
>   ietf-yang-package-types
>   -xx-xx
> 
> 
>   ietf-module-tags
>   -xx-xx
> 
> 
>   ietf-yang-revisions
>   -xx-xx
> 
> 
>   ietf-yang-structure-ext
>   -xx-xx
> 
> 
>   ietf-yang-types
>   -xx-xx
> 
> 
>   ietf-yang-library
>   -xx-xx
> 
> 
>   ietf-inet-types
>   -xx-xx
> 
>   
> 
>   
>   
>  // Actual package information goes here.
>   
> 
> 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/?include_text=1
> 
> The YANG instance data draft provides some other choices:
> (1) (External Method) Don't define the schema, just assume that
> clients know what it will be for YANG packages.  E.g. it would be
> specified in the YANG packages RFC.

I prefer this solution for the packages document.

> (2) (URI method) Put the schema in a separate instance data document
> and reference that.  This could be defined in the YANG packages RFC,
> but it might open the question of what URI can you use to retrieve it.
> (3) Simplified inline schema.
> 
> It is the third one that I would ideally like to use.

Ugh, I haven't paid enough attention to the instance data
document... I will comment on this design in a separate email.

> Here, the package data would like something like this (sorry, in JSON
> this time):
> 
>   "ietf-yang-instance-data:instance-data-set": {
> "name": "example-ietf-network-device-pkg",
> "module": [ "ietf-yang-pack...@2019-09-11.yang" ],
> "description": "YANG package definition",
> "content-data": {
>   "ietf-yang-package:yang-package": {
> "name": "example-ietf-network-device-pkg",
> // Actual package information goes here.
>   }
> }
>   }
> 
> Here, the schema is defined by the "module" line
> "ietf-yang-pack...@2019-09-11.yang".  I think that there are some
> details to work out, but I think that the import dependencies for
> "ietf-yang-package.yang" could be automatically resolved as
> import-only YANG modules.  I have also tried to minimize the required
> imports (e.g. don't import YANG library, perhaps don't import from
> module-tags).

You shouldn't have to do that.  You should use the appriopriate
types.

> In terms of typedefs, are two typedefs equivalent if they have exactly
> the same definition in two different modules?  Or does the fact that
> they are named given them a slightly different meaning?

By reusing appriopriate typedefs you get clearer semantics.  In the
extreme case everyting is just strings with some descripton statements
(you might think that this is absurd, but this approach has been taken
by some data model designers (not necessarily yang) ...)


/martin

> 
> Thanks,
> Rob
> 
> 
> > 
> > /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

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

[Martin Bjorklund]

Hi,

Thank you for your reviewe.  Comments inline.

Qin Wu  wrote:
> Hi, Auhors:
> I have read the latest version and have the following comments:
> 
> 1.  Try to understand the difference between anydata and YANG data
> structure extension? Is YANG data structure extension targeted to
> specify the format which can not be represented by anydata?
> 
> When will we use anydata? When will we use YANG data structure
> extension, would this be clarified in the introduction section.

The Introduction says:

   There is a need for standard mechanisms to allow the definition of
   abstract data that is not intended to be implemented as configuration
   or operational state.

(Also note that 'anydata' doesn't define what goes into the anydata
node; a sx:structure has well-defined content)

> 2.  Why is YANG data structure extension not part of RFC7950 or
> RFC7950bis? It seems two top level YANG statements are introduced in
> this draft.

Well, we can't change history and include it in 7950, and there is no
7950bis being worked on.  If/when that happens, this statement can
possibly go into that document.  But we don't want to wait for that to
happen.

> 3.  In the introduction section, when we say there is no assumption
> that a YANG data structure can only be used as a top-level
> abstraction, instead of nested within some other data structure. I am
> wondering what other data structure looks like? Is other data
> structure specified by YANG data structure defined in this draft or
> data structure defined by anydata?

We don't make any assumptions on how this is done.  The new statement
simply defines a structure; how it is used is up to the designer.

> If the example is A.5, please add reference to Appendix A.5 in the
> introduction section.
> 
> 4.  When we say YANG data structure extension is only valid as a
> top-level statement, does this conflict with YANG data structure can
> be nested within some other data structure?

No.  This just refers to how the grammar is done - sx:structure can
only appear on the top-level in a module or submodule.

> 5.  Why augment-structure is also only valid as a top-level statement,
> why augment-structure is not substatement of YANG data structure?

I don't think augment-structure would make any sense within a
structure statement.

> Can
> we use augment-structure with other data structure instead of YANG
> data structure defined in this document?

No, note how the description of augment-structure says:

  This extension is used to specify an augmentation to YANG data
  structure defined with the 'structure' statement.


> 6.  In A.5, how error-code is hooked into rpc-error?

Only by text; there is no formal way to do this:

   The following example defines a data structure with error
   information, that can be included in an  element in an
   .

Also note that this is just an example...

> Why not use
> augment-structure in this case?

There is no sx:structure to augment.




/martin


> Describe path statement to indicate
> the relationship with rpc error?
> 
> -Qin
> 
> 
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Joel Jaeggli
> 发送时间: 2019年9月27日 13:32
> 收件人: NETMOD Working Group 
> 主题: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4
> 
> All,
> 
> This starts a two week working group last call for
> draft-ietf-netmod-yang-data-ext-04
> 
> The working group last call ends on Friday October 11th 2019.  Please
> send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it
> is ready for publication", are welcome!  This is useful and important,
> even from authors.
> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04
> 
> The diff from 03, produced prior to IETF 105 is available here:
> 
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt
> 
> Thanks
> Joel
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

[Martin Bjorklund]

Hi,

Thank you for the review.  Comments inline.

"Rob Wilton (rwilton)"  wrote:
> Hi,
> 
> I've reviewed this document, and other than 2 minor nits, I believe
> that it is ready for publication. 
> 
> Two minor comments:
> 
> 
>   1.  Section 1.1.1 NMDA.  There should be a comma before "and are
>   not redefined here".

Fixed.

>   2.  I wonder whether it would be useful to have a sentence in the
>   "Definitions" section that defines how a structure is encoded.
>   Although I appreciate that this is specified in the YANG module
>   itself.  An alternative could be a forward reference from the
>   Definitions section to the YANG module.  This could also cover the
>   Xpath behaviour as well.

This is probably a good idea.  Perhaps also add a small example:


   A YANG data structure is encoded in the same way as an "anydata"
   node.  This means that the name of the structure is encoded as a
   "container", with the instantiated children encoded as child nodes to
   this node.  For example, this structure:

 module example-errors {
   ...

   sx:structure my-error {
 leaf error-number {
   type int;
 }
   }
 }

   can be encoded in JSON as:

 "example-module:my-error": {
   "error-number": 131
 }



/martin



> 
> Thanks,
> Rob
> 
> 
> From: netmod  On Behalf Of Joel Jaeggli
> Sent: 27 September 2019 06:32
> To: NETMOD Working Group 
> Subject: [netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4
> 
> All,
> 
> This starts a two week working group last call for  
> draft-ietf-netmod-yang-data-ext-04
> 
> The working group last call ends on  Friday October 11th 2019.  Please send 
> your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors.
> 
> 
> https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04
> 
> 
> The diff from 03, produced prior to IETF 105 is available here:
> 
> 
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt
> 
> 
> Thanks
> Joel
> 
> 

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

Re: [netmod] IPR check draft-ietf-netmod-yang-data-ext-04

[Martin Bjorklund]

Joel Jaeggli  wrote:
> Authors, Contributors, WG,
> 
> As part of WG Last Call for  draft-ietf-netmod-yang-data-ext-04
> 
> Are you aware of any IPR that applies to drafts identified above?

No, I'm not aware of any IPR that applies to this draft


/martin


> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty 
> .
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 

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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Thu, 2019-09-26 at 11:04 +, Schönwälder, Jürgen wrote:
> > On Thu, Sep 26, 2019 at 12:27:17PM +0200, Ladislav Lhotka wrote:
> > > > Sure, one can discuss whether this feature is useful or harmful
> > > > but the only way to officially remove this is to create a new
> > > > specification and to run it through the IETF process.
> > > 
> > > I do insist that the wording in 7950 permits my interpretation, so I don't
> > > propose any change.
> > 
> > It does not. You cannot cherry pick sentences.
> 
> I am not aware of any cherry-picking on my side. Can you show that my
> interpretation is not possible?

8.2 says:

   o  If a request modifies a configuration data node such that any
  node's "when" expression becomes false, then the node in the data=

  tree with the "when" expression is deleted by the server.

This means that requests can modify config this way, otherwise this
text wouldn't be there.  This is not just an intention, but follows
from the text.

>  Whatever the intent was, it is the text of the
> spec that counts.

With this logic, no client can be certain of anything; a server would
be free to reject legal requests in any way it liked.  For example it
would be perfectly fine for a server to only accept requests that
modifies a single leaf at the time.



/martin



> 
> > 
> > > What I propose instead is to remove such protocol-specific parts from the
> > > specification of the YANG language, and clarify it in the specification of
> > > individual protocols.
> > 
> > This is a different topic. Moving things around does not change the
> > meaning (unless you change things as well while moving things around).
> 
> I wrote about clarification of protocols or server behaviour, which means
> changes. It is also possible that different protocols use different 
> approaches.
> 
> Lada
> 
> > 
> > /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
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] 答复: 答复: Please clarify implementation about ‘when’

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Thu, 2019-09-26 at 08:56 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Andy Bierman  writes:
> > 
> > > 
> > 
> > > > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> > 
> > > > jason.ste...@nokia.com> wrote:
> > 
> > > >
> > 
> > > >> Processing order should not matter. The evaluation of the 'when'
> > statement
> > 
> > > >> should be done assuming an atomic application of the edit-config.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> I agree that a standards compliant server should do as Rob said:
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> - For “scene 1”, the config change is accepted because the result of 
> > > >> the
> > 
> > > >> config datastore after the edit-config has been applied is valid.
> > 
> > > >>
> > 
> > > >> - For “scene 2”, the config change is rejected because the result of 
> > > >> the
> > 
> > > >> config datastore after the edit-config has been applied is invalid.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> From an implementation that may indeed mean processing the 'when' 
> > > >> after a
> > 
> > > >> first pass that sets the various leafs to tentative values. But that's
> > 
> > > >> implementation detail.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >> IMO the auto-clearing behavior of 'when' may be complicated but that is
> > 
> > > >> how it is defined (same with 'choice'). Clients can and should depend 
> > > >> on
> > 
> > > >> things being automatically deleted. If you want validation errors (i.e.
> > 
> > > >> force the client to clear all the dependant leafs instead of auto-
> > clearing)
> > 
> > > >> then use a 'must' statement.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >
> > 
> > > > +1
> > 
> > > >
> > 
> > > > YANG clearly defines "must" and "when" with different behavior.
> > 
> > > > A server that does not implement the auto-delete aspects of when-stmt is
> > 
> > > > not compliant to the RFC.
> > 
> > > 
> > 
> > > I don't agree with this. RFC 7950 says in sec. 8.1:
> > 
> > > 
> > 
> > >The following properties are true in all data trees:
> > 
> > > 
> > 
> > >...
> > 
> > > 
> > 
> > >o  There MUST be no nodes tagged with "when" present if the "when"
> > 
> > >   condition evaluates to "false" in the data tree.
> > 
> > 
> > It also says in 8.2:
> > 
> >o  If a request modifies a configuration data node such that any
> >   node's "when" expression becomes false, then the node in the data
> >   tree with the "when" expression is deleted by the server.
> 
> Right. But the request won't modify a configuration data node because it is
> rejected. So the premise of the above implication doesn't hold, and the
> conclusion doesn't apply.

With the same logic you can claim conformance if you reject a request
to create nodes under a case if another case is active.  I think it is
quite clear that this auto-deletion is part of the spec, and something
clients can rely on.  If the intention had been that this was optional
to implement, it would have been clearly stated, and there would have
been mechanism present for clients to detect this.


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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> 
> > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> > jason.ste...@nokia.com> wrote:
> >
> >> Processing order should not matter. The evaluation of the 'when' statement
> >> should be done assuming an atomic application of the edit-config.
> >>
> >>
> >>
> >> I agree that a standards compliant server should do as Rob said:
> >>
> >>
> >>
> >> - For “scene 1”, the config change is accepted because the result of the
> >> config datastore after the edit-config has been applied is valid.
> >>
> >> - For “scene 2”, the config change is rejected because the result of the
> >> config datastore after the edit-config has been applied is invalid.
> >>
> >>
> >>
> >> From an implementation that may indeed mean processing the 'when' after a
> >> first pass that sets the various leafs to tentative values. But that's
> >> implementation detail.
> >>
> >>
> >>
> >> IMO the auto-clearing behavior of 'when' may be complicated but that is
> >> how it is defined (same with 'choice'). Clients can and should depend on
> >> things being automatically deleted. If you want validation errors (i.e.
> >> force the client to clear all the dependant leafs instead of auto-clearing)
> >> then use a 'must' statement.
> >>
> >>
> >>
> >
> > +1
> >
> > YANG clearly defines "must" and "when" with different behavior.
> > A server that does not implement the auto-delete aspects of when-stmt is
> > not compliant to the RFC.
> 
> I don't agree with this. RFC 7950 says in sec. 8.1:
> 
>The following properties are true in all data trees:
> 
>...
> 
>o  There MUST be no nodes tagged with "when" present if the "when"
>   condition evaluates to "false" in the data tree.

It also says in 8.2:

   o  If a request modifies a configuration data node such that any
  node's "when" expression becomes false, then the node in the data
  tree with the "when" expression is deleted by the server.


/martin

> 
> This can also be prevented if the server rejects an edit operation
> that would create such a situation.
> 
> Lada
> 
> 
> >
> >
> >> Jason
> >>
> >
> > Andy
> >
> >
> >>
> >>
> >> *From:* netmod  *On Behalf Of *Qin Wu
> >> *Sent:* Tuesday, September 10, 2019 10:33 PM
> >> *To:* Fengchong (frank) ; Andy Bierman <
> >> a...@yumaworks.com>
> >> *Cc:* netmod@ietf.org; Yangang 
> >> *Subject:* [netmod] 答复: 答复: Please clarify implementation about ‘when’
> >>
> >>
> >>
> >> Why processing order matter? My interpretation is both leaf node values
> >> (i.e.,leaf a, leaf b) should be validated together and commit as a whole,
> >>
> >> RFC6241 said:
> >>
> >> “
> >>
> >> If the device is unable to commit all of the changes in the
> >>
> >>  candidate configuration datastore, then the running
> >>
> >>  configuration MUST remain unchanged.
> >>
> >> ”
> >>
> >> So validate the leaf node value in the edit-config request (message
> >> content validation) is not important, validate the leaf node value that is
> >> applied to  (datastore validation) is the key.
> >>
> >>
> >>
> >> I think what you want to raise is the server should hold on to send reply 
> >> with an "unknown-element"  in the  during payload 
> >> parsing phase and NETCONF 
> >>
> >> Processing until all validation complete, otherwise it seems server will
> >>
> >> Send multiple rply with "unknown-element"  in the  
> >> which seems not reasonable.
> >>
> >>
> >>
> >> -Qin
> >>
> >> *发件人**:* netmod [mailto:netmod-boun...@ietf.org ]
> >> *代表 *Fengchong (frank)
> >> *发送时间**:* 2019年9月11日 9:29
> >> *收件人**:* Andy Bierman 
> >> *抄送**:* netmod@ietf.org; Yangang 
> >> *主题**:* [netmod] 答复: Please clarify implementation about ‘when’
> >>
> >>
> >>
> >> Andy,
> >>
> >>
> >>
> >> Whether different result would occur according different process order?
> >>
> >> According 8.3.2
> >>
> >> if server process ‘a= 3’ firstly, b will be deleted by system and becomes
> >> a non-exist schema node, and then  when ‘b=5’ is processed , server will
> >> report a ‘unknown-element’ error.
> >>
> >> But if server process ‘b=5’ firstly, it will be accepted by server, and
> >> then when ‘a=3’ is processed, b will be deleted by system, but report OK.
> >>
> >>
> >>
> >> If sec 8.3.2 is not right. What is the right?
> >>
> >> When node a and node b in the same request, and b tagged when condition,
> >> a’s value will cause b’s condition is evaluated to false, which is more
> >> prior?
> >>
> >> According you and Rob’s interpretation , maybe node ’a’ is more prior? If
> >> yes, why node ‘b’ should be processed later?
> >>
> >>
> >>
> >> I think whether in edit-config processing phase the configuration tagged
> >> when should not be evaluated and be delayed to commit or validate?
> >>
> >> When commit or validate operation is issued,  the data node tagged when
> >> will be evaluated, and if it’s evaluated to false, this data will be
> >> deleted by system immediately, server should not report any error.
> >>
> >>
> >>
> >>

Re: [netmod] Processing open errata in the the netmod working group

[Martin Bjorklund]

Joel Jaeggli  wrote:
> Folks,
> 
> Over the course of this we we intend to process reported errata that
> we have outstanding in netmod

I started to go through the list and comment, but then I realized that
you probably didn't ask for comments?  This was just a FYI?


/martin

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

Re: [netmod] [Technical Errata Reported] RFC7950 (5807)

[Martin Bjorklund]

Warren Kumari  wrote:
> [ - RFC Ed (for clutter), + Benoit (who verified
> https://www.rfc-editor.org/errata/eid4794) ]
> 
> I'm trying to go through and clean up the outstanding Ops and
> Management Errata. I'm completely, 100% not a YANG / netmod person (I
> cannot even spell YANG!), but I *think* that this Errata should be
> verified, yes? This isn't changing what was decided when the WG
> published this, it is simply correcting / clarifying the text.

Yes I agree it should be verified.


/martin


> 
> The Errata criteria are here:
> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
> 
> One of the big ones is that we only use Errata to fix actual errors,
> not change anything that was WG consensus at the time:
> "Changes that modify the working of a protocol to something that might
> be different from the intended consensus when the document was
> approved should be either Hold for Document Update or Rejected.
> Deciding between these two depends on judgment. Changes that are
> clearly modifications to the intended consensus, or involve large
> textual changes, should be Rejected. In unclear situations, small
> changes can be Hold for Document Update."
> 
> Again, I'm not a NetMod person, so looking for clear advice here...
> 
> W
> 
> On Tue, Aug 13, 2019 at 7:26 AM RFC Errata System
>  wrote:
> >
> > The following errata report has been submitted for RFC7950,
> > "The YANG 1.1 Data Modeling Language".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5807
> >
> > --
> > Type: Technical
> > Reported by: Jernej Tuljak 
> >
> > Section: 7.21.5.
> >
> > Original Text
> > -
> >o  If the "when" statement is a child of a "uses", "choice", or
> >   "case" statement, then the context node is the closest ancestor
> >   node to the node with the "when" statement that is also a data
> >   node.  If no such node exists, the context node is the root node.
> >   The accessible tree is tentatively altered during the processing
> >   of the XPath expression by removing all instances (if any) of the
> >   nodes added by the "uses", "choice", or "case" statement.
> >
> > Corrected Text
> > --
> >o  If the "when" statement is a child of a "uses", "choice", or
> >   "case" statement, then the context node is the closest ancestor
> >   node to the node with the "when" statement that is also a data
> >   node, rpc, action or notification.  If no such node exists, the
> >   context node is the root node. The accessible tree is tentatively
> >   altered during the processing of the XPath expression by removing
> >   all instances (if any) of the nodes added by the "uses",
> >   "choice", or "case" statement.
> >
> > Notes
> > -
> > Similar to verified errata 4794 (https://www.rfc-editor.org/errata/eid4794) 
> > but covers the "uses", "choice" and "case" corner case (instead of 
> > "augment"). If the node for which the "when" statement is defined is within 
> > an rpc, action or notification, the context node also needs to be inside 
> > that rpc, action or notification. There are published IETF modules, which 
> > rely on this to be true, such as "ietf-netconf-nmda@2019-01-07" in RFC8526 
> > (https://tools.ietf.org/html/rfc8526) at schema node id 
> > "/ncds:get-data/ncds:input/ncds:origin-filters". Original text assigns the 
> > context node to the root node, if no data node ancestor is found. "rpc", 
> > "action" and "notification" are not data nodes and are represented by nodes 
> > that are descendants of the root node, as described in Section 6.4.1.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --
> > Title   : The YANG 1.1 Data Modeling Language
> > Publication Date: August 2016
> > Author(s)   : M. Bjorklund, Ed.
> > Category: PROPOSED STANDARD
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
> 

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

Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)

[Martin Bjorklund]

Warren Kumari  wrote:
> On Thu, Feb 21, 2019 at 1:53 PM Andy Bierman  wrote:
> >
> >
> >
> > On Thu, Feb 21, 2019 at 10:33 AM Martin Bjorklund  wrote:
> >>
> >> Andy Bierman  wrote:
> >> > On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg 
> >> > wrote:
> >> >
> >> > >
> >> > >
> >> > > Your example is fine – but the gammar is ch14 specifies something
> >> > > different:
> >> > >
> >> > >
> >> > >
> >> > > enum-stmt   = enum-keyword sep string optsep
> >> > >
> >> > >  (";" /
> >> > >
> >> > >   "{" stmtsep
> >> > >
> >> > >   ;; these stmts can appear in any order
> >> > >
> >> > >   *if-feature-stmt
> >> > >
> >> > >   [value-stmt]
> >> > >
> >> > >   [status-stmt]
> >> > >
> >> > >   [description-stmt]
> >> > >
> >> > >   [reference-stmt]
> >> > >
> >> > >"}") stmtsep
> >> > >
> >> > >
> >> > >
> >> > > It clearly states  string, not quoted-string. These two have the 
> >> > > following
> >> > > rules:
> >> > >
> >> > >
> >> > >
> >> > > quoted-string   = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
> >> > >
> >> > >
> >> > >
> >> > > string  = < an unquoted string, as returned by >
> >> > >
> >> > >  < the scanner, that matches the rule >
> >> > >
> >> > >  < yang-string >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> > The text in 9.6.4 is correct.
> >> > The ABNF is wrong.
> >>
> >> No, the ABNF is correct.  The ABNF doens't handle concatenation etc.
> >> The idea is that the scanner handles quotes and concatenation and
> >> returns a "string".
> >>
> >
> >
> > OK -- it is confusing that the rule quoted-string exists, but it
> > is only for key and leaf-list predicates.
> 
> Hi all,
> 
> I'm trying to go through and do some cleanup of the dangling Errata.
> I'm *certainly* not an expert here, and so am relying on y'all.
> From what I've been able to figure out, the consensus is that this
> Errata should be rejected, yes?

Yes.


/martin


> W
> 
> 
> >
> >
> >>
> >>
> >> /martin
> >>
> >
> > Andy
> >
> >>
> >>
> >>
> >> >
> >> >
> >> >
> >> > > …and in 6.1.3 we can read that:
> >> > >
> >> > >An unquoted string is any sequence of characters that does not
> >> > >
> >> > >contain any space, tab, carriage return, or line feed characters, a
> >> > >
> >> > >single or double quote character, a semicolon (";"), braces ("{" or
> >> > >
> >> > >"}"), or comment sequences ("//", "/*", or "*/").
> >> > >
> >> > >
> >> > >
> >> > >Note that any keyword can legally appear as an unquoted string.
> >> > >
> >> > >
> >> > >
> >> > > Since the section so clearly writes about single quoted strings and 
> >> > > double
> >> > > quoted strings, there can unfortunately be no interpretation that would
> >> > > allow “identifier” to be called an unquoted string – even though it 
> >> > > follows
> >> > > the rules about limited character contents.
> >> > >
> >> > >
> >> > >
> >> > > Hence – this is not a matter of opinion – it’s a matter of reading 
> >> > > what’s
> >> > > actually written in the RFC.
> >> > >
> >> > >
> >> > >
> >> > > But on the subject of

Re: [netmod] Alissa Cooper's Abstain on draft-ietf-netmod-artwork-folding-09: (with COMMENT)

[Martin Bjorklund]

Erik Auerswald  wrote:
> Hi Martin,
> 
> On Thu, Sep 05, 2019 at 05:17:30PM +0200, Martin Bjorklund wrote:
> > Kent Watsen  wrote:
> > > 
> > > >> There has been discussion about how embedding YANG models in RFCs 
> > > >> seems like a
> > > >> poor fit for a number of reasons. By standardizing line-folding 
> > > >> mechanisms and
> > > >> claiming them as a best practice, this document reinforces the root of 
> > > >> that
> > > >> problem rather than trying to fix it.
> > > > 
> > > > Well said, I agree with Alissa's conclusion.
> > 
> > But the algorithm in the document isn't supposed to be used for YANG
> > modules.  It is supposed to be used primarily for XML and JSON
> > snippets (etc).
> 
> Technically, XML and JSON are whitespace-agnostic

Whitespaces are significant in XML element values, which means that we
have to write e.g.

2013-04-01T03:00:00+00:00

With indentation for readability we quickly run out of horizontal
space.

> and often can be
> "folded" manually without any folding indicators.  That seems to be
> true for YANG as well.

It is true for YANG, which is why I wrote that this algorithm isn't
supposed to be used for YANG.  In fact, the document says:

   It is RECOMMENDED that authors do as much as possible within the
   selected format to avoid long lines.

> Even Python code usually can be kept under any
> reasonable line length.
> 
> Very long names or values could require algorithmic folding, i.e.,
> a generic line-folding mechanism.
> 
> I personally would try to keep the line length of any code inside an
> RFC short enough to not need additional algorithmic folding.  But if
> this does not work, e.g., because some name or value is just too long,
> having a recommended algorithm seems to be better than every author
> making up another ad-hoc folding scheme.
> 
> The I-D.ietf-netmod-artwork-folding seems to try to provide a recommended
> algorithm for the case where a generic line-folding mechanism is needed.

Exactly!


/martin


> 
> Overly long lines sometimes result in lost information in HTML or PDF
> documents, if a complex layout is used, but no mechanism for dealing with
> unexpectedly long lines is included.  I have seen too many examples of
> this to believe that this cannot happen with RFCs.
> 
> Thanks,
> Erik
> 

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

Re: [netmod] Alissa Cooper's Abstain on draft-ietf-netmod-artwork-folding-09: (with COMMENT)

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> 
> >> There has been discussion about how embedding YANG models in RFCs seems 
> >> like a
> >> poor fit for a number of reasons. By standardizing line-folding mechanisms 
> >> and
> >> claiming them as a best practice, this document reinforces the root of that
> >> problem rather than trying to fix it.
> > 
> > Well said, I agree with Alissa's conclusion.

But the algorithm in the document isn't supposed to be used for YANG
modules.  It is supposed to be used primarily for XML and JSON
snippets (etc).

> Assuming 'a', yes, 'b' follows 'a'.  That said, the concern is nebulous
> and how to address it more so.  Proposals?
> 
> Assuming the concern is process-overhead for minor spins

I think we need to understand what the "number of reasons" Alissa
refers to really are, before we try to come up with solutions.


/martin


> , perhaps we
> could leverage the module-versioning work as follows:
> 
>   * Initial and NBC modules go thru standard RFC publishing process (i.e.,
> there is still a need to publish YANG modules in RFCs).
> 
>   * BC modules can skip standard publishing process but, to be an "IETF"
> product (not some random fork), they would need to be released via an
> IETF-owned mechanism (e.g., an Git repo) with restricted write-access.
> 
> Thoughts?
> 
> Kent
> 

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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Martin Bjorklund]

"Rob Wilton (rwilton)"  wrote:
> Hi Martin,
> 
> Please see comments inline ...
> 
> > -Original Message-
> > From: Martin Bjorklund 
> > Sent: 22 August 2019 12:35
> > To: Rob Wilton (rwilton) 
> > Cc: vladi...@transpacket.com; netmod@ietf.org
> > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> > 
> > Hi,
> > 
> > Some comments inline.
> > 
> > 
> > "Rob Wilton (rwilton)"  wrote:
> > > Hi Vladimir,
> > >
> > > Thanks for your detailed review.  Sorry for the slow reply, I've been
> > > away.  I'm also about to be away again for a couple of days.
> > >
> > > Please see my comments inline ...
> > >
> > > I'll also track these issues to closure on
> > > https://github.com/netmod-wg/interface-extensions-yang/issues
> > >
> > > > -Original Message-
> > > > From: netmod  On Behalf Of Vladimir
> > > > Vassilev
> > > > Sent: 13 August 2019 17:05
> > > > To: Kent Watsen ; netmod@ietf.org
> > > > Subject: Re: [netmod] WG Last Call:
> > > > draft-ietf-netmod-intf-ext-yang-07
> > > >
> > > > I have reviewed the draft. I have the following (19) IMO useful
> > > > proposals:
> > > >
> > > > 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the
> > > > oper- status debouncing/dampening functionality currently in
> > > > ietf-interfaces-
> > > > common.yang.
> > >
> > > I don't think that we want a proliferation of too many separate YANG
> > > modules for small features.  Each of the areas of different
> > > functionality within this module are already conditional on
> > > if-feature, so I don't think that there is a strong justification to
> > > separating this out as a separate module.
> > 
> > I agree.
> > 
> > > > 4. Dedicated module (ietf-if-loopback.yang) for the loopback
> > > > functionality currently in ietf-interfaces-common.yang.
> > >
> > > Same answer as for 1. I don't think that we should have too many
> > > really small modules.
> > 
> > I agree.
> > 
> > 
> > > > 10. Introducing config true "forwarding-mode" leaf breaks clients
> > > > that support e.g. rfc8344 ietf-ip (which has its dedicated
> > > > forwarding leafs e.g.
> > > > /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) by
> > > > introducing this new module with a new leaf they know nothing about.
> > > > I support this leaf as config false. If NETCONF was not
> > > > transactional a global leaf enabling the forwarding configuration
> > > > would be a feature.
> > > > But NETCONF is transactional.
> > >
> > > I don't get the relevance of transactions

Neither do I.


> > > , but it isn't intended to
> > > break existing clients/YANG modules.
> > >
> > > The idea of this leaf is that if it is configured then the system can
> > > use it to check other constraints.  E.g. to validate that an L2 QoS
> > > policy isn’t being configured on an L3 interface.  If the leaf isn't
> > > configured then those constraints are not checked.
> > 
> > Hmm.  Are you saying that this leaf doesn't have any direct effect in
> > the
> > server?
> 
> It depends on the device.  Some devices require a leaf like this (or
> similar) to correctly provision the services.  Other devices don't
> need it.

Hmm, is this really a property of the device implementation?  Isn't it
a property of the data models that describe these services?

It seems to me that the semantics of this leaf is a bit unclear,
esp. if we look at the sub-intf-vlan model which uses this leaf:

container dot1q-vlan {
  must
'count(../../if-cmn:forwarding-mode) = 0 or ' +
'derived-from-or-self(../../if-cmn:forwarding-mode,' +
  '"if-cmn:layer-3-forwarding")' 


This means that it is perfectly ok for a client to configure
"dot1q-vlan" without also setting forwarding-mode.



> > > > 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of
> > > > ietf-
> > > > interfaces-common.yang and ietf-interfaces-ethernet-like.yang.
> > > > Setting a shorter naming precedent for future modules augmenting
> > > > ietf- interfaces.
> > >
> > > I'm not opposed to shorter names, but would be interested in the views
> > > of others in the WG.
>

Re: [netmod] WG Last Call: draft-ietf-netmod-sub-intf-vlan-model-05

[Martin Bjorklund]

Hi,

Here is my (late) review of draft-ietf-netmod-sub-intf-vlan-model-05.

o  1

  The YANG module names are not correct; they are listed as:

  if-l3-vlan.yang - Defines the model for basic classification of
  VLAN tagged traffic to L3 transport services

  flexible-encapsulation.yang - Defines the model for flexible
  classification of Ethernet/VLAN traffic to L2 transport services

   Should be "ietf-if-l3-vlan" and "ietf-flexible-encapsulation".

   Or "ietf-if-l3-vlan" and "ietf-if-flexible-encapsulation".

   But I also wonder if these names should somehow be changed.  What
   is a "l3-vlan"?  And "flexible-encapsulation" sound a bit too
   generic.


o  1.1

  The text says:

   Sub-interface: A sub-interface is a small augmentation of a regular
   interface in the standard YANG module for Interface Management that
   represents a subset of the traffic handled by its parent interface.

  I think the augmentation is the YANG-realization of a sub-interface,
  but it is not what a sub-interface is.  Also, this definition is
  mis-leading; it doesn't mention that a sub-interface has its own
  interface type and is represented as one separate entry in the
  interface list.  I think it is better to import this term from
  draft-ietf-netmod-intf-ext-yang (section 3.6)

o  3

  The text says:

   The L3 Interface VLAN model provides appropriate leaves for
   termination of an 802.1Q VLAN tagged segment to a sub-interface based
   L3 service.

  There is a comment in the YANG model that says the same thing.

  But the YANG model itself augments not only to sub-interface-based
  interface, but also to ethernet-like interfaces.


o  YANG modules

  Both modules lack the IETF Trust Copyright statement.

  We don't list WG Chairs anymore.

  The revision statements should be on the form: "RFC : "

  Many descriptions are full sentences w/o the ending ".".

  The modules should be indented properly; a starting point can be
  pyang -f yang --yang-line-length 69


o  ietf-if-l3-vlan

  There is a comment:

/*
 * Matches a single VLAN Id, or a pair of VLAN Ids to classify
 * traffic into an L3 service.
 */

  This should be moved into a description clause.

o  ietf-if-l3-vlan / container dot1q-vlan

  The must statement has:

 count(../../if-cmn:forwarding-mode) = 0

  This can be changed to not(../../if-cmn:forwarding-mode) which is
  more direct imo.

  The must statement's description statement seems to be a
  copy-and-paste error.


o  ietf-if-l3-vlan / container dot1q-vlan

  The descriptions talk about "matching frames" and "classifying
  traffic", but it is not described anywhere how the matching and
  classifying is used.

  (also applies to ietf-flexible-encapsulation)


o  ietf-if-l3-vlan / outer-tag / second-tag

  These names are a bit inconsistent.  The description describes them
  as "outermost tag" and "second outermost tag".  Perhaps use these
  names instead?

  (same names are found in ietf-flexible-encapsulation)



o  ietf-flexible-encapsulation / all features

  The features are described as:

  "This feature indicates whether the network element supports
specifying flexible rewrite operations";

  Should this be s/whether/that ?


o  ietf-flexible-encapsulation

  There is some descriptive text in comments that should be moved to
  description statements.


o  ietf-flexible-encapsulation

  The descriptions for pop/push are a bit terse.  It seems to assume
  that readers already know what this (from somewhere) is so it
  doesn't need to be described.  If this is intended, perhaps add a
  reference to where this is described.



/martin

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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Martin Bjorklund]

Martin Bjorklund  wrote:
> Hi,
> 
> Some comments inline.
> 
> 
> "Rob Wilton (rwilton)"  wrote:
> > Hi Vladimir,
> > 
> > Thanks for your detailed review.  Sorry for the slow reply, I've been
> > away.  I'm also about to be away again for a couple of days.
> > 
> > Please see my comments inline ...
> > 
> > I'll also track these issues to closure on
> > https://github.com/netmod-wg/interface-extensions-yang/issues
> > 
> > > -Original Message-
> > > From: netmod  On Behalf Of Vladimir Vassilev

[...]

> > > 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of
> > > ietf-
> > > interfaces-common.yang and ietf-interfaces-ethernet-like.yang.
> > > Setting a shorter naming precedent for future modules augmenting ietf-
> > > interfaces.
> > 
> > I'm not opposed to shorter names, but would be interested in the views
> > of others in the WG.
> 
> I had a similar concern for the modules in the sub-intf-vlan draft (I
> will post my review of that doc later).
> 
> Currently we have:
> 
>   ietf-interfaces-common
>   ietf-interfaces-ethernet-like
>   ietf-if-l3-vlan
>   ietf-flexible-encapsulation
> 
> I think we should have consistency, either:
> 
>   ietf-interfaces-common
>   ietf-interfaces-ethernet-like
>   ietf-interfaces-l3-vlan
>   ietf-interfaces-flexible-encapsulation
> 
> or
> 
>   ietf-if-common
>   ietf-if-ethernet-like
>   ietf-if-l3-vlan
>   ietf-if-flexible-encapsulation


One comment re naming here.

The name "ietf-interfaces-common" seems a bit odd; isn't
"ietf-interfaces" for "common" definitions?

I was going to suggest "ietf-interfaces-extensions", but then I
re-read the description in the module:

  This module contains common definitions for extending the IETF
  interface YANG model (RFC 8343) with common configurable layer 2
  properties.

So perhaps "ietf-interfaces-l2-extensions" would be better?

 but then "forwarding-mode" isn't a l2 property.



/martin

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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Martin Bjorklund]

Hi,

Some comments inline.


"Rob Wilton (rwilton)"  wrote:
> Hi Vladimir,
> 
> Thanks for your detailed review.  Sorry for the slow reply, I've been
> away.  I'm also about to be away again for a couple of days.
> 
> Please see my comments inline ...
> 
> I'll also track these issues to closure on
> https://github.com/netmod-wg/interface-extensions-yang/issues
> 
> > -Original Message-
> > From: netmod  On Behalf Of Vladimir Vassilev
> > Sent: 13 August 2019 17:05
> > To: Kent Watsen ; netmod@ietf.org
> > Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> > 
> > I have reviewed the draft. I have the following (19) IMO useful
> > proposals:
> > 
> > 1. Dedicated module (ietf-if-oper-status-debounce.yang) for the oper-
> > status debouncing/dampening functionality currently in
> > ietf-interfaces-
> > common.yang.
> 
> I don't think that we want a proliferation of too many separate YANG
> modules for small features.  Each of the areas of different
> functionality within this module are already conditional on
> if-feature, so I don't think that there is a strong justification to
> separating this out as a separate module.

I agree.

> > 4. Dedicated module (ietf-if-loopback.yang) for the loopback
> > functionality
> > currently in ietf-interfaces-common.yang.
> 
> Same answer as for 1. I don't think that we should have too many
> really small modules.

I agree.


> > 10. Introducing config true "forwarding-mode" leaf breaks clients that
> > support e.g. rfc8344 ietf-ip (which has its dedicated forwarding leafs
> > e.g. /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding )
> > by
> > introducing this new module with a new leaf they know nothing about. I
> > support this leaf as config false. If NETCONF was not transactional a
> > global leaf enabling the forwarding configuration would be a feature.
> > But NETCONF is transactional.
> 
> I don't get the relevance of transactions, but it isn't intended to
> break existing clients/YANG modules.
> 
> The idea of this leaf is that if it is configured then the system can
> use it to check other constraints.  E.g. to validate that an L2 QoS
> policy isn’t being configured on an L3 interface.  If the leaf isn't
> configured then those constraints are not checked.

Hmm.  Are you saying that this leaf doesn't have any direct effect in
the server?

> > 12. I do not agree we need this text. Normally NETCONF devices should
> > accept transactions to any valid configuration:
> > 
> > OLD:
> >     ...
> >     Normally devices will not allow the parent-interface leaf to be
> >     changed after the interfce has been created.  If an implementation
> >     did allow the parent-interface leaf to be changed then it could
> >  cause
> >     all traffic on the affected interface to be dropped.  The affected
> >     leaf is:
> > 
> >     o  /if:interfaces/if:interface/parent-interface
> >     ...
> > 
> > NEW:
> >     ...
> >     Changing the parent-interface leaf could cause
> >     all traffic on the affected interface to be dropped.
> >     The affected leaf is:
> > 
> >     o  /if:interfaces/if:interface/parent-interface
> >     ...
> 
> This isn't about transactions so much as valid configuration.
> 
> Normally, the name of the sub-interface is tightly bound to the parent
> interface.  E.g. if the parent in "Ethernet0/1" then the sub-interface
> would be "Ethernet0/1.1".  If you tried to change the parent-interface
> leaf of "Ethernet0/1.1" to "Ethernet2/2" then I would expect the
> system to reject that change (because the configuration is invalid not
> because of transactions).

Well, this is already described in section 3.6.  The quoted text is
from Security Considerations.  I agree with Vladimir; I think his
suggested text is better.

> > 14. I propose the in-pkts and out-pkts counters standardized too.
> > https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/ietf-
> > interfaces-ext.yang.
> > And yes someone forgot to update the boilerplate text.
> 
> This one I think that we need to get further input on.
> 
> https://github.com/YangModels/yang/blob/master/standard/ieee/published/802.3/ieee802-ethernet-interface.yang
> 
> defines in-frames and out-frames, but these are only for Ethernet, but
> you are probably looking for a counter across all interface types.

in-pkts is presumably in-unicast-pkts + in-broadcast-pkts +
in-multicast-pkts.  So is this really needed?

> > 19. ietf-if-common.yang and ietf-if-ethernet-like.yang instead of
> > ietf-
> > interfaces-common.yang and ietf-interfaces-ethernet-like.yang.
> > Setting a shorter naming precedent for future modules augmenting ietf-
> > interfaces.
> 
> I'm not opposed to shorter names, but would be interested in the views
> of others in the WG.

I had a similar concern for the modules in the sub-intf-vlan draft (I
will post my review of that doc later).

Currently we have:

  ietf-interfaces-common
  ietf-interfaces-ethernet-like
  ietf-if-l3-vlan
  

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Martin Bjorklund]

Hi,

Here is my (late) review of draft-ietf-netmod-intf-ext-yang-07.  It is
a well-written document and my comments are mostly minor.


o  Abstract

  OLD:

   The YANG data model in this document conforms to the Network
   Management Datastore Architecture (NMDA) defined in RFC 8342.

  NEW:

   The YANG modules in this document conform to the Network
   Management Datastore Architecture (NMDA) defined in RFC 8342.


o  Section 1

 One of the aims of this draft is to provide a standard namespace and
 path for these configuration items regardless of the underlying
 interface type.  For example a standard namespace and path for

  "standard namespace and path" sounds a bit clumsy.  In section 2 you
  use "standard definition", perhaps that can be use here.


o  General

  s/this internet draft/this document/g
  s/this draft/this document/g


o  Section 2

  It seems this short section mostly says what is already said in
  section 1.  Remove?


o  3

  The text says:

o  A parent interface leaf useable for all types of sub-interface
   that are children of parent interfaces.

  I suggest you add before that bullet:

o  A generic "sub-interface" identity that an interface identity
   defintion can derive from if it defines a sub-interface.


o  3.1

  The text says:

E.g. in the
case that the link state transition is suppressed then there is no
change of the /if:interfaces-state/if:interface/oper-status or
/if:interfaces-state/if:interfaces/last-change leaves for the
interface that the feature is operating on.

  This should be:

no change of the /if:interfaces/if:interface/oper-status or
/if:interfaces/if:interfaces/last-change leaves for the
interface that the feature is operating on.


o  3.2

  It took me some time to understand the dampening algorithm.  Why is
  it important to talk about nominal values and that a device doesn't
  have to use 1000 as the penalty, as long as they scale the given
  values?  Wouldn't it be easier to describe the algorithm w/o any
  nominal values, and then explain that an implementation is free to
  implement this algorithm in any way it wants (which of course is
  true for everything we do...)

  Otherwise, the text currently says:

   Implementations are not required to use a penalty of 1000 units in
   their dampening algorithm, but should ensure that the Suppress
   Threshold and Reuse Threshold values are scaled relative to the
   nominal 1000 unit penalty to ensure that the same configuration
   values provide consistent behaviour.

  Should "should" in this text be "SHOULD"?  Or perhaps "MUST"?


o  3.2.1

  The text says:

   When the accumulated penalty reaches the default or
   configured suppress threshold, the interface is placed in a dampened
   state.

  The term "dampended state" occurs twice, in 3.2.1 and 3.2.3.  It is
  not used in the YANG model.  I suspect the leaf "suppressed"
  reflects this.  Perhaps align naming.


o  4

  It would be useful with a sentence that describes the relationship
  to /if:interfaces/if:interface/if:phys-address.

  It seems that the mac-address leaf is useful when the mac address
  can be configured; otherwise if:phys-address should be sufficient,
  right?  Should the mac-address leaf have a feature, or can we expect
  all implementations to support configurable mac addresses?


o  4

  You add a container 'statistics' under 'ethernet-like', so we have:

  +--rw interfaces
 +--rw interface* [name]
...
+--ro statistics
   ...
+--rw ethlike:ethernet-like
   +--ro ethlike:statistics
  ...

  Did you consider augmenting the container if:statistics instead?  I
  think it can be useful to have all statistics in the same container
  in this case.


o  7.2

  Perhaps show the (related) 'if:oper-status' leaf as well.


o  7.3

  Perhaps show the (related) if:phys-address' leaf as well in the
  first and third examples.

  Before the second example, perhaps change:

   The following example shows an explicit MAC address being configured
   on interface eth0.

  to:

   The following example shows the intended configuration for
   interface eth0 with an explicit MAC address being configured.


o  YANG nits

  Both YANG modules list the WG chairs; we don't do that anymore.

  Both YANG modules have the IETF Trust Copyright statement, but not
  exactly as it should be (try: pyang --ietf and/or pyang --ietf-help)

  Many descriptions are full sentences w/o the ending ".".

  The reference in the revision statement should be changed to "RFC
  : "



/martin

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

Re: [netmod] RFC8526 and 'derived-from-or-self(datastore, "ds:operational")'

[Martin Bjorklund]

Hi,

Jernej Tuljak  wrote:
> Hi,
> 
> I'm trying to determine who is at fault, our YANG validator
> implementation or the module ietf-netconf-nmda in RFC8526 .
> 
> There is a "when" expression at line 193 within this module
> 
> when 'derived-from-or-self(datastore, "ds:operational") ';
> 
> which is under this pseudo-branch within the module: / get-data
> ("rpc") / input ("input") / origin-filters ("choice").
> 
> Our implementation claims that the initial context node of the
> expression does not contain a "datastore" child, resulting in a
> warning for this expression, which seemed like an obvious bug at
> first, but does not anymore.
> 
> The accessible tree for this expression is built using the following
> bullet in Section 6.4.1:
> 
>o  If the XPath expression is defined in a substatement to an "input"
>   statement in an "rpc" or "action" statement, the accessible tree
>   is the RPC or action operation instance, all state data in the
>   server, and the running configuration datastore.  The root node
>   has top-level data nodes in all modules as children.
>   Additionally, for an RPC, the root node also has the node
>   representing the RPC operation being defined as a child.  The node
>   representing the operation being defined has the operation's input
>   parameters as children.
> 
> 
> "origin-filters" for which the "when" expression is defined is clearly
> a substatement to an "input" statement in an "rpc" statement. Pseudo-
> accessible tree below (matches what our implementation does).
> 
> 
>     +- get-data
>     +- datastore
>     +- // other data node siblings of datastore
>     +- // top-level data nodes of all modules
> 
> The initial context node is determined by using the following bullet
> in Section 7.21.5:
> 
>o  If the "when" statement is a child of a "uses", "choice", or
>   "case" statement, then the context node is the closest ancestor
>   node to the node with the "when" statement that is also a data
>   node.  If no such node exists, the context node is the root node.
>   The accessible tree is tentatively altered during the processing
>   of the XPath expression by removing all instances (if any) of the
>   nodes added by the "uses", "choice", or "case" statement.
> 
> 
> The "when" statement in question is clearly a child of a "choice"
> statement without a data node ancestor. Neither "input" nor "rpc"
> represent data nodes, as per Terminology section:
> 
>o  data node: A node in the schema tree that can be instantiated in a
>   data tree.  One of container, leaf, leaf-list, list, anydata, and
>   anyxml.
> 
> 
> To our implementation this means that the initial context node is the
> root node of the accessible tree, not the node that represents the
> "rpc". Therefore the expression is attempting to refer to a node that
> is undefined. It is expecting
> 
> when 'derived-from-or-self(get-data/datastore, "ds:operational") ';
> 
> or something along those lines instead.
> 
> Either way, something doesn't add up between RFC7950 and RFC8526.
> 
> There is a suspicious verified RFC7950 errata
> (https://www.rfc-editor.org/errata/eid4794) dealing with initial
> context nodes under augments, but there's nothing for the UCC ("uses",
> "choice", "case") corner case. Perhaps there should be? Should Section
> 7.21.5 say
> 
> NEW:
> 
>o  If the "when" statement is a child of a "uses", "choice", or
>   "case" statement, then the context node is the closest ancestor
>   node to the node with the "when" statement that is also a data
>   node, rpc, action or notification.  If no such node exists, the
>   context node is the root node. The accessible tree is tentatively
>   altered during the processing of the XPath expression by removing
>   all instances (if any) of the nodes added by the "uses",
>   "choice", or "case" statement.
> 
> OLD:
> 
>o  If the "when" statement is a child of a "uses", "choice", or
>   "case" statement, then the context node is the closest ancestor
>   node to the node with the "when" statement that is also a data
>   node.  If no such node exists, the context node is the root node.
>   The accessible tree is tentatively altered during the processing
>   of the XPath expression by removing all instances (if any) of the
>   nodes added by the "uses", "choice", or "case" statement.
> 
> ?

I think this matches the intent.  As you note above, since the
accessible tree is:

  
      +- get-data
      +- datastore
      +- // other data node siblings of datastore
      +- // top-level data nodes of all modules

the context node for the "when" statement in the "choice" is supposed
to be "get-data".

This also makes it consistent with augment:

  augment /get-data/input {
choice origin-filters {
  when 'derived-from-or-self(datastore, "ds:operational")';
  ...
}
  }



/martin

Re: [netmod] 答复: FW: a question about ietf-hardware yang module

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Jun 28, 2019 at 09:52:20AM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Jun 27, 2019 at 10:04:50PM +0200, Martin Bjorklund wrote:
> > > > Juergen Schoenwaelder  wrote:
> > > > > On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bjorklund wrote:
> > > > > > > Yes, good point, I think the phrase "by a different hardware
> > > > > > > component" should be removed. It seems last-change should change 
> > > > > > > when
> > > > > > > I unplug a component and I plug it back shortly after, i.e., a
> > > > > > > component is replaced by itself. So we have:
> > > > > > > 
> > > > > > > "The last time a new hardware component has been added to 
> > > > > > > the
> > > > > > >  '/hardware/component' list, or a hardware component has 
> > > > > > > been
> > > > > > >  removed from the '/hardware/component' list, or a 
> > > > > > > hardware
> > > > > > >  component in the '/hardware/component' list has been
> > > > > > >  replaced."
> > > > > > 
> > > > > > I think that this is still not clear what it means that a component
> > > > > > has been replaced.  Do you mean "replaced by a different hardware
> > > > > > component"?
> > > > > > 
> > > > > > Otherwise (unplug then plug in the same component), the system 
> > > > > > either
> > > > > > detects the removal and thus updates last-change, or it doesn't 
> > > > > > detect
> > > > > > the quick removal/insertion, and then it can't do anything.  Thus, I
> > > > > > don't think this case needs special treatment, and the text could be
> > > > > > just:
> > > > > > 
> > > > > >  "The last time a new hardware component has been added to 
> > > > > > the
> > > > > >   '/hardware/component' list, or a hardware component has 
> > > > > > been
> > > > > >   removed from the '/hardware/component' list."
> > > > > >
> > > > > 
> > > > > The question is whether every implementor will figure out that if the
> > > > > component found in some slot x-y-z is different from what is expected
> > > > > to be in slot x-y-z, this must be seen as a remove + add combination.
> > > > > If we include 'replace', then it may be clearer that even in the case
> > > > > where what is in slot x-y-z has changed, the last-change must be
> > > > > updated. (That is, the list element with the same name still exists
> > > > > but it is different from what was there before with the same name.)
> > > > 
> > > > But then we're back to where we started - what exactly does "different
> > > > from what was there before" mean?  Presumably that some leaf's value
> > > > is different...?
> > > >
> > > 
> > > Go back some emails, I have removed the 'different' phrase.
> > 
> > Perhaps we can say:
> > 
> >[...] or a hardware
> >component in the '/hardware/component' list has been
> >replaced with a new hardware component with the same
> >name.
> >
> 
> Do we want last-change to be updated when a component gets unplugged
> and put back, i.e., a component got replaced with itself?
> 
> Can last-change be used to detect that something messed around with
> the components (or a component is connected via a bad line)? Or is
> last-change more strictly for the set of components has changed?
> 
> If I remove a component and I put it back slowly enough, I might get
> two last-change updates (the removal and the addition). If a client
> polls even more slowly, it will see that last-change has changed but
> it will find the same components. Hence, it seems reasonable to not
> exclude a replacement or a component with itself since it is a matter
> of the time resolution with which changes are detected and reported
> via the operational datastore.

Agreed.


/martin

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

Re: [netmod] 答复: FW: a question about ietf-hardware yang module

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Jun 27, 2019 at 10:04:50PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bjorklund wrote:
> > > > > Yes, good point, I think the phrase "by a different hardware
> > > > > component" should be removed. It seems last-change should change when
> > > > > I unplug a component and I plug it back shortly after, i.e., a
> > > > > component is replaced by itself. So we have:
> > > > > 
> > > > > "The last time a new hardware component has been added to the
> > > > >  '/hardware/component' list, or a hardware component has been
> > > > >  removed from the '/hardware/component' list, or a hardware
> > > > >  component in the '/hardware/component' list has been
> > > > >  replaced."
> > > > 
> > > > I think that this is still not clear what it means that a component
> > > > has been replaced.  Do you mean "replaced by a different hardware
> > > > component"?
> > > > 
> > > > Otherwise (unplug then plug in the same component), the system either
> > > > detects the removal and thus updates last-change, or it doesn't detect
> > > > the quick removal/insertion, and then it can't do anything.  Thus, I
> > > > don't think this case needs special treatment, and the text could be
> > > > just:
> > > > 
> > > >  "The last time a new hardware component has been added to the
> > > >   '/hardware/component' list, or a hardware component has been
> > > >   removed from the '/hardware/component' list."
> > > >
> > > 
> > > The question is whether every implementor will figure out that if the
> > > component found in some slot x-y-z is different from what is expected
> > > to be in slot x-y-z, this must be seen as a remove + add combination.
> > > If we include 'replace', then it may be clearer that even in the case
> > > where what is in slot x-y-z has changed, the last-change must be
> > > updated. (That is, the list element with the same name still exists
> > > but it is different from what was there before with the same name.)
> > 
> > But then we're back to where we started - what exactly does "different
> > from what was there before" mean?  Presumably that some leaf's value
> > is different...?
> >
> 
> Go back some emails, I have removed the 'different' phrase.

Perhaps we can say:

   [...] or a hardware
   component in the '/hardware/component' list has been
   replaced with a new hardware component with the same
   name.


/martin

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

Re: [netmod] 答复: FW: a question about ietf-hardware yang module

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Jun 27, 2019 at 09:52:56PM +0200, Martin Bjorklund wrote:
> > > Yes, good point, I think the phrase "by a different hardware
> > > component" should be removed. It seems last-change should change when
> > > I unplug a component and I plug it back shortly after, i.e., a
> > > component is replaced by itself. So we have:
> > > 
> > > "The last time a new hardware component has been added to the
> > >  '/hardware/component' list, or a hardware component has been
> > >  removed from the '/hardware/component' list, or a hardware
> > >  component in the '/hardware/component' list has been
> > >  replaced."
> > 
> > I think that this is still not clear what it means that a component
> > has been replaced.  Do you mean "replaced by a different hardware
> > component"?
> > 
> > Otherwise (unplug then plug in the same component), the system either
> > detects the removal and thus updates last-change, or it doesn't detect
> > the quick removal/insertion, and then it can't do anything.  Thus, I
> > don't think this case needs special treatment, and the text could be
> > just:
> > 
> >  "The last time a new hardware component has been added to the
> >   '/hardware/component' list, or a hardware component has been
> >   removed from the '/hardware/component' list."
> >
> 
> The question is whether every implementor will figure out that if the
> component found in some slot x-y-z is different from what is expected
> to be in slot x-y-z, this must be seen as a remove + add combination.
> If we include 'replace', then it may be clearer that even in the case
> where what is in slot x-y-z has changed, the last-change must be
> updated. (That is, the list element with the same name still exists
> but it is different from what was there before with the same name.)

But then we're back to where we started - what exactly does "different
from what was there before" mean?  Presumably that some leaf's value
is different...?


/martin

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

Re: [netmod] 答复: FW: a question about ietf-hardware yang module

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Jun 27, 2019 at 04:59:08PM +0200, Martin Bjorklund wrote:
> > 
> > Sounds reasonable.  But what exactly does "replaced by a different
> > component" mean?  Presumably it has the same name, but something else
> > is different.
> >
> 
> Yes, good point, I think the phrase "by a different hardware
> component" should be removed. It seems last-change should change when
> I unplug a component and I plug it back shortly after, i.e., a
> component is replaced by itself. So we have:
> 
> "The last time a new hardware component has been added to the
>  '/hardware/component' list, or a hardware component has been
>  removed from the '/hardware/component' list, or a hardware
>  component in the '/hardware/component' list has been
>  replaced."

I think that this is still not clear what it means that a component
has been replaced.  Do you mean "replaced by a different hardware
component"?

Otherwise (unplug then plug in the same component), the system either
detects the removal and thus updates last-change, or it doesn't detect
the quick removal/insertion, and then it can't do anything.  Thus, I
don't think this case needs special treatment, and the text could be
just:

 "The last time a new hardware component has been added to the
  '/hardware/component' list, or a hardware component has been
  removed from the '/hardware/component' list."


/martin

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

Re: [netmod] 答复: FW: a question about ietf-hardware yang module

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Jun 27, 2019 at 02:13:03AM +, Fengchong (frank) wrote:
> > > 
> > > I think the ambiguity is 'list changed' - does this mean that list 
> > > entries are added/removed or does it include also the case where a 
> > > property of a list entry has changed.
> > 
> > Ok.  Yes it is supposed to mean entry added/removed/modified.
> > 
> > But I can see another unclear thing - suppose I augment in an addtional 
> > leaf from my own model into this list.  Should last-change be updated if 
> > this new leaf is changed?
> > 
> 
> A reasonable interpretation in my view is that hardware/last-change is
> updated whenever
> 
> (1) a hardware component has been added
> (2) a hardware component has been removed
> (3) a hardware component has been replaced by a different hardware component
> 
> Here is an attempt for a new description:
> 
>  "The last time a new hardware component has been to the
   ^
added


>   '/hardware/component' list, or a hardware component has
> been removed from the '/hardware/component' list, or a
>   hardware component in the '/hardware/component' list has
>   been replaced by a different hardware component."
> 
> The point is to define this based on the events that cause the set of
> components to change instead of discussing leaf value changes.

Sounds reasonable.  But what exactly does "replaced by a different
component" mean?  Presumably it has the same name, but something else
is different.


/martin

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

Re: [netmod] ?= ?==?utf-8?q? mandatory choice with non-presence container cas

[Martin Bjorklund]

Michal Vaško  wrote:
> Hi Rob,
> actually, I have used model with the container TOP just for
> simplification, I have encountered the issue while implementing
> ietf-ssh-server model from its current draft. I have created the
> container "users" [1] without any "user" list instances. Now, you may
> argue that this is still not a valid use-case because there are no
> users but I only tried to satisfy the condition.

Yes, I think that this list (user) should have a "min-elements 1".  I
think that matches the intent.


/martin



> There are some users
> on the system but they are generated into the configuration on-demand
> when operational data is requested.
> 
> Regards,
> Michal
> 
> [1]
> https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-14#page-22
> 
> On Tuesday, June 25, 2019 11:08 CEST, "Rob Wilton (rwilton)"
>  wrote:
>  
> > Hi Michal,
> > 
> > It is not the printing of the data that makes it valid/invalid.
> > 
> > I don't think that your input data was ever valid, because "container
> > C" doesn't satisfy the mandatory statement because it isn't a real
> > data node in the tree - it is instantiated when required and may be
> > deleted when it is no longer required.
> > 
> > I.e. your model has been designed such that it can never be satisfied.
> > 
> > 
> > If your model was instead:
> > 
> > container TOP {
> >   leaf L {
> > type empty;
> >   }
> >   choice A {
> > mandatory true;
> > container C {
> >   leaf L2 {
> > type empty;
> >   }
> > }
> >   }
> > }
> > 
> > 
> > Then this data is valid:
> > 
> > 
> >   
> >   
> >
> >   
> > 
> > 
> > 
> > But this data is not:
> > 
> > 
> >   
> > 
> > 
> > 
> > Nor is this, which is directly equivalent to the one above, because
> > the  container doesn't really exist if it doesn't have a child
> > node present.
> > 
> > 
> >   
> >   
> > 
> > 
> > Thanks,
> > Rob
> > 
> > 
> > > -Original Message-
> > > From: Michal Vaško 
> > > Sent: 24 June 2019 18:15
> > > To: Andy Bierman 
> > > Cc: Rob Wilton (rwilton) ; netmod 
> > > Subject: Re: [netmod] ?= mandatory choice with non-presence container
> > > cas
> > > 
> > > Hi Andy,
> > > 
> > > On Monday, June 24, 2019 19:11 CEST, Andy Bierman 
> > > wrote:
> > > 
> > > > On Mon, Jun 24, 2019 at 10:01 AM Michal Vaško 
> > > > wrote:
> > > >
> > > > > Hi Rob,
> > > > > I think there is a problem in the RFC because using only allowed
> > > > > steps I got invalid data from initially valid data. That cannot be
> > > correct.
> > > > >
> > > > >
> > > > No.  See sec. 7.5.7
> > > >
> > > >If a non-presence container does not have any child nodes, the
> > > >container may or may not be present in the XML encoding.
> > > >
> > > >
> > > > Just because your retrieval does not contain the NP-container, that
> > > > does not mean the NP-container was not present in the server for the
> > > > mandatory-stmt validation.
> > > 
> > > I agree, but these valid data were correctly printed into invalid
> > > data. I
> > > do not think printing is allowed to change the validity of data.
> > > 
> > > Michal
> > > 
> > > >
> > > > Regards,
> > > > > Michal
> > > > >
> > > > >
> > > > Andy
> > > >
> > > >
> > > > > On Monday, June 24, 2019 18:52 CEST, "Rob Wilton (rwilton)" <
> > > > > rwil...@cisco.com> wrote:
> > > > >
> > > > > > Hi Michal,
> > > > > >
> > > > > > My thoughts:
> > > > > >
> > > > > > According to 7.5.1:
> > > > > >
> > > > > >In the first style, the container has no meaning of its own,
> > > existing
> > > > > >only to contain child nodes.  In particular, the presence of the
> > > > > >container node with no child nodes is semantically equivalent to
> > > the
> > > > > >absence of the container node.  YANG calls this style a "non-
> > > presence
> > > > > >container".  This is the default style.
> > > > > >
> > > > > > Hence your request (because the NP container does not have any
> > > > > > children)
> > > > > is equivalent to:
> > > > > >
> > > > > >  
> > > > > >
> > > > > >  
> > > > > >
> > > > > > which fails the "mandatory" check.
> > > > > >
> > > > > > Thanks,
> > > > > > Rob
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: netmod  On Behalf Of Michal Vaško
> > > > > > > Sent: 24 June 2019 17:39
> > > > > > > To: netmod 
> > > > > > > Subject: [netmod] mandatory choice with non-presence container
> > > > > > > case
> > > > > > >
> > > > > > > Hi,
> > > > > > > I have encountered a situation that I think is not covered by
> > > > > > > RFC
> > > > > 7950. My
> > > > > > > specific use-case was as follows.
> > > > > > >
> > > > > > > model:
> > > > > > >
> > > > > > > container TOP {
> > > > > > >   leaf L {
> > > > > > > type empty;
> > > > > > >   }
> > > > > > >   choice A {
> > > > > > > mandatory true;
> > > > > > > container C;
> > > > > > >   }
> > > > > > > }
> > > > > > >
> > > > > > > data:
> > > > > > >
> > > > > > > 
> > > > > > >   
> > > > > > >   
> 

Re: [netmod] ?= ?==?utf-8?q? mandatory choice with non-presence container cas

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Kent Watsen  writes:
> 
> > Hi Michal,  
> >> I agree, but these valid data were correctly printed into invalid
> >> data. I do not think printing is allowed to change the validity of
> >> data.
> >  The NP-container text is unclear.
> 
> This issue IMO has more to do with the "mandatory" statement under
> "choice". Similar problems can be caused by data nodes that depend on
> "when". For example:
> 
> choice sel {
>madatory true;
>leaf foo {
>when "...";
>...
>}
>leaf bar { ... }
>leaf baz { ... }
> 
> If "foo" exists in instance data but its when condition becomes false,
> the server is expected to remove the "foo" instance, but what next?
> The data becomes invalid, but the server can hardly include "bar" or
> "baz" on its own.

Right, so that change (that would make the when condition false) will
be rejected by the server, since the resulting config would be
invalid.



/martin




> 
> Lada
> 
> > I'm unsure if you saw the thread in NETCONF, but I filed this issue
> > over the weekend.  Please add to it, if only to include a link to this
> > thread: https://github.com/netmod-wg/yang-next/issues/88. Thanks, Kent
> > ___ netmod mailing list
> > netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] FW: a question about ietf-hardware yang module

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Tue, Jun 25, 2019 at 09:13:51AM +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > I don't understand what is unclear about the current descriptions.  Is
> > it the relations to the MIB objects that are unclear or is it the
> > descriptions in the YANG module?  The original question was:
> > 
> >   My question is whether only configuration change of hardware
> >   component will cause the update of /hardware/last-change?
> > 
> > The answer is clearly "no", since /hardware/last-change says:
> > 
> > "The time the '/hardware/component' list changed in the
> >  operational state.";
> > 
> > and this list has e.g.:
> > 
> >When the server detects a new hardware component, it
> >initializes a list entry in the operational state.
> > 
> > So it is clear that if a hardware component is added (not a
> > configuration change) this list is changed, and last-change is
> > updated.
> 
> I think the ambiguity is 'list changed' - does this mean that list
> entries are added/removed or does it include also the case where a
> property of a list entry has changed.

Ok.  Yes it is supposed to mean entry added/removed/modified.

But I can see another unclear thing - suppose I augment in an
addtional leaf from my own model into this list.  Should last-change
be updated if this new leaf is changed?


> The relationship to
> entLastChangeTime is also not clear to me.

Perhaps that's why it isn't listed in the table ;-)


/martin


> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
> 

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

Re: [netmod] FW: a question about ietf-hardware yang module

[Martin Bjorklund]

Hi,

I don't understand what is unclear about the current descriptions.  Is
it the relations to the MIB objects that are unclear or is it the
descriptions in the YANG module?  The original question was:

  My question is whether only configuration change of hardware
  component will cause the update of /hardware/last-change?

The answer is clearly "no", since /hardware/last-change says:

"The time the '/hardware/component' list changed in the
 operational state.";

and this list has e.g.:

   When the server detects a new hardware component, it
   initializes a list entry in the operational state.

So it is clear that if a hardware component is added (not a
configuration change) this list is changed, and last-change is
updated.


/martin


Juergen Schoenwaelder  wrote:
> On Mon, Jun 24, 2019 at 07:14:18PM -0700, Andy Bierman wrote:
> > On Mon, Jun 24, 2019 at 6:59 PM Fengchong (frank) <
> > frank.fengch...@huawei.com> wrote:
> > 
> > > Andy,
> > >
> > > Can you clarify this question?
> > >
> > >
> > >
> > 
> > Since state-last-changed seems to cover state data changing, last-change
> > seems to apply to
> > the operational value of the config=true nodes in the /hardware/component
> > subtree
> > 
> > Andy
> >
> 
> It could be that the intention was that ietf-hardware:last-change
> matches ENTITY-MIB:entLastChangeTime, which has this description (see
> RFC 6933):
> 
> "The value of sysUpTime at the time a conceptual row is
> created, modified, or deleted in any of these tables:
> - entPhysicalTable
> - entLogicalTable
> - entLPMappingTable
> - entAliasMappingTable
> - entPhysicalContainsTable
> "
> 
> If so, ietf-hardware:last-change should change whenever the an element
> in the hardware/component list changes, e.g., pluggable hardware is
> added or removed.
> 
> If this interpretation is correct, then an entry in the table "YANG
> Data Nodes and Related ENTITY-MIB Objects" is missing. Anyway, the
> description of ietf-hardware:last-change is obviously not precise
> enough and this thread should perhaps lead to an errata if we find
> agreement what the intention here was.
> 
> /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

Re: [netmod] Yang Schema mount implementation

[Martin Bjorklund]

Balazs Lengyel  wrote:
> Hello,
> 
> Who has implemented YANG schema mount? Are there SW tools already
> implementing it?

We have implemented YANG schema mount in our NSO product.


/martin

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

Re: [netmod] regular expression flavours (again)

[Martin Bjorklund]

Robert Varga  wrote:
> On 12/06/2019 11:25, Juergen Schoenwaelder wrote:
> > That said, they do seem to declare something like
> > oc-ext:regexp-posix; but it would have been much smarter to use for
> > example oc-posix:regex instead of changing the semantics of the
> > pattern statement.
> 
> Yes, this would be preferable, but it has a downside: now you need to
> carry the patterns twice and must make sure they are in sync.

In the OC models they would/could just use the oc-posix:regex statement, and
not even use the pattern statement.

The current solution doesn't really work, since it requires tools to
understand the "regexp-posix" extension.

And yes, I'm the first to admit that tailf:action had the same kind of
problem.


/martin

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

Re: [netmod] Ip layer statistics in Yang ?

[Martin Bjorklund]

Hi,


Karen Elisabeth Egede Nielsen  wrote:
> Hi Steve, All
> 
> I hope that you may advice on this issue.
> 
> I am looking for the YANG modeling of the IP "interface" statistics
> (aka RFC4293) and stumbled over the now expired individual
> contribution
> https://tools.ietf.org/html/draft-baill-netmod-yang-ip-stats-01
> which does not seem to have progressed.
> 
> RFC8343 refers to RFC2863.
> Is it correctly understood that the RFC8343 refers to the network
> layer interfaces only and would not attempt to cover the IP layer
> statistics ?

Yes.  For additional IP-specific statistics, something like the model
in the draft above is needed.



/martin



> Or is it alternatively so that in an interface layering model it is
> intended for that RFC4383 would model IP layer statistics also (with
> the granularity provided of RFC8343, which
> does not go to the same level of detail as RFC4293/the draft above).
> 
> Many Thanks in advance
> 
> BR, Karen
> 
> 

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

Re: [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

[Martin Bjorklund]

Hi,

Qin Wu  wrote:
> I think what they are looking for in RFC7950 is generic overridden
> rule, i.e., a parent node statement can be overridden by its child
> node substatement.

See Per's reply to the netmod list.  In summary, in this case you
should do:

  container priority {
leaf value {
  type uint8;
  default 64;
}
container level-1 {
  leaf value {
type uint8;
description
  "If not configured, use the value of ../../value.";
  }
}
container level-2 {
  leaf value {
type uint8;
description
  "If not configured, use the value of ../../level-1/value.";
  }
}
  }



/martin




> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen
> Schoenwaelder
> 发送时间: 2019年6月9日 23:28
> 收件人: Xufeng Liu 
> 抄送: l...@ietf.org; NETMOD WG 
> 主题: Re: [netmod] A question on the parameter overriding in
> draft-ietf-isis-yang-isis-cfg
> 
> Hi,
> 
> YANG does not have 'levels'. This seems to be an ISIS specific
> question you should ask on the ISIS list.
> 
> /js
> 
> On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:
> > In Section 2.3. and many other locations, the current IS-IS model 
> > applies the parameter overriding rule as below:
> > 
> > [Quote]:
> > 
> > 2.3
> > .
> > Per-Level Parameters
> > 
> > 
> >Some parameters allow a per level configuration.  In this case, the
> >parameter is modeled as a container with three configuration
> >locations:
> > 
> >o  a top-level container: corresponds to level-1-2, so the
> >   configuration applies to both levels.
> > 
> >o  a level-1 container: corresponds to level-1 specific parameters.
> > 
> >o  a level-2 container: corresponds to level-2 specific parameters.
> > 
> >+--rw priority
> >|  +--rw value? uint8
> >|  +--rw level-1
> >|  |  +--rw value?   uint8
> >|  +--rw level-2
> >| +--rw value?   uint8
> > 
> >Example:
> > 
> >
> >250
> >
> >100
> >
> >
> >200
> >
> >
> > 
> >An implementation SHOULD prefer a level specific parameter over a
> >level-all parameter.  As example, if the priority is 100 for the
> >level-1, 200 for the level-2 and 250 for the top-level configuration,
> >the implementation should use 100 for the level-1 and 200 for the
> >level-2.
> > 
> > [End of Quote]
> > 
> > 
> > In the model, all three value leaves above have a default statement 
> > “default 64”, which brings up my question for the following example:
> > 
> > 
> >
> >250
> >
> >100
> >
> >
> > 
> > 
> > The user does not provide a configured value for level-2. According to
> > Section 7.6.1. of RFC7950, because the default value is in use, “the 
> > server MUST operationally behave as if the leaf was present in the 
> > data tree with the default value as its value”. This means the 
> > priority value for level-2 will be 64 (the default value), so the 
> > value 250 can never take effect as intended in the above quoted
> > Section 2.3.
> > 
> > 
> > Is my understanding correct?
> > 
> > 
> > Since this is a generic question, I am CC’ing NETMOD WG too.
> > 
> > 
> > Thanks,
> > 
> > - Xufeng
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> 
> Hi Martin,
> 
> Thanks for your review.
> 
> 
> > I have reviewed draft-ietf-netmod-artwork-folding-02, and here are my
> > comments:

[...]

> >  The algorithm talks specifically about space (' ') rather than
> >  whitespace.
> 
> True and, FWIW, this was the only instance of the word "whitespace" in
> the document.
> 
> However, I wonder if there might be an issue lurking here.  Already
> the algorithm eliminates the potential for TAB, and implicitly
> eliminates NL and CR through the use of the word "line", but I wonder
> if there are other characters that we wish to skip
> over... e.g. vertical tab?

No.

[...]

> > o  7.1.2 / 7.2
> > 
> >  I would prefer if the format is defined with descriptive text,
> >  rather than with an algorithm.  It is the end result that matters,
> >  not which algorithm an implementation uses to get to the result.
> > 
> >  I suggest the algorithm is moved to an appendix, and/or a sentence
> >  is added that explains that the algorithm is just an example.
> 
> OLD:
> 
>This section describes the process for folding and unfolding long
>lines when they are encountered in a single instance of text content.
>It is assumed that another process inserts/extracts the individual
>text content instances to/from an Internet-Draft or RFC.  For
>example, the `xiax` utility [xiax] does this.
> 
> 
> NEW:
> 
>This section describes a process for folding and unfolding long lines
>when they are encountered in text content.
> 
>The steps are complete, but implementations MAY achieve the same
>result in other ways.
> 
>When a larger document contains multiple instances of text content
>that may need to be folded or unfolded, it is assumed that another
>process inserts/extracts the individual text content instances to/
>from the larger document prior to utilizing the algorithms described
>in this section.  For example, the `xiax` utility [xiax] does this.

Well, again I don't really understand why we need to assume _anything_
about how the author decides to implement this format.

I would just remove this paragraph.

> >  Also expand the descriptive text in 7.1.2; I think that the text in
> >  section 6 is probably enough.  However, there are some important
> >  details buried in the desciption of the algorithm; specifically the
> >  cases where SBS can't be used.
> 
> I looked at this for a little while, but didn't see how it could be
> improved.  Can you provide some text?


NEW:

   Lines that have a backslash ('\') occurring as the last character in
   a line are considered "folded", which means that the line continues
   at the first character that is not a space (' ') on the following line.

   Really long lines may be folded multiple times.


On second thought, this text doesn't have to mention when SBS can't be
used.


> > o  7.2.1
> > 
> >  I don't understand why there is a min limit of 46 characters for
> >  folding to work.  If the only reason is for the non-normative script
> >  to be able to center the header line, then I think this limitation
> >  should be removed.  (I would even prefer less flexibility in the
> >  header line syntax...)
> 
> This is because we never defined how to handle folding the header
> itself.  I wrote about this a while back and no-one seemed bothered by
> the limitation.  The effort/value ration isn't there.  The need to
> fold less than 69-characters is unlikely, and less than 46-characters
> seems even more so.

IMO we could remove this arbitrary limitaion and still leave the
header alone.

> > o  7.2.1 / 7.2.2
> > 
> >  I don't think the text should assume that folding/unfolding is
> >  "automated".
> 
> Both sections clearly state that authors may do the equivalent
> manually, or do you mean that the word "automated" in these sections
> isn't adding much value and could/should be removed?

Right:

OLD:

   Folding is assumed to be automated although authors may perform the
   folding steps manually.

   Determine the desired maximum line length from input to the automated
   line-wrapping process,

NEW:

   Determine the desired maximum line length from input to the
   line-wrapping process,




/martin

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

Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> 
> > [RW] 
> > Yes, I think that is better, and probably OK.
> >  
> > I still slightly question “One strategy is based on the time-proven use of 
> > a single backslash ('\') character to indicate where line-folding has 
> > occurred, with the continuation occurring with the first non-space (' ') 
> > character on the next line.”  Because I don’t think that is how ‘\’ 
> > character works, at least in languages such as C.  Specifically, it doesn’t 
> > ignore leading whitespace on the following line, instead it is often used 
> > where that whitespace is not significant to the compiler.
> 
> Would s/time-proven/POSIX/ be better?

If you write POSIX I think you need a reference.  Is there really a
POSIX standard for how a single backslash is used...?

I think "time-proven" is better.


/martin




> 
> BTW, I also added this to Appendix A:
> 
>Shell-level end-of-line backslash ('\') characters have been
>purposely added to the script so as to ensure that the script is
>itself not folded in this document, thus simplify the ability to
>copy/paste the script for local use.  As should be evident by the
>lack of the mandatory header described in Section 7.1.1, these
>backslashes do not designate a folded line, such as described in
>Section 7.
> 
> 
> 
> 
> > [RW] 
> > Perhaps “original text content” -> “exact original text content”?  But I’m 
> > also OK with your suggested text.
> 
> I'm hesitant, because it seems redundant, but it doesn't cause harm, so I 
> added it.
> 
> 
> 
> > [RW] 
> > According to RFC2119, RECOMMENDED is interpreted exactly the same way as 
> > SHOULD.
> 
> Yes, when composing my response before I was going to say that it's a 
> downgrade "(in IMO)", but figured it would require more explanation, which I 
> was hoping to avoid.  But here we are now  ;)   While I'm aware that they 
> carry the same RFC 2119 weight, RECOMMENDED reads softer to me, less 
> commanding, hence my comment.
> 
> 
> 
> >  I still think that SHOULD/RECOMMENDED is too strong.
> 
> I still disagree.Any tie-breakers out there?
> 
> 
> 
> > Good point, how about this?
> >  
> >Scan the text content to ensure no existing lines already end with a
> >backslash ('\') character while the subsequent line starts with a
> >backslash ('\') character as the first non-space (' ') character, as
> >this could lead to an ambiguous result.  If such a line is found, and
> >its width is less than the desired maximum, then it SHOULD be flagged
> >for forced folding (folding even though unnecessary).  If the folding
> >implementation doesn't support forced foldings, it MUST exit.
> >  
> >
> >  
> >For each line in the text content, from top-to-bottom, if the line
> >exceeds the desired maximum, or requires a forced folding, then fold
> >the line by:
> >  
> >  
> > [RW] 
> > OK.
> 
> Great.  BTW, I also added this to Appendix A:
> 
>This script does not implement the "forced folding" logic described
>in Section 8.2.1.  In such cases the script will exit with the
>message:
> 
>  Error: infile has a line ending with a '\\' character
>  followed by a '\\' character as the first non-space
>  character on the next line.  This file cannot be folded.
> 
> 
> 
> 
> Kent // author
> 
> 
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-artwork-folding-02

[Martin Bjorklund]

Hi,

I have reviewed draft-ietf-netmod-artwork-folding-02, and here are my
comments:


o  6

  Perhaps:

  OLD:

   begins at the first non-
   whitespace character on the following line.

  NEW:

   begins at the first character that is not a space character (' ')
   on the following line.


  The algorithm talks specifically about space (' ') rather than
  whitespace.


o  6.1

  s/is exists/exists/


o  6.1 / 6.2

  6.2 says (correctly!):

   It is RECOMMENDED for implementations to first attempt to fold
   content using the single backslash strategy and, only in the unlikely
   event that it cannot fold the input or the folding logic is unable to
   cope with a contingency occurring on the desired folding column, then
   fallback to the double backslash strategy.

  But 6.1 says about the Single Backslash Strategy:

   automation implementations are likely to encounter scenarios that
   will produce errors without special care


  So it 6.1 thinks it is likely that SBS won't work, but 6.2 says it
  is unlikely.  IMO 6.2 is correct - it is extremely unlikely that SBS
  won't work.


o  7.1.2 / 7.2

  I would prefer if the format is defined with descriptive text,
  rather than with an algorithm.  It is the end result that matters,
  not which algorithm an implementation uses to get to the result.

  I suggest the algorithm is moved to an appendix, and/or a sentence
  is added that explains that the algorithm is just an example.

  Also expand the descriptive text in 7.1.2; I think that the text in
  section 6 is probably enough.  However, there are some important
  details buried in the desciption of the algorithm; specifically the
  cases where SBS can't be used.


o  7.2.1

  I don't understand why there is a min limit of 46 characters for
  folding to work.  If the only reason is for the non-normative script
  to be able to center the header line, then I think this limitation
  should be removed.  (I would even prefer less flexibility in the
  header line syntax...)


o  7.2.1 / 7.2.2

  I don't think the text should assume that folding/unfolding is
  "automated".


o  7.2.1

  Perhaps add to bullet 1:

If no such location can be found, then exit (this text content
cannot be folded)


o  7.2.2

  s/maximum../maximum./


o  Appendix A

  Consider using the command "tempfile" instead of /tmp/wip*




/martin

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

Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

[Martin Bjorklund]

tom petch  wrote:
> - Original Message -
> From: "Joe Clarke (jclarke)" 
> Sent: Monday, May 06, 2019 4:11 PM
> >
> > On May 6, 2019, at 08:06, Qin Wu
> mailto:bill...@huawei.com>> wrote:
> >
> > Hi, Chairs:
> > Sorry for late follow up, thanks Jurgen, Andy,Joe, Joel and all others
> for good comments, here is the update based on discussion and suggestion
> on the mailing list
> > The diff is:
> > https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-03
> >
> > Hey, Qin.  I read through the changes, and I have a couple of
> additional comments.
> >
> > First, the term “YANG server” sounds odd to me.  I know what you mean,
> but I haven’t seen this defined before.  Maybe just saying a device or
> host is sufficient?
> 
> Joe
> 
> If you look at the various RFC - YANG, Netconf, NMDA - they all define
> the terms 'client' and 'server'; in the context, 'YANG server' seems
> appropriate.

I agree w/ Joe.  I had the same comment when I read
draft-ietf-netmod-yang-instance-file-format; it uses the term "YANG
server".

I think these documents should import and use the term "server" from
RFC 8342 where it is defined as:

   o  server: An entity that provides access to YANG-defined data to a
  client, over some network management protocol.

Perhaps we should have a term "YANG-based server" or something as an
alias to "server" as defined above.  In some documents the short word
"server" may sound too generic.  But "YANG server" doesn't sound right
to me.


/martin




> 
> Tom Petch
> 
> 
> 
> 
> 
> >
> > When you talk about the datastore to be reset, you list ,
> , and .  You state that each will receive the
> contents of .  The  DS wouldn’t need that.
> I think it would just be zeroed out.
> >
> > I think the RPC should reset any and all non-derived read-write
> datastores and not imply that a specific DS’s contents (i.e., the
> factory-default DS) is copied to them.  This way, other DSes would just
> be handled by this RPC based on implementation.  The 
> can exist as the factory default contents for .
> >
> > Joe
> >
> > We believe it is ready for second adoption poll. Thanks!
> >
> > -Qin (on behalf of authors)
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
> > 发送时间: 2019年4月9日 2:36
> > 收件人: netmod@ietf.org
> > 主题: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
> >
> > This message concludes the adoption poll for
> draft-wu-netmod-factory-default-02   The working group consensus
> supports working on the problem, but fundamental concerns were raised
> regarding the solution, specifically around reseting datastores versus
> resetting devices.  The chairs feel that these issues should be
> addressed before proceeding with the adoption.
> >
> > Authors, please update and resubmit the draft addressing the comments
> received during the adoption poll.  Another adoption poll will be issued
> when ready.
> > Thank you,
> > Kent (and Lou and Joel)
> >
> >
> >
> > On Mar 25, 2019, at 4:34 PM, Kent Watsen
> mailto:kent+i...@watsen.net>> wrote:
> >
> > This email begins a 2-week adoption poll for:
> >
> >
> > https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
> >
> >
> > Please voice your support or objections before April
> 8.
> >
> >
> > Kent (and Lou)
> > ___
> > 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
> >
> 
> ___
> 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] 6021 ipv4-prefix

[Martin Bjorklund]

Kristian Larsson  wrote:
> 
> 
> On 2019-04-25 23:51, Juergen Schoenwaelder wrote:
> > On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
> >>
> >>
> >> On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
> >>> On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
>  On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
> > On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
> > +17.4 is not an integer, so this is an error (not because of the + but
> > because of the . followed by additional digits). +17 is I think a
> > valid
> > integer value but the + will be dropped in the canonical
> > representation.
> 
>  Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion
>  of the
>  prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>  rounded
>  if an integer input is expected?
> >>>
> >>> The non-prefix bits are irrelevant for the prefix and the canonical
> >>> format has the non-prefix bits all set to zero. I understand that you
> >>> prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
> >>> consider this as valid input that can be safely interpreted to mean
> >>> 2001:db8::0/64.
> >>
> >> Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
> >> error, is that implementation incorrect?
> >>
> > I think so. The types do not require that non-prefix bits are zero
> > when a value is received. However, a server must report the canonical
> > value, in this case 2001:db8::/64.
> 
> Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type
> ip-prefix (or ip6-prefix).
> 
> It would be interesting to hear Martins opinion on this.

I did some digging, and it turns out that we had this type internally
before it was part if ietf-inet-types, where we did not require that
all non-prefix bits were zero, but at one point (after
draft-ietf-netmod-yang-types-00 back in 2008) checked in a fix:

  The confd:ipv4Prefix and confd:ipv6Prefix types now require that all
  bits that do not belong to the prefix are set to zero. This is for
  compatibility with the corresponding YANG types defined by the IETF
  NETMOD working group.

You may want to see the threads:

https://mailarchive.ietf.org/arch/msg/netmod/bXL0Mec_ZVVyalmK3pNHkczm6ZI

https://mailarchive.ietf.org/arch/msg/netmod/3Wz5BPgxZajCZloAOjU-ycfr9Lg

Specifically Juergen's proposal:

  Require that all bits that are not part of the prefix are set to
  zero (192.0.2.8/24 becomes an invalid representation of an IPv4
  prefix)

I can't find any discussion in the archive about allowing non-zero non-prefix
bits.  So I think that the original intention was to be strict in
these types.  I agree that the current description text needs
clarification in either case.



/martin

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

Re: [netmod] [Editorial Errata Reported] RFC7950 (5698)

[Martin Bjorklund]

Hi,

This errata is correct and should be accepted.


/martin


RFC Errata System  wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5698
> 
> --
> Type: Editorial
> Reported by: Andy Bierman 
> 
> Section: 7.5.4.3
> 
> Original Text
> -
>  container interface {
>leaf ifType {
>  type enumeration {
>enum ethernet;
>enum atm;
>  }
>}
>leaf ifMTU {
>  type uint32;
>}
>must 'ifType != "ethernet" or ifMTU = 1500' {
>  error-message "An Ethernet MTU must be 1500";
>}
>must 'ifType != "atm" or'
>   + ' (ifMTU <= 17966 and ifMTU >= 64)' {
>  error-message "An ATM MTU must be 64 .. 17966";
>}
>  }
> 
> 
> Corrected Text
> --
>  container interface {
>leaf ifType {
>  type enumeration {
>enum ethernet;
>enum atm;
>  }
>}
>leaf ifMTU {
>  type uint32;
>}
>must 'string(ifType) != "ethernet" or ifMTU = 1500' {
>  error-message "An Ethernet MTU must be 1500";
>}
>must 'string(ifType) != "atm" or'
>   + ' (ifMTU <= 17966 and ifMTU >= 64)' {
>  error-message "An ATM MTU must be 64 .. 17966";
>}
>  }
> 
> 
> Notes
> -
> The intent of the example is for each must-stmt to be false if the ifType 
> leaf does not exist.
> However the XPath is incorrect.
> 
> From the XPath 1.0 spec, section 3.4, para 5
> 
> If one object to be compared is a node-set and the other is a string, then 
> the comparison will be true if and only if there is a node in the node-set 
> such that the result of performing the comparison on the string-value of the 
> node and the other string is true. 
> 
> The empty node-set is not implicitly converted to an empty string for a = or 
> != comparison.
> Instead the string() function must explicitly convert the node-set to a string
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 

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

Re: [netmod] 6991bis: address-with-prefix-length

[Martin Bjorklund]

Kristian Larsson  wrote:
> 
> 
> On 2019-04-18 14:18, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> >> On Thu, Apr 18, 2019 at 10:41:11AM +0200, Ladislav Lhotka wrote:
> >>>>>
> >>>>> I am not in favour of adding this type. Having ip-prefix next to
> >>>>> ip-address-and-prefix is confusing.
> >>>>
> >>>> Confusing or not, they are NOT interchangeable and actually do
> >>>> different
> >>>> things, which is why both are needed. There's plenty of precedence to
> >>>
> >>> I actually agree with you. It is a historical accident that these
> >>> two different things got mixed up (and some vendors contributed to
> >>> this). I would argue that
> >>>
> >>> - IP prefix is a set of IP addresses, and as such can be thought of
> >>>as a single entity.
> >>>
> >>> - IP address and subnet mask/prefix are two separate things, the
> >>>latter being an instruction for routing to *other* destination
> >>>addresses.
> >>
> >> I think we should be pragmatic. There are other common types that are
> >> in fact constructed out of simpler types, date-and-time is a prime
> >> example of a type constructed out of a date value and a time value.
> > I think that date-and-time represents one thing - a single point in
> > time.
> 
> Convenient for users to enter a single point in time in terms of year,
> month, day, hours, minutes and seconds, perhaps. But not as convenient
> for a program that needs to compare two date-and-times.

Actually, *comparing* works quite ok, but calculating diff is not as
easy.

> Clearly for a
> program comparing times against each other we must represent a point
> in time as the number of vibrations of cesium since an arbitrarily
> chosen epoch.

We do have yang:timeticks as well.  In some cases that's a better type
than yang:date-and-time.

> >> is sometimes convenient to treat something that is in fact constructed
> >> as an atomic value.
> > Convenient for users that enter these values, perhaps.  But not as
> > convenient for a program (or a filter) that needs one of the combined
> > values.
> 
> Really? Are you using a text representation of IP addresses when you
> handle them in your program?
> 
> If you are to deal with IP addresses, prefixes etc in a robust way in
> your program, you need an internal datatype that understands what an
> address is - it needs to handle it as bits and massage it to any other
> presentation you want. It needs to understand relevant comparisons and
> operations, like is prefix A contained in prefix B?

I agree.  Note that I wrote *filter* above.  It also extends to
must/when expressions.  The problem is that these mechanisms use
XPath, and XPath is quite limited when it comes to "understanding"
types.  I even wrote a (now expired) draft with a proposed solution:
https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00


> Or if we are dealing with time, then a class that understands leap
> years, leap seconds, time zones etc can be fairly useful so you don't
> have to fall in any of those pitfalls.
> 
> I don't think we choose a format or representation in our YANG models
> primarily to suit the algorithmic needs of a computer program, in that
> case an IPv4 address would just be a uint32 and not the dotted quad
> format we have today.
> 
> 
> >  For example, suppose I want to find all entries with a given
> > prefix; that is non-trivial with a combined ip-address-and-prefix
> > type.
> 
> This seems like a very weird example since it doesn't support your
> case; it is not easier with two separate leaves!?
> 
> The alternative to using ip-address-and-prefix-length would be to use
> two leaves; one for the address and the other for the subnet mask /
> prefix-length.
> 
> combined:
> ip-address-and-prefix-length: 1.2.3.4/24
> 
> split:
> address: 1.2.3.4
> prefix-length: 24
> 
> Say we have another interface with address '1.2.3.5' (prefix-length 24
> still). In what way is it easier to determine these are part of the
> same IP prefix / subnetwork by having the values split in two leaves?

As have been said before in this thread, it is not an address and a
prefix length, it is an address and a prefix.  So the split model
would have a leaf "ip-prefix: 1.2.3.0/24", which can be compared.

> There is no text operation that can easily do this for us - we need to
> parse the values with some class / type in our programming language
> that helps us make this comparison so in what way is
> ip-address-a

Re: [netmod] 6991bis: address-with-prefix-length

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Apr 18, 2019 at 03:14:20PM +0200, Per Hedeland wrote:
> 
> > Agreed - except the not entirely minor nit that the thing after the
> > "/" is not a prefix but a *prefix-length*. Another way of putting it
> > is that the IP address is a property of an interface, while the
> > prefix-length or subnet mask is a property of the network that an
> > interface is connected to.
> 
> The property relevant for the network is the _prefix_, not the
> prefix-length. The prefix-length 12 does not tell the system the
> network prefix that is valid on the link, the prefix tells it. In
> other words, you have a single value that gives you an address and a
> prefix, hence ip-address-and-prefix. The question is whether we name
> it according to the pieces that go into the combined value or whether
> we name it according to the meaning of the combined value. What goes
> in is "address + prefix length" and the meaning is "address + prefix".
> 
> > From a data modelling perspective, having separate leafs for separate
> > values should be the natural choice, and I don't think anyone is
> > suggesting that the "bundled" type, if added, should be used in e.g.
> > RFC 7277. A grouping could be nice, but it is still two separate
> > leafs.
> > 
> > This is no solution to Kristian's problem, which as far as I
> > understand is about having a YANG model for existing devices that
> > already *use* the "bundled" type, i.e. it "needs" to be a single leaf
> > in the YANG module.
> > 
> > Whether this need is enough motivation to actually add these types to
> > ietf-inet-types I don't really know. There is no real cost in doing it
> > per se, but it could have the negative consequence that it is taken as
> > an encouragement/"blessing" to use these types when writing new
> > modules that *don't* "need" to use them. Bad from a data modelling
> > perspectve, and bad for the operational reasons that Martin gave an
> > example of while I was writing this. But maybe the 'description'
> > statement could warn against this.
> 
> Some bundled types are widely used and practically useful. See the uri
> type, which is a big complicated combination of many different pieces.

A uri represents a single entity; a resource.   From RFC 3986:

   A Uniform Resource Identifier (URI) is a compact sequence of
   characters that identifies an abstract or physical resource.

> Yes, filtering for a port number in a uri is likely not easy.

Right, but the port is just one part of the uri syntax for a resource
(for some schemes).  The uri type doesn't represent multiple "things"
(scheme, host, port, etc).  If you use a URI to model a port you have
likely a bad model.  Whereas for the proposed ip-address-and-prefix,
it is clear that you're suppose to use it when you need to model an
ip-address and an ip-prefix.


/martin


> These
> are tradeoffs. The notion that "bundles types" are generally bad is I
> think not true. I am not saying we should make it an art to create
> "bundled types", I am just challenging the idea that they are
> generally bad.
> 
> /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

Re: [netmod] 6991bis: address-with-prefix-length

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Apr 18, 2019 at 02:18:43PM +0200, Martin Bjorklund wrote:
> > 
> > > It
> > > is sometimes convenient to treat something that is in fact constructed
> > > as an atomic value.
> > 
> > Convenient for users that enter these values, perhaps.  But not as
> > convenient for a program (or a filter) that needs one of the combined
> > values.  For example, suppose I want to find all entries with a given
> > prefix; that is non-trivial with a combined ip-address-and-prefix
> > type.
> >
> 
> Syntactically, ip-prefix and ip-address-and-prefix look the same, it
> is all about whether the non-prefix bits carry a meaning or not. Once
> these bits carry a meaning, you argue that this combination is a bad
> idea? Or do you argue that ip-prefix also is a bad idea

No, filtering works b/c ip-prefix has a canonical format.

I argue that in general it is a bad idea to combine two values into
one.


/martin


> (and if so do
> you propose ip-prefix to be deprecated)? And what do we do with url?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
> 

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

Re: [netmod] 6991bis: address-with-prefix-length

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Apr 18, 2019 at 10:41:11AM +0200, Ladislav Lhotka wrote:
> > > > 
> > > > I am not in favour of adding this type. Having ip-prefix next to
> > > > ip-address-and-prefix is confusing.
> > > 
> > > Confusing or not, they are NOT interchangeable and actually do different 
> > > things, which is why both are needed. There's plenty of precedence to
> > 
> > I actually agree with you. It is a historical accident that these
> > two different things got mixed up (and some vendors contributed to
> > this). I would argue that
> >
> > - IP prefix is a set of IP addresses, and as such can be thought of
> >   as a single entity.
> > 
> > - IP address and subnet mask/prefix are two separate things, the
> >   latter being an instruction for routing to *other* destination
> >   addresses.
> 
> I think we should be pragmatic. There are other common types that are
> in fact constructed out of simpler types, date-and-time is a prime
> example of a type constructed out of a date value and a time value.

I think that date-and-time represents one thing - a single point in
time.

> It
> is sometimes convenient to treat something that is in fact constructed
> as an atomic value.

Convenient for users that enter these values, perhaps.  But not as
convenient for a program (or a filter) that needs one of the combined
values.  For example, suppose I want to find all entries with a given
prefix; that is non-trivial with a combined ip-address-and-prefix
type.


/martin

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

Re: [netmod] IANA modules

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund píše v St 10. 04. 2019 v 15:15 +0200:
> > Ladislav Lhotka  wrote:
> > > Martin Bjorklund píše v St 10. 04. 2019 v 14:26 +0200:
> > > > Ladislav Lhotka  wrote:
> > > > > Hi,
> > > > > 
> > > > > in a discussion in the yang-doctors mailing list, Acee noted that
> > > > > IANA probably hasn't yet implemented a procedure for updating YANG
> > > > > modules corresponding to IANA registries
> > > > 
> > > > I think that this is a false alarm.  IANA updates the modules
> > > > according to the process.
> > > > 
> > > > > (such a procedure is
> > > > > specified, e.g., in the IANA Considerations section of RFC 7224). It
> > > > > indeed seems to be the case - for example, a few new interface types
> > > > > have been added recently to
> > > > > 
> > > > > https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
> > > > > 
> > > > > but the module iana-if-type only exists in revision 2014-05-08.
> > > > 
> > > > See
> > > > https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
> > > > 
> > > > The latest version is iana-if-t...@2019-02-08.yang
> > > > 
> > https://www.iana.org/assignments/yang-parameters/iana-if-t...@2019-02-08.yang
> > > > 
> > > > 
> > > > > A part of the problem may be that there is AFAIK no authoritative
> > > > > repository for
> > > > > YANG modules where IANA could put the new revisions.
> > > > 
> > > > See
> > > > https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
> > > > 
> > > > This is the authoritative repo.  IANA gets new YANG modules directly
> > > > from the RFC editor before they are formatted into the ascii RFC.
> > > 
> > > Hmm, but then it is kept pretty secret:
> > > 
> > > - RFC 6020 only specifies the new registry "YANG Module Names" and media
> > types
> > > in IANA Considerations, not this authoritative module repository.
> > 
> > RFC 6020 defines the registry.  IANA maintains the registry.  The link
> > above is the link to this registry.  If you go to iana.org and search
> > for "YANG Module Names" this link is the first to be shown.
> 
> According to RFC 6020, it is "a registry for YANG module and submodule names".
> Maybe I am ignorant, but I really didn't know that complete modules can also 
> be
> retrieved. Also, it seems that only the most recent revision of the iana-*
> modules is kept there.

Right.  So the relevant RFC is really RFC 7224, which defines the
initial version of iana-if-type, and the rules for when to update it.

Technically, there's a new IANA registry called "iana-if-type YANG
Module", which is found here:
https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml


The fact that you can download the other YANG modules is a bonus ;-)


/martin




> 
> > 
> > 
> > > - YANG Catalog doesn't know about the recent revisions of iana-if-type.
> > 
> > That's a completely different issue!
> 
> Of course, but it shows that learning about existing modules & revisions (even
> the standard ones) isn't particularly easy.
> 
> Lada
> 
> > 
> > 
> > /martin
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IANA modules

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund píše v St 10. 04. 2019 v 14:26 +0200:
> > Ladislav Lhotka  wrote:
> > > Hi,
> > > 
> > > in a discussion in the yang-doctors mailing list, Acee noted that
> > > IANA probably hasn't yet implemented a procedure for updating YANG
> > > modules corresponding to IANA registries
> > 
> > I think that this is a false alarm.  IANA updates the modules
> > according to the process.
> > 
> > > (such a procedure is
> > > specified, e.g., in the IANA Considerations section of RFC 7224). It
> > > indeed seems to be the case - for example, a few new interface types
> > > have been added recently to
> > > 
> > > https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
> > > 
> > > but the module iana-if-type only exists in revision 2014-05-08.
> > 
> > See
> > https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
> > 
> > The latest version is iana-if-t...@2019-02-08.yang
> > https://www.iana.org/assignments/yang-parameters/iana-if-t...@2019-02-08.yang
> > 
> > 
> > > A part of the problem may be that there is AFAIK no authoritative
> > > repository for
> > > YANG modules where IANA could put the new revisions.
> > 
> > See
> > https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
> > 
> > This is the authoritative repo.  IANA gets new YANG modules directly
> > from the RFC editor before they are formatted into the ascii RFC.
> 
> Hmm, but then it is kept pretty secret:
> 
> - RFC 6020 only specifies the new registry "YANG Module Names" and media types
> in IANA Considerations, not this authoritative module repository.

RFC 6020 defines the registry.  IANA maintains the registry.  The link
above is the link to this registry.  If you go to iana.org and search
for "YANG Module Names" this link is the first to be shown.


> - YANG Catalog doesn't know about the recent revisions of iana-if-type.

That's a completely different issue!


/martin

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

Re: [netmod] IANA modules

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> in a discussion in the yang-doctors mailing list, Acee noted that
> IANA probably hasn't yet implemented a procedure for updating YANG
> modules corresponding to IANA registries

I think that this is a false alarm.  IANA updates the modules
according to the process.

> (such a procedure is
> specified, e.g., in the IANA Considerations section of RFC 7224). It
> indeed seems to be the case - for example, a few new interface types
> have been added recently to
> 
> https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
> 
> but the module iana-if-type only exists in revision 2014-05-08.

See
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

The latest version is iana-if-t...@2019-02-08.yang
https://www.iana.org/assignments/yang-parameters/iana-if-t...@2019-02-08.yang


> A part of the problem may be that there is AFAIK no authoritative
> repository for
> YANG modules where IANA could put the new revisions.

See
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

This is the authoritative repo.  IANA gets new YANG modules directly
from the RFC editor before they are formatted into the ascii RFC.



/martin

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

Re: [netmod] YAng-Tree for a YANG structure

[Martin Bjorklund]

Hi,

Balázs Lengyel  wrote:
> Hello,
> 
> In draft-ietf-netmod-yang-data-ext the extension structure is
> defined. In my draft about
> instance data format I plan to use this in a YANG model. Kent raised
> the question about
> providing a YANG Tree description of the model.
> 
> Is there any idea how the data nodes inside a yang "structure" should
> be represented in a
> tree?

I suggest just like yang-data:

module: example-module

  structure address-book:
+-- address* [last first]
   +-- last  string
   +-- first string
   +-- street?   string
   +-- city? string
   +-- state?string

I will add text to the draft that defines this.


> Any idea when pyang will be prepared for that?

I have added support for this on the branch feature/yang-structure.
It verifies the grammar and adds the option --tree-print-structures.
It doesn't handle augment-structure yet.


/martin

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

Re: [netmod] Doubts about static routes in RFC 8349

[Martin Bjorklund]

Hi,


Alexander Vainshtein  wrote:
> Martin,
> 
> Lots of thanks for an interesting input.
> 
> I have noticed that Appendix A in RFC
> 8349<https://tools.ietf.org/html/rfc8349#appendix-A>  defines the
> key for static IPv4 and IPv6 unicast routes as
> “destination-prefix”.

Right (to be precise, the key is defined in the YANG models in section
8 and 9).


> draft-ietf-rtgwg-
> yang-rib-extend<https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rib-extend-01>
> claims that it augments the model defined in 8349, therefore, to the
> best of my understanding, it uses the same key for station IPv4 and
> IPv6 unicast routes.

Correct.


> At the same time Appendix A in this draft does not define any keys
> for the read-only RIB.
> 
> Can you explain this controversy?

Not sure there's a controversy.  The static route list is how you
configure static routes, and the RIB is the operational state of all
routes (static and others).  Two different things.

The MIB had a single table to show routes and write routes.  I don't
think the persistency of the routes you wrote into the MIB was
defined; perhaps these can be viewed as being "static".


/martin


> 
> 
> 
> Regards, and lots of thanks in advance,
> 
> Sasha
> 
> 
> 
> Office: +972-39266302
> 
> Cell:  +972-549266302
> 
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> 
> -Original Message-
> From: Martin Bjorklund 
> Sent: Wednesday, April 3, 2019 1:34 PM
> To: Alexander Vainshtein 
> Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
> 
> 
> 
> Hi,
> 
> 
> 
> Alexander Vainshtein 
> mailto:alexander.vainsht...@ecitele.com>> 
> wrote:
> 
> 
> 
> [...]
> 
> 
> 
> > Meanwhile, could you please explain the rationale for changing the
> 
> > data model that has been defined in RFC 4292 (where both the
> 
> > destination prefix and the next hop have been parts of the index in
> 
> > the appropriate MIB table) ?
> 
> >
> 
> > The side effect of this change is that it is not backward-compatible
> 
> > with multiple existing RFC 4292-compliant RIB implementations:
> 
> >
> 
> > -  Retrieval of such a RIB using YANG requires a stateful mapper 
> > that
> 
> >merges multiple RIB entries with the same destination prefix and
> 
> >different “simple” NH into a single entry with the
> 
> >next-hop-list
> 
> 
> 
> Note that the "route" list in the rib doesn't have any keys.  This means that 
> you can report several entries with the same destination prefix.  So I think 
> that this design is compatible with the MIB design.
> 
> 
> 
> 
> 
> 
> 
> /martin
> 
> ___
> 
> This e-mail message is intended for the recipient only and contains 
> information which is 
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this 
> transmission in error, please inform us by e-mail, phone or fax, and then 
> delete the original 
> and all copies thereof.
> ___
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Doubts about static routes in RFC 8349

[Martin Bjorklund]

Hi,

Alexander Vainshtein  wrote:

[...]

> Meanwhile, could you please explain the rationale for changing the
> data model that has been defined in RFC 4292 (where both the
> destination prefix and the next hop have been parts of the index in
> the appropriate MIB table) ?
> 
> The side effect of this change is that it is not backward-compatible
> with multiple existing RFC 4292-compliant RIB implementations:
> 
> -  Retrieval of such a RIB using YANG requires a stateful mapper that
>merges multiple RIB entries with the same destination prefix and
>different “simple” NH into a single entry with the
>next-hop-list

Note that the "route" list in the rib doesn't have any keys.  This
means that you can report several entries with the same destination
prefix.  So I think that this design is compatible with the MIB
design.



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

Re: [netmod] 6991bis: address-with-prefix-length

[Martin Bjorklund]

"Rob Wilton (rwilton)"  wrote:
> Hi Acee,
> 
> Having re-read the thread, I think that "ip-address-prefix" is going
> to be confusing, since I had incorrectly assumed that the type being
> defined was an IP prefix, but as you have pointed out there is already
> a type for that.
> 
> I think that we need to choose this name very carefully or otherwise I
> suspect that folks will accidentally use the wrong type.
> 
> So having the type as "ip-address-and-prefix-length" or
> "ip-addr-and-prefix-len" now seems like a clearer choice to me.

The combined type really specifies (i) an ip address and (ii) an ip
prefix.  The prefix happens to be specified with a length indicator.
So I think the name "ip-address-and-prefix" is the correct one.

> I
> think that I also now agree with Martin that this is really merging
> two values into one leaf.

And for the record (again, perhaps), I think this is a bad idea in
general, and I am not sure an exception is needed in this case.


/martin


> Where is this type going to be used?  Is it only used for configuring
> host address/prefix?  Or are there other uses cases as well?
> 
> Thanks,
> Rob
> 
> 
> > -----Original Message-
> > From: Acee Lindem (acee) 
> > Sent: 02 April 2019 16:52
> > To: Rob Wilton (rwilton) ; Martin Bjorklund
> >  > f.com>; j.schoenwael...@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] 6991bis: address-with-prefix-length
> > 
> > Hi Rob,
> > 
> > On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
> >  > boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
> > 
> > 
> > 
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin
> > Bjorklund
> > > Sent: 02 April 2019 13:47
> > > To: j.schoenwael...@jacobs-university.de
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] 6991bis: address-with-prefix-length
> > >
> > > Juergen Schoenwaelder  wrote:
> > > > If you go back ~20 messages, my proposal was ip-address-prefix,
> > > > ipv4-address-prefix, and ipv6-address-prefix.
> > >
> > > Do we agree that this type really specifies two values in one?  If so
> > > I think
> > the
> > > "and" is useful.
> > 
> > Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
> > 
> > This was my confusion as well since the ipv4-prefix and ipv6-prefix
> > types
> > (ietf-inet-types) have been used when they probably shouldn't have
> > been.
> > Note that they both have the constraint of not allowing the host bits
> > to be set
> > should they should be used in situations like interface address
> > assignment.
> > 
> > Excerpted from RFC6991 ipv4-type definition (note the last sentence):
> >  description
> > "The ipv4-prefix type represents an IPv4 address prefix.
> >  The prefix length is given by the number following the
> >  slash character and must be less than or equal to 32.
> > 
> >  A prefix length value of n corresponds to an IP address
> >  mask that has n contiguous 1-bits from the most
> >  significant bit (MSB) and all other bits set to 0.
> > 
> >  The canonical format of an IPv4 prefix has all bits of
> >  the IPv4 address set to zero that are not part of the
> >  IPv4 prefix.";
> > 
> > So, I think that the names above are probably right, or otherwise if
> > you
> > want the "and" then perhaps it should be
> > "ip-address-and-prefix-length" -
> > which seems clunky?
> > 
> > I think the original suggestion of ipxx-address-prefix would be ok.
> > 
> > Thanks,
> > Acee
> > 
> > Thanks,
> > Rob
> > 
> > 
> > >
> > > Also note that the current text in RFC 6991 says:
> > >
> > >  The ipv4-prefix type represents an IPv4 address prefix.
> > >
> > > so having a type ipv4-address-prefix for something that is not (only)
> > > an
> > > "ipv4 address prefix" is imo confusing.
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > > >
> > > > /js
> > > >
> > > > On Tue, Ap

Re: [netmod] 6991bis: address-with-prefix-length

[Martin Bjorklund]

Hi,

Michael Rehder  wrote:

[...]

> Note also that the ietf pattern regexp are not anchored so
> " junk192.168.1.1"
> and
> "192.168.1.1   "
> Are accepted.

No, this is not correct.  YANG uses the XSD "dialect" of regular
expressions.  In this dialect, all patterns are implicitly anchored.


/martin

> I don't know why they are unanchored. This makes them
> unusable in my view.
> 
> As a result I've written my own regxp and a somewhat elaborate MUST
> clause for canonical format check but a specific type would be better.
> Another perspective is to ensure there is some way to avoid using MUST
> to simply constrain type.
> Has that ever been discussed?
> 
> Thanks
> Mike
> 
> > -Original Message-
> > --
> > 
> > Message: 1
> > Date: Mon, 1 Apr 2019 16:38:34 +0200
> > From: Kristian Larsson 
> > To: netmod@ietf.org
> > Subject: [netmod] 6991bis: address-with-prefix-length
> > Message-ID: <10d3413c-df96-6e7d-df82-5542bb023...@spritelink.net>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> > 
> > Hello,
> > 
> > seeing that 6991 is up for a refresh I wonder if this would be the
> > time to
> > suggest the addition of a type for address-and-prefix-length, for
> > example like
> > 192.0.2.1/24?
> > 
> > I find that it's the most natural way express the address and
> > prefix-length to
> > configure on an interface or for some other use. We currently have an
> > ip-prefix
> > type which allows CIDR style prefixes but since all bits to the right
> > of the mask
> > is to be 0 it is only possible to use for describing the IP prefix /
> > network address
> > itself - not the address of a host in that network.
> > 
> > I actually wish the interface-ip modules would have used a combined
> > leaf for
> > these settings rather than the dual-leaf approach it currently has,
> > but I suppose
> > that ship has sailed :/
> > 
> > Regardless, can we add such a type? Is this the document and time to
> > do it? :)
> > 
> > Kind regard,
> > Kristian.
> > 
> > 
> > 
> > --
> > 
> > Message: 2
> > Date: Mon, 1 Apr 2019 18:13:21 +0200
> > From: Juergen Schoenwaelder 
> > To: Kristian Larsson 
> > Cc: 
> > Subject: Re: [netmod] 6991bis: address-with-prefix-length
> > Message-ID:
> > <20190401161321.seiodlfsmjjvj...@anna.jacobs.jacobs-university.de>
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > This is the right time for this and I would call these
> > ip-address-prefix, ipv4-
> > address-prefix and ipv6-address prefix.
> > 
> > /js
> > 
> > On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
> > > Hello,
> > >
> > > seeing that 6991 is up for a refresh I wonder if this would be the
> > > time to suggest the addition of a type for address-and-prefix-length,
> > > for example like 192.0.2.1/24?
> > >
> > > I find that it's the most natural way express the address and
> > > prefix-length to configure on an interface or for some other use. We
> > > currently have an ip-prefix type which allows CIDR style prefixes but
> > > since all bits to the right of the mask is to be 0 it is only possible
> > > to use for describing the IP prefix / network address itself - not the
> > > address of a host in that network.
> > >
> > > I actually wish the interface-ip modules would have used a combined
> > > leaf for these settings rather than the dual-leaf approach it
> > > currently has, but I suppose that ship has sailed :/
> > >
> > > Regardless, can we add such a type? Is this the document and time to
> > > do it?
> > > :)
> > >
> > > Kind regard,
> > >Kristian.
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> > 
> > 
> > 
> > --
> > 
> > Message: 3
> > Date: Mon, 1 Apr 2019 16:31:12 +
> > From: "Acee Lindem (acee)" 
> > To: Juergen Schoenwaelder ,
> > "Kristian Larsson" 
> > Cc: "netmod@ietf.org" 
> > Subject: Re: [netmod] 6991bis: address-with-prefix-length
> > Message-ID: 
> > Content-Type: text/plain; charset="utf-8"
> > 
> > I believe the "address-" could be omitted from the type
> > identifiers. At least
> > within the routing area, "ipv4-prefix" is unambiguous.
> > Thanks,
> > Acee
> > 
> > ?On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder"
> >  > university.de> wrote:
> > 
> > This is the right time for this and I would call these
> > ip-address-prefix, ipv4-address-prefix and ipv6-address
> > prefix.
> > 
> > /js
> > 
> > On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
> > > Hello,
> > >
> > > seeing that 6991 is up for a refresh I wonder if this 

Re: [netmod] [Technical Errata Reported] RFC7950 (5663)

[Martin Bjorklund]

Ebben Aries  wrote:
> On Mar 19 23:27 PM, Robert Varga wrote:
> > On 19/03/2019 19:12, Rob Wilton (rwilton) wrote:
> > > Hi Ebben,
> > > 
> > > I've always taken the ABNF to list the definitive sub-statements that are 
> > > allowed for the various deviate "add", "replace", or "delete" options.  
> > > Perhaps the RFC could state this more explicitly.  Perhaps raise an issue 
> > > on the YANG Next issue tracker to clarify this 
> > > (https://github.com/netmod-wg/yang-next/issues) and it might get 
> > > discussed tomorrow.
> > 
> > I agree.
> > 
> > Proposed statements are simple cases, for which 'deviate replace' can be
> > used to specify the correct value -- for example remove 'min-elements'
> > by replacing it with 'min-elements 0'.
> 
> Sure - my point was rather that in either case we have an issue.  The
> table of substatements in 7.20.3.2 is either not accurate or we modify
> the grammar to match.

I agree that the document needs clarification, and the yang-next issue
will take care of that.  The document needs a clarification that the
refers to the grammar, or perhaps different substatement tables for
add/replace/delete.

Meanwhile, I think that this errata should be rejected.


/martin




> 'deviate replace' can be used to 'reverse' these
> substatements much like a 'delete' would as you point out but the
> wording in this section should state this - I'll raise an issue on the
> tracker
> 
> FWIW - pyang does not honor the grammar and allows for a mandatory
> substatement of 'deviate delete' while yanglint appears to follow the
> ABNF strictly
> 

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

Re: [netmod] instance data new backward compatibility text

[Martin Bjorklund]

Hi

I agree with Juergen.  I think section 6 should be removed.  This
document should specify the document format (which it does), but it
shouldn't specify specific rules for the different use cases.


/martin


Juergen Schoenwaelder  wrote:
> Your rules are use case specific and I am not convinced they are
> applying to all use cases. It should be a perfectly valid use case to
> store snapshots of  in instance data files. Your rules do not
> make sense here and I do not think this is a valid usage of the SHOULD
> mechanism.
> 
> /js
> 
> On Mon, Mar 25, 2019 at 11:01:52PM +, Balázs Lengyel wrote:
> >Hello Jurgen,
> > 
> >I don't think these rules are Ericsson specific. In some of our most
> >important use-cases (UC1, UC2, UC6) changing the keys would lead to
> >problems.
> > 
> >UC1: If you document server capabilities using ietf-yang-library the name
> >of the module sets may be/should be meaningful. It might be used by the
> >NMS to compare the capabilities of different versions of the YANG server;
> >changing keys without a reason will mislead the NMS into assuming the
> >server capabilities changed..
> > 
> >UC2: Preloading default configuration data. E.g. If you change the
> >identifier of NACM ruleset, then during upgrade it might be loaded again
> >as the server can not detect, that this is the same ruleset that is
> >already in the datastore.
> > 
> >UC6:Â Storing diagnostics data. If you change the keys used in diagnostic
> >data, comparing values before and after the key change will be difficult.
> > 
> >And yes as we were using instance data for the last then years, we did
> >have a lot of problem with people changing the keys without considering
> >compatibility effects.
> >I agree that this is not always a problem, so I only used SHOULDÂ (and 
> > not
> >MUST) in the text.
> > 
> >regards Balazs
> > 
> > 
> >On 2019. 03. 25. 23:16, Juergen Schoenwaelder wrote:
> > 
> >  On Mon, Mar 25, 2019 at 09:59:43PM +, Balázs Lengyel wrote:
> > 
> >  Hello Jurgen,
> > 
> >  You are right that this is important mostly for instance data prepared as a
> >  design/implementation activity; while not relevant for data coming from the
> >  node.
> >  I will add it.
> > 
> >  However in the first case it is vital!
> > 
> >  For config files, and also for file documenting server capabilities we have
> >  had MANY problems with people changing the key values/identities of list
> >  entries.
> >  They think it is a nice idea to provide better, more meaningful key values;
> >  however the NMS designers use these key values to detect changes; also
> >  during an upgrade process if a default configuration file is loaded again
> >  with slightly changed key values, then e.g. access control rules become
> >  duplicated.
> > 
> > 
> >  The conditions under which it is meaningful to change keys and when it
> >  is not appropriate are very application specific.  You may have
> >  specific use cases at Ericsson where you want internal regulations but
> >  I do not think this leads to meaningful rules outside your specific
> >  application scenario.
> > 
> >  /js
> > 
> > 
> >  --
> >  Balazs Lengyel   Ericsson Hungary Ltd.
> >  Senior Specialist
> >  Mobile: +36-70-330-7909  email: 
> > [1]balazs.leng...@ericsson...com
> > 
> > References
> > 
> >Visible links
> >1. mailto:balazs.leng...@ericsson.com
> 
> 
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> 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] Adoption poll for draft-chopps-netmod-geo-location-01

[Martin Bjorklund]

Kent Watsen  wrote:
> This email begins a 2-week adoption poll for:
> 
> https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01
> 
> Please voice your support or objections before April 8.

I support the adoption of this draft.


/martin

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

Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

[Martin Bjorklund]

Kent Watsen  wrote:
> This email begins a 2-week adoption poll for:
> 
> https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00
> 
> Please voice your support or objections before April 8.

I support the adoption of this draft.


/martin

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

Re: [netmod] Comments on instance data draft rev -02

[Martin Bjorklund]

Joe Clarke  wrote:
> First, I agree with Jürgen that the "target" terminology confused me,

+1

> especially so given you have target-module and inline-target-spec.  Like
> Jürgen and Rob said, "schema" seems to work better.

Since we have "content-data", perhaps use "content-schema"?


And a question:  why is the "name" leaf mandatory?


/martin


> And maybe
> "inline-schema-module-spec" would be clearer that the spec modifies the
> modules from which the schema is generated.
> 
> To the point about yang-data-ext/structure, I see instance data was very
> useful, but it's a must to be able to augment its metadata.  YANG
> Catalog would use that.  If this draft moves forward without
> sx:structure, then I think it would need to be straight YANG so that
> augments will work (i.e., a schema element would exist to augment).
> 
> A few other comments (minor):
> 
> Section 2.1:
> 
> "P2 Re-use existing formats similar to the  operation/request"
> 
> Isn't the format similar to a  _response_ versus the request?
> 
> ===
> 
> Section 3
> 
> s/and and/and/
> 
> Joe
> 
> ___
> 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] adoption poll for yang-versioning-reqs-02

[Martin Bjorklund]

Andy Bierman  wrote:
> On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli  wrote:
> 
> >
> >
> > On Mar 22, 2019, at 12:07, Lou Berger  wrote:
> >
> > Hi,
> >
> > Thank you all for the good input on this thread.
> >
> > With the understanding that a 00 working group document is a starting
> > point for the working group rather than a document that is ready for last
> > call - we believe there is sufficient support to adopt this document as a
> > starting point for the requirements we wish to address on this topic.
> >
> > It is clear that there is still work to be done on this document before we
> > can declare consensus on it and, not surprisingly, that there is more work
> > to be done on the solution.
> >
> > Authors,
> >
> > Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00
> > with the only change being the name and publication date.  The -01 version
> > should focus on resolving issues raised during adoption.  Of course the
> > document is subject to normal WG input and processing.
> >
> > Please note the 'file' name change -this is to indicate that the
> > requirements are not presupposing a specific solution. It is also
> > consistent with how versioning is defined within the document currently.
> >
> > Note: we would like to try to continue the list discussion in next week's
> > session and ask the Authors/DT to summarize issues raised during the
> > adoption call and lead a discussion to help resolve these issues.
> >
> > I think this meeting is great opportunity to decide what steps need to be
> > taken to advance the document within the working group.
> >
> > Martin specifically objects to the presence of of Non-Backward-Compatible
> > changes.
> >
> > Many modules outside the IETF are already incompatible with roc 7950 yang
> > 1.1 revision rules. So that cat may be out of the bag at least with respect
> > to the real world. the question remains what to do about that?
> >
> >
> 
> I do not look at the problem as allowing NBC so much as making it clear to
> toolmakers what is going on,
> like a deviation to the versioning rules.
> 
> BTW, I do not support adoption of the requirements document at all.
> I support the work on versioning as part of the charter, and I am happy to
> accept the design team solution draft as the starting point, and just work
> on a solution.
> 
> But I think the solution is a bit flawed.
> 
> 1) extensions are optional and problematic since they can be revisioned
> without changing
> the language version; the solution needs to use new YANG 1.2 statements
> instead of extensions
> 
> 2) the version string does not have to contain all the NBC semantics.
> The solution draft does not show modified semver.
> It should be done differently than overloading the version string;
> 
> Let's say a fork is done on 1.3.0.
> 
>  revision 2017-07-30 {
>description "Added leaf foo-64";
>semver:module-version "1.3.0";
>  }
> 
> start with a legal change, just not at the HEAD
> 
>  revision 2019-01-10 {
>description "Added leaf bar-64";
>semver:module-version "1.3.1";
>  }
> 
> 
> then later, an NBC change
> 
> revision 2019-02-10 {
>description "Changed leaf bar-64 default-stmt";
>semver:module-version "1.3.2";
>semver:nbc-change;
> 
>  }
> 
> then later, a legal change
> 
> revision 2019-03-10 {
>description "Added leaf baz-64";
>semver:module-version "1.3.3";
> 
>  }

+1  I have suggested something similar.

> This is a form of an inline deviation-stmt.
> The YANG update rules are not changing. They are just not being followed.

Right!

> The NBC info belongs in the revision-stmt, not overloading the version string.

Agreed.


> Not every major revision will mean NBC changes anyway.





/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] import-by-semver issue

[Martin Bjorklund]

Andy Bierman  wrote:
> On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Sun, Mar 24, 2019 at 03:14:18PM +, Rob Wilton (rwilton) wrote:
> > >
> > > But that is true of YANG compilers today.  If there are multiple
> > revisions of a module that could be chosen, then each compiler is at
> > liberty to decide which revision to choose (last paragraph of section 5.1.1
> > in RFC 7950).
> > >
> >
> > The difference is that NBC changes are not allowed. As long as you
> > find a certain symbol, it has fixed and predictable semantics.
> >
> > Sorry, but changing the way the import statement works is an NBC
> > change of YANG and this can't be done with extensions.
> >
> >
> I strongly agree.
> The expected behavior for tools needs to be consistent, especially for
> the construction of the schema tree, which depends on the import rules.
> 
> Implementation complexity should matter in the IETF, but it does not.
> Just keep raising the complexity up to 10 and complain that the tools have
> bugs,
> as if the two are unrelated. (Simply looking for a hardwired string
> "semver:version"
> will not work since the prefix is not required to be "semver" in the
> import-stmt.)

Agreed, but it quite easy to first build a prefix map (prefix ->
module name), and then instead of ":semver" you see ("ietf-semver",
"semver"); and _this_ can be hardcoded in the compiler.  (pyang works
like this)

This said, it is a bit weird with:

import ietf-semver {
  prefix "semver";
  semver:version 1.1.2;
}

so in order to handle the "semver:version" statement, you need to
import the module that has the prefix "semver".  But we can't just
import it like a normal import, b/c it has the semver: statement that
modifies how we do imports!



/matrin

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

Re: [netmod] import-by-semver issue

[Martin Bjorklund]

"Rob Wilton (rwilton)"  wrote:
> Hi Juergen,
> 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > Sent: 24 March 2019 15:31
> > To: Rob Wilton (rwilton) 
> > Cc: Andy Bierman ; NetMod WG 
> > Subject: Re: [netmod] import-by-semver issue
> > 
> > On Sun, Mar 24, 2019 at 02:07:15PM +, Rob Wilton (rwilton) wrote:
> > > Hi Andy,
> > >
> > > There are many ways to write and design compilers.
> > >
> > > Compilers that don’t understand import-by-semver just ignore the
> > > extension,
> > no deviation is required.  They just import whichever arbitrary
> > revision that they
> > would have imported anyway, as specified by YANG 1.1.  The
> > import-by-semver
> > statement just reduces the set of valid modules revisions that can be
> > used for
> > import.
> > >
> > 
> > If two compilers (one supporting semver, the other not) resolve
> > imports
> > differently, then the design is in my view somewhat broken, in
> > particular if you
> > allow NBC changes.
> 
> But that is true of YANG compilers today.  If there are multiple
> revisions of a module that could be chosen, then each compiler is at
> liberty to decide which revision to choose (last paragraph of section
> 5.1.1 in RFC 7950).

This is by design, of course.  With an "open" import (not import by
revision), the server implementor is free to implement any set of
modules that work together.

> So, I would argue that "import-by-version" doesn't make YANG compilers
> any less consistent that they are already today, since that
> inconsistency already exists.

I don't think I understand Andy's objection.   I also think that this
is just another implementation detail.

> I presume that the real solution here is to explicitly define the full
> set of implemented, import-only-modules to the compiler so that it
> always compiles a consistent schema.  Perhaps other compilers have
> different ways to solve this problem.
> 
> Note, I also think that YANG library has a similar inconsistency.
> I.e. there is no guarantee that two different compilers will construct
> exactly the same datastore schema from the YANG library output.

Can you elaborate?  Given an instance of YANG library, it should be
clear which set of modules are used.



> I
> think that this is a design bug, but also one that we attempt to
> address in draft-verdt-netmod-yang-semver-00.
> 
> Thanks,
> Rob
> 
> > 
> > /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

Re: [netmod] guidelines for top-level nodes in RFC 8407

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Fri, 2019-03-22 at 10:24 +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > RFC 8407, section 4.10 says:
> > 
> >A mandatory database data definition is defined as a node that a
> >client must provide for the database to be valid.  The server is not
> >required to provide a value.
> > 
> >Top-level database data definitions MUST NOT be mandatory.
> 
> The term "database" is somewhat unclear. Other documents use "datastore".
> 
> > 
> > The objective for this rule is to avoid a situation where a module cannot
> > be loaded w/o providing additional config, or a situation where you
> > can't boot a server w/o additional config.
> 
> In fact, this issue is related to the semantics of a particular datastore. For
> example, mandatory top-level nodes make a very good sense in
> . If I
> remember correctly, the NACM module has some.

Yes I agree.

> > Consider this snippet:
> > 
> >   container top {
> > leaf foo {
> >   type int32;
> >   default 0;
> > }
> > leaf bar {
> >   when '../foo = 42';
> >   mandatory true;
> >   type int32;
> > }
> >   }
> > 
> > 
> > Is /top/bar considered a mandatory top level node?
> 
> Of course it is, as well as the /top, per definition in RFC 7950:
> 
>o  mandatory node: A mandatory node is one of:
> 
>   *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>  statement with the value "true".
> 
>   *  A list or leaf-list node with a "min-elements" statement with a
>  value greater than zero.
> 
>   *  A container node without a "presence" statement and that has at
>  least one mandatory node as a child.

Ok.  So in this case I suppose I can do:

   container top {
 leaf foo {
   type int32;
   default 0;
   must '. != 42 or ../bar' {
 description
   "If foo is 42, then bar must be be set";
   }
 }
 leaf bar {
   when '../foo = 42';
   type int32;
 }
   }

It accomplishes the same thing, but it is less clear.


/martin


> > IMO it doesn't violate the spirit of the rule.  So the question is; is
> > this allowed?
> 
> My answer is that the mandatory property is a syntactic/schema constraint
> whereas "when" should be treated as a semantic rule because its expression has
> to be evaluated on a particular instance. As such, it should not interfere 
> with
> schema constraints including mandatory.
> 
> If the when expression is more complicated (e.g. involves data from
> other modules), it may not be possible to determine just by looking
> at a single module whether an empty datastore is valid or not.
> 
> Even in your trivial example, what if an implementation adds a deviation 
> module
> changing the default for /top/foo to 42?
> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > P.S. the real data model is a potential solution to a problem with
> > ietf-alarms from draft-ietf-ccamp-alarm-module:
> > 
> >   leaf notify-status-changes {
> > type enumeration {
> >   enum all-state-changes {
> > ...
> >   }
> >   enum raise-and-clear {
> > ...
> >   }
> >   enum severity-level {
> > ...
> >   }
> > }
> > default "all-state-changes";
> > description
> >   ...
> >   }
> >   leaf notify-severity-level {
> > when '../notify-status-changes = "severity-level"';
> > type severity;
> > mandatory true;
> > ...
> >   }
> > 
> > 
> > pyang complains that this violates the cited rule.
> > 
> > D.S.
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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