[netmod] Yangdoctors last call review of draft-ietf-netmod-rfc6991-bis-16

[Martin Björklund via Datatracker]

Reviewer: Martin Björklund
Review result: Ready with Nits

Here is my YANG doctor's review of draft-ietf-netmod-rfc6991-bis-16.  


o  typedef email-address

  The domain part of "email-address" is different from the type
  "domain-name".  This looks a bit odd.  If special characters can
  occur in the domain part of an email address, one would assume that
  they can occur in a domain name as well.


o  typedef protocol-number

 "The protocol-number type represents an 8-bit Internet
  protocol number, carried in the 'protocol' field of the
  IPv4 header or in the 'next header' field of the IPv6
  header. If IPv6 extension headers are present, then the
  protocol number type represents the upper layer protocol
  number, i.e., the number of the last next header' field
 ^^^ ' missing
  of the IPv6 extension headers.


o  typedef ipv6-address-and-prefix

 "The ipv6-address-and-prefix type represents an IPv6
  address and an associated ipv4 prefix.

   s/ipv4 prefix/IPv6 prefix/


o  typedef ipv4-address-and-prefix

 "The ipv4-address-and-prefix type represents an IPv4
  address and an associated ipv4 prefix.

   s/ipv4 prefix/IPv4 prefix/


o  "schema node instance"

  This term is used in a few places in ietf-yang-types, for example:

  A schema node instance of this type will be set to zero (0)
  on creation

  This isn't correct, since a schema node is a node in the schema
  tree, and doesn't have a value.  With RFC 7950 terminology, it would
  be "a node in the data tree".  It is unfortunate that there is no
  specific term for this in RFC 7950.

  Perhaps it would be easier to just write "An instance of this
  type...".

  (I know that this was not correct RFC 6991 either)


/martin


___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

Re: [netmod] structured metadata for schema nodes using YANG extensions

[Martin Björklund]

"Jason Sterne (Nokia)"  wrote:
> Thanks Martin.
> 
> I can see how that approach can be used to create a structure of containers 
> and leafs (where each leaf could have a type). So that's helpful for some 
> scenarios.
> 
> I'm not sure how to deal with leaf-lists or lists though.
> 
> If we wanted a leaf-list like this:
>   myext:colors "red green"
> it isn't obvious to me how to extend the approaches in yang-next issue 54 to 
> specify it. I'm also not sure how to specify the format of the "instance 
> data" in the leaf-list or if there is any sort of "right" format for that. In 
> my example I show space separated names (any separator may need escape 
> mechanisms).

A "leaf-list" would be:

  myext:color "red";
  myext:color "green";

It could be specified as:

  extension color {
argument color-name {
  tailf:arg-type {
type enumeration {
  enum red;
  enum green;
}
  }
}
tailf:occurence "*";
  }



> 
> Similarly I'm not sure how a list could work. In theory extension 
> "saturation" could be a substatement of extension "color" and then "color" 
> could have an argument. That could act as a sort of list:

Yes.

But the approach we took was to be able to specify a grammar for
extension statements so that they could express what ordinary YANG can
do, rather than having a way to add "instance data" to a module.


/martin



> 
> extension color {
> argument "color-name";
> }
> extension saturation {
> argument "saturation-level";
> tailf:use-in "myext:color";
> }
> 
> Leaf foo {
> myext:color "red" {
> saturation "45";
> }
> myext:color "blue" {
> saturation "12";
> }
> 
> Maybe another approach is to somehow allow full RFC 9195 instance data to be 
> the argument of an extension, and then also have some way to define the data 
> model of that instance data as part of the extension definition.
> 
> Jason
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: Wednesday, March 13, 2024 5:08 AM
> > To: Jason Sterne (Nokia) 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] structured metadata for schema nodes using YANG
> > extensions
> > 
> > 
> > CAUTION: This is an external email. Please be very careful when clicking 
> > links or
> > opening attachments. See the URL nok.it/ext for additional information.
> > 
> > 
> > 
> > "Jason Sterne \(Nokia\)"  wrote:
> > > Hi all,
> > >
> > > I'm looking for information about doing more complex YANG extensions
> > > that the basic  type, e.g.:
> > > oc-ext:openconfig-version "2.5.0";
> > 
> > See https://github.com/netmod-wg/yang-next/issues/54 for a discussion
> > about one approach.
> > 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > 
> > 
> > 
> > >
> > > The node-tags approach doesn't fit what I'm trying to do (tags can't
> > > have values).
> > >
> > > RFC7950 says the following:
> > >The substatements of an
> > >extension are defined by the "extension" statement, using some
> > >mechanism outside the scope of this specification.  Syntactically,
> > >the substatements MUST be YANG statements, including extensions
> > >defined using "extension" statements.
> > >
> > > Let me start with a simple example and build on it. Say I want to
> > > associate a color with any schema node. That's easy:
> > >
> > > extension color {
> > > argument "color";
> > > description "Takes a value of red, green or blue";
> > > }
> > >
> > > leaf foo {
> > > myext:color "red";
> > > }
> > >
> > > But what if I want a more complex structure for my color metadata like
> > > this?  (a leaf-list and leaf inside a container)
> > >
> > > leaf foo {
> > > myext:chroma-metadata {
> > > myext:colors "red green";
> > > myext:saturation "45";
> > > }
> > >
> > > >From what I can tell, I'd have to define it like this:
> > >
> > > extension chroma-metadata {
> > > }
> > > ex

Re: [netmod] structured metadata for schema nodes using YANG extensions

[Martin Björklund]

"Jason Sterne \(Nokia\)"  wrote:
> Hi all,
> 
> I'm looking for information about doing more complex YANG extensions
> that the basic  type, e.g.:
> oc-ext:openconfig-version "2.5.0";

See https://github.com/netmod-wg/yang-next/issues/54 for a discussion
about one approach.



/martin






> 
> The node-tags approach doesn't fit what I'm trying to do (tags can't
> have values).
> 
> RFC7950 says the following:
>The substatements of an
>extension are defined by the "extension" statement, using some
>mechanism outside the scope of this specification.  Syntactically,
>the substatements MUST be YANG statements, including extensions
>defined using "extension" statements.
> 
> Let me start with a simple example and build on it. Say I want to
> associate a color with any schema node. That's easy:
> 
> extension color {
> argument "color";
> description "Takes a value of red, green or blue";
> }
> 
> leaf foo {
> myext:color "red";
> }
> 
> But what if I want a more complex structure for my color metadata like
> this?  (a leaf-list and leaf inside a container)
> 
> leaf foo {
> myext:chroma-metadata {
> myext:colors "red green";
> myext:saturation "45";
> }
> 
> >From what I can tell, I'd have to define it like this:
> 
> extension chroma-metadata {
> }
> extension colors {
> argument "color-list";
> description "sub-statement of chroma-metadata. Space separated list of
> colors red, green and blue.";
> }
> extension saturation {
> argument "saturation-level";
> description "sub-statement of chroma-metadata";
> }
> 
> Or if I wanted a list like this?
> 
> myext:chroma-metadata {
> myext:color "red" {
> myext:saturation "45";
> }
> myext:color "green" {
> myext:saturation "23";
> }
> }
> 
> I don't think there is any formal way to do it, but could I say that
> the structure of the chroma-metadata follows a grouping I define?
> 
> grouping cm-struct {
> list color {
> leaf saturation { ... }
> }
> }
> 
> Could another option be to just define the top level extension
> chroma-metadata with a single argument, and then describe that the
> argument itself is a json-ietf blob of instance data that conforms to
> YANG grouping xyz?
> 
> Jason (he/him)
> 

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

Re: [netmod] Is changing the type with union a BC change?

[Martin Björklund]

Andy Bierman  wrote:
> Hi,
> 
> On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia)  40nokia@dmarc.ietf.org> wrote:
> 
> > Hi Italo,
> >
> >
> >
> > IMO RFC7950 Section 11 makes the second case NBC (and I remember it being
> > confirmed on this list in the past). It may not turn out to be impactful
> > depending on the client design (and if only XML is used) but officially it
> > is NBC. The type of the leaf is changing from whatever foo is, to type
> > ‘union’.   (even changes from uint8 to uint16 are NBC).
> >
> >
> >
> 
> 
> I think RFC 7950 addresses only XML encoding of YANG data.

RFC 7950 defines a "lexical representation" of types.  This is not
encoding-specific.  However, section 9 says:

   The lexical representation of a value of a certain type is used in
   the XML encoding and when specifying default values and numerical
   ranges in YANG modules.


/martin



> CBOR encoding of a union would cause an NBC change only for protocols using
> CBOR.
> 
> I prefer to focus on the backward compatibility at run-time.
> There are "soft" NBC changes that may break compile-time definitions but
> probably not run-time,
> especially if old-client and new-client are not both changing the same
> configuration data structures.
> 
> 
> The following change is not legal:
> 
> V1:
> 
> 
>  container oldway {}
> 
> 
> V2:
> 
>  choice wrapper {
> container oldway {}
>   }
> 
> 
> The following changes are legal:
> 
> V1:
> 
>  choice wrapper {
>  container oldway {}
>   }
> 
> V2:
> 
>  choice wrapper {
> container oldway {}
> container newway {}
>  }
> 
> This allows old clients and new clients to coexist (better than just
> removing 'oldway').
> But adding the choice wrapper changes the schema node path that may be used
> in augments or deviations.
> Creating the choice from the start would clutter YANG modules and add
> complexity.
> IMO this compile-time NBC change is worth it if enough deployment of
> 'oldway' exists.
> 
> The same applies for a simple type changing to a union type.
> It is not always transparent.  In C the order of the member types is
> irrelevant, but not in YANG.
> 
> Safe (except for CBOR):
> 
> V1:
> 
> leaf foo { type int8; }
> 
> V2:
> 
>leaf foo {
>   type union {
>type int8;
>type declimal64;
>type string;
>}
>}
> 
> Not safe since no member types after 'string' would ever match:
> 
> V1:
> 
> leaf foo { type string; }
> 
> V2:
> 
>leaf foo {
>   type union {
>type string;
>type declimal64;
>type binary;
>}
>}
> 
> IMO it should be OK to to place the original type anywhere in the member
> types.
> It may not be completely transparent within the implementation or the
> message encoding.
> 
> 
> V1:
> 
> leaf foo { type string; }
> 
> new V2:
> 
>leaf foo {
>   type union {
>type declimal64;
>type binary;
>type string;
>}
>}
> 
> If old-client reads new values set by new-client then it may cause a
> problem,
> but probably not if it only reads values set by old-client.
> 
> 
> Some of those sections of 7950 are really focussed on XML encoding. But
> > YANG is intended to work with other encodings (and some of those may not
> > encode foo in and out of a union in the same way).
> >
> >
> >
> 
> They only apply to XML.
> Any extrapolation or new rules are post-7950.
> 
> 
> 
> > Jason
> >
> 
> Andy
> 
> 
> >
> >
> >
> >
> > *From:* Italo Busi 
> > *Sent:* Thursday, January 18, 2024 3:19 PM
> > *To:* Jason Sterne (Nokia) ; Reshad Rahman <
> > res...@yahoo.com>; Jan Lindblad 
> > *Cc:* netmod@ietf.org
> > *Subject:* RE: [netmod] Is changing the type with union a BC change?
> >
> >
> >
> > Hi Reshad, Jason, Jan,
> >
> >
> >
> > Thanks for your replies
> >
> >
> >
> > I have found these pieces of text in sections 9.12 and 11 which might be
> > interpreted as stating that the changes to the union are BC:
> >
> >
> >
> >When generating an XML encoding, a value is encoded according to the
> >
> >rules of the member type to which the value belongs.  When
> >
> >interpreting an XML encoding, a value is validated consecutively
> >
> >against each member type, in the order they are specified in the
> >
> >"type" statement, until a match is found.  The type that matched will
> >
> >be the type of the value for the node that was validated, and the
> >
> >encoding is interpreted according to the rules for that type.
> >
> >
> >
> > <…>
> >
> >
> >
> >The lexical representation of a union is a value that corresponds to
> >
> >the representation of any one of the member types.
> >
> >
> >
> > <…>
> >
> >
> >
> >The canonical form of a union value is the same as the canonical form
> >
> >of the member type of the value.
> >
> >
> >
> > <…>
> >
> >
> >
> >o  A "type" statement may be replaced with another "type" sta

Re: [netmod] Is changing the type with union a BC change?

[Martin Björklund]

Italo Busi  wrote:
> I have some questions/doubts about whether changing a type with union
> is a BC or NBC change
> 
> For example, is the following change a BC or NBC change?
> 
>   OLD
> type union {
>type foo;
>type bar
> }
> 
>   NEW
> type union {
>type foo;
>type bar;
>type baz
> }
> 
> Section 11 of RFC7950 is silent on this case although this change is
> expanding the allowed value space and therefore it looks like a BC
> change

Section 11 says

   o  A "type" statement may be replaced with another "type" statement
  that does not change the syntax or semantics of the type.  For
  example, an inline type definition may be replaced with a typedef,
  but an int8 type cannot be replaced by an int16, since the syntax
  would change.

In this case, the syntax of the type would change, which is not allowed.


/martin

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

Re: [netmod] case + when in 8407bis

[Martin Björklund]

mohamed.boucad...@orange.com wrote:
> Hi Martin,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Martin Björklund 
> > Envoyé : jeudi 14 décembre 2023 21:48
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : netmod@ietf.org
> > Objet : Re: [netmod] case + when in 8407bis
> > 
> > Hi,
> > 
> > 
> > mohamed.boucad...@orange.com wrote:
> > > Hi Martin, all,
> > >
> > > Please remember that RFC8407 includes already the following:
> > >
> > > ==
> > > "when" statement evaluation is generally more expensive than
> > > "if-feature" or "choice" statements ==
> > 
> > Yes, this is fine.  It is something that the module designer can
> > keep in mind when designing the module (actually, the text says
> > "MAY be considered").
> > 
> 
> [Med] ACK for the MAY part. However, that excerpt seems to implicitly
> assume that either a "when" is present or "choice". At least this is
> how I interpret that text. No?

I don't think it should be interpreted that way.  It basically says
that *if* a model can be designed with "if-feature" or "choice"
instead of (an expensive) "when", then it should be considered.  It
doesn't say anything about the combination of "when" and "choice".



/martin

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

Re: [netmod] case + when in 8407bis

[Martin Björklund]

Hi,


mohamed.boucad...@orange.com wrote:
> Hi Martin, all,
> 
> Please remember that RFC8407 includes already the following:
> 
> ==
> "when" statement evaluation is generally more expensive than
> "if-feature" or "choice" statements
> ==

Yes, this is fine.  It is something that the module designer can keep
in mind when designing the module (actually, the text says "MAY be
considered").

> I understand that you may have a concern with the MUST NOT language,
> but we do need some guidance for such constraints. If there are cases
> where having both makes sense, we can transform the MUST NOT to SHOULD
> NOT with a guidance when it is OK to maintain that constraint.

I don't agree that we should have SHOULD NOT either.  It feels very
arbitrary to have such a statement for this particular construct.

To be clear, I think the paragraph:

   Some modules use "case + when" construct such as shown in the example
   below.  Such a construct MUST be avoided by removing the "when"
   statement or using a "container" outside the "choice".

and the example that follows should be removed.


/martin

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

Re: [netmod] case + when in 8407bis

[Martin Björklund]

Hi,

mohamed.boucad...@orange.com wrote:
> Re-, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Martin Björklund 
> > Envoyé : vendredi 8 décembre 2023 17:35
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : netmod@ietf.org
> > Objet : Re: [netmod] case + when in 8407bis
> > 
> > mohamed.boucad...@orange.com wrote:
> > > Re-,
> > >
> > > There was an invitation to review the changes:
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> > archive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F4NDzo7SLinue-
> > CeHGRyOD6aWXHI%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cdeeb
> > 1242f9e74a43da5208dbf80baf06%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> > 0%7C638376501320001779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k4pc
> > 95TknbyhSk4duRn%2Brt6vlTPOchzrsVbFOiuYv4M%3D&reserved=0, but no
> > follow-up.
> > >
> > > Do you have any concern with that part? Thanks.
> > 
> > I do, but I suspect that there is a reason for this rule, so I'd like
> > to understand that.  (I have some faint memory of such a discussion on
> > the list, but I may be wrong).
> > 
> > My objection is (1) why should this legal construct not be used and
> 
> [Med] The reasoning is: What would be intuitive is to see a model use
> either of these approaches rather than both. This questions the need
> for the choice/case statement in the first place.

Ok.  I object to this recommendation.  It is a valid construct, and if
the model designer thinks that the model is best when this consruct is
used, they should be allowed to use it.


/martin




> 
> > (2) I don't think the proposed workaround is correct, since if you
> > move the when to a container that surrounds the entire choice, the
> > other cases in the choice are also made conditional.
> 
> [Med] Actually, that's not what the text intends to say. The proposal
> is to consider getting rid of choice.
> 
> > 
> > 
> > 
> > /martin
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] case + when in 8407bis

[Martin Björklund]

mohamed.boucad...@orange.com wrote:
> Re-,
> 
> There was an invitation to review the changes: 
> https://mailarchive.ietf.org/arch/msg/netmod/4NDzo7SLinue-CeHGRyOD6aWXHI/, 
> but no follow-up.
> 
> Do you have any concern with that part? Thanks.

I do, but I suspect that there is a reason for this rule, so I'd like
to understand that.  (I have some faint memory of such a
discussion on the list, but I may be wrong).

My objection is (1) why should this legal construct not be used and
(2) I don't think the proposed workaround is correct, since if you
move the when to a container that surrounds the entire choice, the
other cases in the choice are also made conditional.



/martin

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

Re: [netmod] URLs from where to retrieve the latest version of an IANA module RE: New guidelines for IANA in draft-ietf-netmod-rfc8407bis

[Martin Björklund]

mohamed.boucad...@orange.com wrote:
> Re-,
> 
> > I cannot find the reference [IANA_FOO_URL].  
> 
> That's normal. That is defined as a generic reference whenever we need
> in the bis to point to the latest version of a module.

The problem is that "[IANA_FOO_URL]" looks like a reference, but it is
not present in the References section.  I can also not find where it
is defined as a generic reference.  Perhaps it should be just
"IANA_FOO_URL" and also defined in section 2?


/martin



> 
> I made the following change to have both the parent link and
> per-revision one:
> 
> ==
> OLD:
>Examples of IANA URLs from where to retrieve the latest version of an
>IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-Types_URL],
>and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to refer
>to such URLs.  These URLs are expected to be sufficiently permanent
>and stable. 
> 
> NEW:
>Examples of IANA URLs from where to retrieve the latest version of an
>IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-Types_URL],
>and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to refer
>to such URLs.  These URLs are expected to be sufficiently permanent
>and stable.  Whenever referencing a specific version of an IANA-
>maintained module is needed, then URLs such as
>[IANA_BGP-L2_URL-Revision] are used.  [IANA_FOO_URL_With_REV] is used
>in the following to refer to such URLs.
> ==
> 
> IANA_FOO_URL can be used in the description, cross-reference purposes,
> and importing any available latest version.
> 
> IANA_FOO_URL_With_REV can be used in revisions or when importing
> specific version of module (for whatever reason).
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Martin Björklund 
> > Envoyé : vendredi 8 décembre 2023 09:07
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : netmod@ietf.org
> > Objet : Re: [netmod] New guidelines for IANA in draft-ietf-netmod-
> > rfc8407bis
> > 
> > Hi,
> > 
> > mohamed.boucad...@orange.com wrote:
> > > Hi Martin,
> > >
> > > Thanks for raising these points.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : netmod  De la part de Martin
> > Björklund
> > > > Envoyé : jeudi 7 décembre 2023 17:05 À : netmod@ietf.org Objet :
> > > > [netmod] New guidelines for IANA in draft-ietf-netmod- rfc8407bis
> > > >
> > > > Hi,
> > > >
> > > > There has been some discussion with IANA on the YANG doctors list
> > > > regarding this text in section 4.8 in RFC 8407:
> > > >
> > > >A "revision" statement MUST be present for each published
> > version
> > > > of
> > > >the module.  The "revision" statement MUST have a "reference"
> > > >substatement.  It MUST identify the published document that
> > > > contains
> > > >the module.
> > > >
> > > > (the same text is present in rfc8407bis)
> > > >
> > > > It continues with the motivation behind the rule:
> > > >
> > > >Modules are often extracted from their original
> > > >documents, and it is useful for developers and operators to
> > know
> > > > how
> > > >to find the original source document in a consistent manner.
> > > >
> > > > As can be seen in e.g.,
> > > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> > 2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C8778e705b2e34e99790
> > 808dbf7c4c75c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63837619675
> > 3722174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> > JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fxf8A2Rg8DoawhFAJqe
> > xoKe%2BReEruxK23PK1BYY5UAQ%3D&reserved=0.
> > > > iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> > > > type%402023-11-
> > > >
> > 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d
> > > > 4a
> > > >
> > e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383
> > > > 75
> > > >
> > 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > > > uM
> > > >
> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu
&g

[netmod] case + when in 8407bis

[Martin Björklund]

Hi,

rfc8407bis has this text:

   Some modules use "case + when" construct such as shown in the example
   below.  Such a construct MUST be avoided by removing the "when"
   statement or using a "container" outside the "choice".

 case yang-datastore {
   when 'derived-from-or-self(ex:source-type, "ex:yang-datastore")';
   description
 "Example data source for local or remote YANG datastore.";
   ...
 }

Can you point me to the discussion about this?  I searched the archives
but didn't find anything.


/martin


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

Re: [netmod] New guidelines for IANA in draft-ietf-netmod-rfc8407bis

[Martin Björklund]

Hi,

mohamed.boucad...@orange.com wrote:
> Hi Martin,
> 
> Thanks for raising these points. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : netmod  De la part de Martin Björklund
> > Envoyé : jeudi 7 décembre 2023 17:05
> > À : netmod@ietf.org
> > Objet : [netmod] New guidelines for IANA in draft-ietf-netmod-
> > rfc8407bis
> > 
> > Hi,
> > 
> > There has been some discussion with IANA on the YANG doctors list
> > regarding this text in section 4.8 in RFC 8407:
> > 
> >A "revision" statement MUST be present for each published version
> > of
> >the module.  The "revision" statement MUST have a "reference"
> >substatement.  It MUST identify the published document that
> > contains
> >the module.
> > 
> > (the same text is present in rfc8407bis)
> > 
> > It continues with the motivation behind the rule:
> > 
> >Modules are often extracted from their original
> >documents, and it is useful for developers and operators to know
> > how
> >to find the original source document in a consistent manner.
> > 
> > As can be seen in e.g.,
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> > type%402023-11-
> > 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d4a
> > e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638375
> > 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu03
> > Z6hne6g16fU405pTiLPhv5gZYZV4k%3D&reserved=0,
> > this rule has not been followed.
> > 
> > The discussion ended with the recommendation to IANA to always add a
> > "reference" statement that refers to the published module (e.g.,
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > iana.org%2Fassignments%2Fyang-parameters%2Fiana-dns-class-rr-
> > type%402023-11-
> > 08.yang&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ccf5ad65dd26d4a
> > e3a1f508dbf73e4f79%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638375
> > 619746432780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X6s86KFMCkdu03
> > Z6hne6g16fU405pTiLPhv5gZYZV4k%3D&reserved=0).
> > 
> > If people agree that this is the correct solution, I think we should
> > update 8407bis with this.
> > 
> > Specifically, I suggest to change 4.30.3.1 and 4.30.3.2:
> > 
> > OLD:
> > 
> > When the "iana-foo" YANG module is updated, a new "revision"
> > statement with a unique revision date must be added in front of the
> > existing revision statements.
> > 
> > NEW:
> > 
> > When the "iana-foo" YANG module is updated, a new "revision"
> > statement with a unique revision date must be added in front of the
> > existing revision statements.  The "revision" statement must have a
> > "reference" substatement that to the published module (e.g.,
> >  ...)
> > 
> > 
> 
> [Med] Looks reasonable to me. As you can see in the proposed PR 
> (https://github.com/boucadair/rfc8407bis/pull/31/files) I went with a 
> slightly modified wording because we do already have the following to refer 
> to the link to be used:
> 
>Examples of IANA URLs from where to retrieve the latest version of an
>IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-Types_URL],
>and [IANA_BFD_URL].  [IANA_FOO_URL] is used in the following to refer
>to such URLs.  These URLs are expected to be sufficiently permanent
>and stable.

I cannot find the reference [IANA_FOO_URL].  If we assume that it is
similar to [IANA_PW-Types_URL], it would be:

   https://www.iana.org/assignments/iana-foo/iana-foo.xhtml

This points to the "meta" page for the module, which has a pointer to
the latest version of the YANG module.

I don't think it makes sense to put this URL in the "reference"
statement in each revision, b/c it would be:

  revision 2023-04-01 {
reference
  "https://www.iana.org/assignments/iana-foo/iana-foo.xhtml";;
  }
  revision 2022-04-01 {
reference
  "https://www.iana.org/assignments/iana-foo/iana-foo.xhtml";;
  }
  revision 2020-04-01 {
reference
  "https://www.iana.org/assignments/iana-foo/iana-foo.xhtml";;
  }

The proposal was to use the url to the module its

[netmod] New guidelines for IANA in draft-ietf-netmod-rfc8407bis

[Martin Björklund]

Hi,

There has been some discussion with IANA on the YANG doctors list
regarding this text in section 4.8 in RFC 8407:

   A "revision" statement MUST be present for each published version of
   the module.  The "revision" statement MUST have a "reference"
   substatement.  It MUST identify the published document that contains
   the module.

(the same text is present in rfc8407bis)

It continues with the motivation behind the rule:

   Modules are often extracted from their original
   documents, and it is useful for developers and operators to know how
   to find the original source document in a consistent manner.

As can be seen in e.g.,
https://www.iana.org/assignments/yang-parameters/iana-dns-class-rr-t...@2023-11-08.yang,
this rule has not been followed.

The discussion ended with the recommendation to IANA to always add a
"reference" statement that refers to the published module (e.g.,
https://www.iana.org/assignments/yang-parameters/iana-dns-class-rr-t...@2023-11-08.yang).

If people agree that this is the correct solution, I think we should
update 8407bis with this.

Specifically, I suggest to change 4.30.3.1 and 4.30.3.2:

OLD:

When the "iana-foo" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the
existing revision statements.

NEW:

When the "iana-foo" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the
existing revision statements.  The "revision" statement must have a
"reference" substatement that to the published module (e.g.,
https://www.iana.org/assignments/yang-parameters/iana-...@2023-11-08.yang)




Further, some IANA modules use the IETF template for the module's
"description", see e.g.,
https://www.iana.org/assignments/yang-parameters/iana-routing-ty...@2022-08-19.yang.
That module has in its "description":

 This version of this YANG module is part of RFC 8294; see
 the RFC itself for full legal notices.";

But that is not correct.  Other module use this instead:

 The initial version of this YANG module is part of RFC 7224;
 see the RFC itself for full legal notices.";

I think 8407bis should recommend that IANA-maintained modules use this
wording instead.



/martin

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

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Martin Björklund]

What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules

- As it works today; the IETF *has* published bugfixed modules that break the
  rules.  (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible

This would allow 6991bis to update date-and-time to follow the updated
semantics for RFC3339 timestamps (which imo is the only reasonable
thing to do - the consuequences of this change is handled by SEDATE).


/martin

"Jason Sterne (Nokia)"  wrote:
> Hi all,
> 
> At the request of the NETMOD chairs, and on behalf of the YANG Versioning 
> weekly call group, here's a summary of Key Issue #1 for the versioning work 
> (i.e. for the Module Versioning and YANG Semver WGLC).
> 
> We'd like to suggest that the WG has a strong focus on deciding on this 
> specific issue first. Then we'll move on to tackle other key issues. The idea 
> is to try and avoid getting tangled in a web of multiple intertwined issues.
> 
> Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1 or 
> not?
> 
> For now please avoid debating other issues in this thread (e.g. multiple vs 
> single label schemes, whether YANG semver is a good scheme, etc). Let's focus 
> on K1 and work towards a WG decision.
> 
> ###
> K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
> 
> Option 1 - Update RFC7950 to Allow NBC Changes
> ---
> - Module Versioning modifies 7950 to allow NBC changes
> - guidance that NBC changes SHOULD NOT be done (impact to user base)
> - rev:non-backwards-compatible is a YANG extension
> - introduction in published YANG does not impact current tooling (ignored 
> until recognized)
> PROS:
> - address fundamental requirement of this versioning work (requirements doc)
> - allows gradual adoption in the industry. YANG authors can immeditately 
> start publishing with the new extensions.
> - move faster to produce modules in the IETF (accept some errors/iteration)
> - address the liaison from external standards bodies in a reasonable timeframe
> - authors believe work is ready
> - broad vendor support
> - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> CONS:
> - perception that we're "cheating" by not bumping our own spec's version
> - Not fundamentally mandatory for clients or servers using YANG (mandatory 
> for YANG claiming conformance to Module Versioning).
> 
> Option 2 - RFC7950-bis: Publish a new version of the YANG language to allow 
> NBC changes
> ---
> - NBC changes only allowed in a new (future) version of YANG
> - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0)
> - Content = Module Versioning + YANG Semver + very limited YANG NEXT items
> - rev:non-backwards-compatible tag is a language keyword
> - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't 
> been updated
> - TBD how to handle small NBC changes in IETF in the short term (i.e. non 
> conformance to 7950)?
> - RFC6991 bis - change the use/meaning of ip-address (or change datetime)
>   - YANG date-and-time (because of SEDATE date string changes)
> 
> PROS:
> - address fundamental requirement of this versioning work (requirements doc)
> - clear delineation of changes in the YANG language
> - consistent with philosophy that version number changes for significant 
> changes in a spec (avoids concern that YANG is changing without bumping the 
> version of YANG)
> - can do this with mandatory YANG keywords which helps increase conformance 
> to the new rules
> CONS:
> - difficult to roll out in the industry. Tools need upgrading before they 
> won't error on a YANG 1.2 module.
> - Authors can't publish YANG 1.2 until their users have upgraded their tools. 
> Everyone has to move at once.
> - likely large delay in producing the work (unclear what would go into YANG 
> 1.2, may not reach concensus easily on N items)
> - delay in follow up work (Packages, Schema Comparison, Version Selection)
> - continue dominating WG effort for longer (opportunity cost)
> 
> Option 3 - Strict Adherence to Current RFC7950 Rules
> ---
> - IESG will be unable to approve any RFCs that make any changes to IETF YANG 
> modules that don't strictly conform to those rules
> - RFC6991 bis would not be allowed to change the use/meaning of 
> ip-address (or change datetime)
>   - YANG date-and-time couldn't change (related to SEDATE date 
> string changes)
> PROS:
> - clear rules for entire industry including IETF
> CONS:
> - doesn't address agreed/adopted requirements of YANG versioning work
> - incorrect assumption in tool chains, etc that NBC changes don't happen. 
> Silent failures.
> 
> Jason (he/him)
> 

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

"Rob Wilton (rwilton)"  wrote:
> Hi Martin,
> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin Björklund
> > Sent: 07 June 2023 08:22
> > To: rwilton=40cisco@dmarc.ietf.org
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > drafts
> > 
> > Hi,
> > 
> > But the two drafts go way beyond fixing the problem your three
> > examples illustrate.
> [Rob Wilton (rwilton)] 
> 
> The actual goals of this work (i.e., the set of drafts) is aiming to
> address the requirements stated here:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07.
> Although never taken to RFC, I believe was effectively last called and
> achieved WG consensus for the NETMOD WG.  Hopefully the chairs can
> chime in and keep me honest if I'm wrong on this point.
> 
> The shape/structure/content of the drafts is very similar to when
> these documents were adopted in March 2020:
> 
> Your comments on these document at adoption time are here
> (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN8/).
> From that email, it is clear that you didn't support the YANG Semver
> scheme, but my reading is that you were broadly supportive of the YANG
> module versioning draft.
> 
> Here are your review comments of the YANG module versioning draft at
> adoption time:
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKNJgk/
> 
> Here is a thread where you are discussing supporting different
> revision label schemes:
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> 
> I appreciate that everyone has the right to change their mind at any
> point, but as stated previously, I don't think that the shape of the
> solution has really changed substantially since they were adopted.

I'm not sure that I have changed my mind on this topic (but if I have
I view that as a good thing; it means I'm open to new technical
arguments ;-)

I don't think I have ever said that this is important work.  I can
live with optional extension statements that indicate nbc changes, and
even that another optional revision label scheme is used, but I do
think it adds unnecessary complexity.  I do not like "modified
semver", and I see no reason why the current revision-date based
scheme doesn't work for IETF modules.



/martin



>   If the goal is to indicate that non-backwards
> > compatible changes have occured, a single new extension statement
> > could solve that.  (As I probably have stated before, personally I
> > don't think this is necessary).
> 
> That is one goal.  Another is to acknowledge that
> non-backwards-compatible changes will occur, potentially even on
> branches.  Another is to align with the versioning scheme that is
> being broadly used by the industry (but with extensions to support a
> branched history).
>
> >
> > Apart from the updates to RFC 7950 section 11, I am mostly concerned
> > about the additional complexity the "pluggable" revision-label scheme
> > brings.
> [Rob Wilton (rwilton)] 
> 
> It feels like we are somewhat going in circles:
> 
> 1.The original proposal was to embed regular Semver 2.0.0 for the
> version numbers.
> 
> 2. That scheme was extended to what is being labelled as "Yang Semver"
> because regular Semver didn't support some level of branching that the
> vendors require to support customers on older releases over a much
> longer time period.  Semver 2.0.0 works best when the updates are
> always committed to the head of a linear sequence of versions, and if
> a bug needs to be fixed in an older version then the user is forced to
> migrate to the latest version.
> 
> 3. If I recall correctly, you didn't like YANG Semver (and possibly
> not even Semver), and if I also recall correctly from a conversation
> then I think that it is because you envisaged more advanced branching
> schemes and perhaps a version number scheme that follows branch
> history (and hence cannot also contain semantic meaning).  Based on
> that feedback, and an in-person side meeting, we moved to a revision
> label scheme, an nbc-marker, and standardizing a versioning scheme to
> fit into the revision-label scheme separately.  This was all in place
> when these documents were adopted.
> 
> Based on those who are or have participated in the weekly calls, I
> also believe that the solution has reasonable industry support:
>  - Representatives from Cisco, Ericsson, Huawei, Juniper, Nokia have all
>  - participated in the calls at various stages.
>  - Other SDOs (3GPP at lea

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

on of YANG modules among
> vendors, OpenConfig, IETF, and other SDOs strictly followed the rules
> in RFC 7950 then I would probably agree that an update from YANG 1.1
> to YANG 1.2 is needed.  But I think that the reality is that tools
> must handle non-backwards compatible changes frequently happening in
> YANG 1.0 (OpenConfig) and YANG 1.1 YANG modules anyway.  I.e., I don't
> believe that the "YANG 1.1 no breaking change contract" is being
> widely honoured anyway, and instead is being treated as a goal or
> aspiration.  What these documents attempt to do is to move YANG module
> evolution from what we currently have now where clients don't have any
> way of really knowing how a module has evolved and whether they are
> impacted to one that they do, and as part of that process they are
> aiming to update the YANG versioning rules to better reflect how is it
> being deployed and used.
> 
> Hence, as am author, I still of the opinion that the best pragmatic
> path forward is to try and get these documents to a shape where they
> achieve rough consensus and are acceptable to the WG to be published
> now, in the short term, as a good enough solution.  After that point,
> then I think that it would be great for some folks to form an idea on
> a what YANG 1.2/2.0 could look like, but I think that coupling these
> goals together would be a mistake.
> 
> Regards,
> Rob
> 
> // Who doesn't really know which hat he is wearing for this comment,
> but is only trying to do the right thing for the wider industry ...
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Jürgen Schönwälder
> > Sent: 06 June 2023 06:07
> > To: Martin Björklund 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > drafts
> > 
> > On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> > > >
> > > > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > > > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > > > does not add any other new features, then having agreement on such a
> > > > statement will help to steer the process.
> > >
> > > I hope that (i) doesn't happen.  I think it is the proposed changes in
> > > draft-ietf-netmod-yang-module-versioning that require a new YANG
> > > version.  If this new YANG version allows for other versioning schemes
> > > than revision-date, then we can keep the modified semver scheme
> > > outside the core document.
> > >
> > 
> > I consider the module update rules a part of a versioning model. The
> > current update rules were written to support the current versioning
> > model. If we want to support multiple versioning models, then we have
> > to refactor the update rules out of the YANG language specification
> > into separate versioning specifications, i.e., traditional YANG
> > versioning and the new semver versioning. There are some language
> > mechanisms (like the import statement), that have to be flexible
> > enough to support multiple versioning schemes.
> > 
> > Is it worth factoring the versioning model out of the language? I
> > guess the opinions vary widely on this, depending on the dynamics of
> > the software environment people are working in.
> > 
> > /js
> > 
> > --
> > Jürgen Schönwälder  Constructor University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 <https://constructor.university/>
> > 
> > ___
> > 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] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

Jürgen Schönwälder  wrote:
> On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
> > 
> > Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next 
> > design team, asked to produce a limited-scope I-D they think best.  
> > WG-objections of the form "my pet-issue isn't picked-up" should not be used 
> > to fail adoption (or, later, the WGLC).  Of course, objections to how the 
> > specific-issues picked-up were resolved are valid.  The goal being to most 
> > expediently (<1yr) forward the versioning work in a correct 
> > (contract-compliant) manner.  Support?
> >
> 
> I believe the WG chairs should guide more actively here. Back in a
> day, the IETF used WG charters to define the scope of work items and a
> project to produce lets say YANG 1.2 would have been a WG charter
> update. For the charter update, the WG chairs would organize a
> discussion to agree on the scope of the work. While bureaucratic, I
> believe it was useful to work this way since it helped to get
> agreement on the scope of work.
> 
> If the goal is to produce YANG 1.2 which (i) integrates semantic
> versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> does not add any other new features, then having agreement on such a
> statement will help to steer the process.

I hope that (i) doesn't happen.  I think it is the proposed changes in
draft-ietf-netmod-yang-module-versioning that require a new YANG
version.  If this new YANG version allows for other versioning schemes
than revision-date, then we can keep the modified semver scheme
outside the core document.  (I don't like the name "YANG semver",
since it sort of implies that this is something that is required by
YANG the language.)


/martin


> Yes, we will still have to
> sort out what is a bug fix and what is a new feature, but this is
> easier if there is upfront guidance on the scope of the work.
> 
> And the second incredient is a dedicated team to work on such a
> project, which ideally brings the major stakeholders together.
> 
> /js
> 
> -- 
> Jürgen Schönwälder  Constructor 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] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

Andy Bierman  wrote:
> On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen  wrote:
> 
> > As an individual contributor and faithful YANG custodian, I cannot
> > support work that changes YANG-semantics without versioning YANG itself.
> > As Andy wrote before:
> >
> > The only correct way to remove MUST/MUST NOT from the "YANG contract"
> > is to introduce a new YANG language version (1.2), and make a new
> > contract.
> >
> > I want this work to move forward in the form of a quick (limited-scope)
> > rfc7950-bis.  One idea would to support just this YANG-next issue
> > 

I think you meant https://github.com/netmod-wg/yang-next/issues/49.

> > and then mark the
> > versioning extension as "critical".  That said, I believe that an even
> > better versioning-solution can be had if integrated into the YANG-language
> > directly.
> >
> 
> 
> IMO the parsing of YANG files to produce a conceptual data model
> is a critical component of the language itself.  Any statements that
> affect this conversion step MUST be regular statements.
> An extension is (by definition) an external statement that is not part of
> the YANG language.
> Critical extensions are not a good design choice.

I strongly agree.  Allowing the language to drastically change (like
in this example) by just defining a critical extension is not a good
idea.  Basically, anyone can define their own extension that changes
YANG to whatever, and still claim conformance.


> Just add real statements
> instead.
> 
> IMO most of the yang-next issues are not interesting or valuable,
> so a long WG process to go through this entire list is a non-starter.
> 

The problem is that everyone will have their own pet-issues that they
think are critical...


> There are 3 critical changes that need to be made.
>   - change "status" so deprecated and obsolete definitions are
> correct

... for example I don't think this is critical ...

>   - introduce new instance-identifier data type based on RFC 7951 definition
>   - introduce new identityref data type based on RFC 7951 definition

... but I do agree with these!


/martin




> 
> 
> 
> 
> > Kent
> >
> 
> 
> Andy
> 
> 
> >
> >
> > On May 22, 2023, at 6:20 PM, Kent Watsen  wrote:
> >
> > NETMOD WG,
> >
> > The chairs are extending this WGLC by two weeks (now ending June 5) in
> > order to ensure adequate review, since this is important work, and a solid
> > consensus is needed.
> >
> > Kent and Lou
> >
> >
> >
> > On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
> >
> > Dear NETMOD WG,
> >
> > This message begins a joint two-week WGLC for
> > draft-ietf-netmod-yang-semver-11 and
> > draft-ietf-netmod-yang-module-versioning-09
> > ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the
> > direct links to the HTML version for these drafts:
> >
> >  - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
> >  -
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> >
> > 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.  Objections, concerns, and suggestions are also welcomed at
> > this time.
> >
> > Thank you,
> > Kent and Lou (chairs)
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > 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] Unknown bits - backwards compatibility

[Martin Björklund]

Hi,


"Jason Sterne (Nokia)"  wrote:
> Hi Martin,
> 
> If a "description" of a leaf (without a default statement) changes from this:
> 
>   "the absence of this leaf causes the protocol to stay administratively 
> down"
> 
> to this:
> 
>   "the absence of this leaf causes the protocol to go administratively up"
> 
> (with no other changes in the YANG) then IMO it *is* an NBC
> change. The behavior described in a "description" field is
> considered part of the model/API (I've seen many references &
> examples of this over the years in NETMOD/NETCONF discussions).

Absolutely.

But that's not what we disuss in this case.  In this case we have
a leaf that shows "unknown bits", and neither the type nor the leaf
(including descriptions) change during the upgrade.



/martin



> 
> Maybe it becomes more subtle if that behavior change isn't documented in the 
> "description" statement (I'd argue it is still NBC if the server changes that 
> behavior and they should be publishing a new revision of the YANG model/API), 
> but I was proposing that it should in this case.
> 
> Jason
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: Friday, April 14, 2023 4:39 AM
> > To: Jason Sterne (Nokia) 
> > Cc: jh...@pfrc.org; netmod@ietf.org
> > Subject: Re: [netmod] Unknown bits - backwards compatibility
> > 
> > 
> > CAUTION: This is an external email. Please be very careful when clicking 
> > links or
> > opening attachments. See the URL nok.it/ext for additional information.
> > 
> > 
> > 
> > Hi,
> > 
> > I am quite confused after reading this thread, so I had to go back to
> > this first message:
> > 
> > "Jason Sterne (Nokia)"  wrote:
> > > Hi Jeff,
> > >
> > > One topic that came up during the IETF 116 NETMOD meeting was
> > > backwards compatibility.
> > >
> > > >From what I understand, a leaf (e.g. unknown-flags) that uses the
> > > >unknown-bits typedef would never change its definition in YANG. It
> > > >would always be defined as unknown-bits with all 64 bit definitions
> > > >even as more and more bits become "known".  *But* the system would
> > > >suddenly stop reporting bit-0, then bit-1 in that unknown-flags leaf
> > > >as those bits become known.
> > >
> > > Strictly speaking, that should probably be considered an NBC change
> > 
> > Nothing has changed in the data model, so there is no way to mark the
> > _data model_ as NBC.
> > 
> > The server follows the data model, and reports which bits it doesn't
> > understand.  With software updates, this may change over time.  This
> > is simply the semantics of this state leaf.
> > 
> > 
> > /martin

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

Re: [netmod] Unknown bits - backwards compatibility

[Martin Björklund]

Acee Lindem  wrote:
> 
> > On Apr 14, 2023, at 04:39, Martin Björklund  wrote:
> > 
> > Hi,
> > 
> > I am quite confused after reading this thread, so I had to go back to
> > this first message:
> > 
> > "Jason Sterne (Nokia)"  wrote:
> >> Hi Jeff,
> >> 
> >> One topic that came up during the IETF 116 NETMOD meeting was
> >> backwards compatibility.
> >> 
> >>> From what I understand, a leaf (e.g. unknown-flags) that uses the
> >>> unknown-bits typedef would never change its definition in YANG. It
> >>> would always be defined as unknown-bits with all 64 bit definitions
> >>> even as more and more bits become "known".  *But* the system would
> >>> suddenly stop reporting bit-0, then bit-1 in that unknown-flags leaf
> >>> as those bits become known.
> >> 
> >> Strictly speaking, that should probably be considered an NBC change
> > 
> > Nothing has changed in the data model, so there is no way to mark the
> > _data model_ as NBC.
> > 
> > The server follows the data model, and reports which bits it doesn't
> > understand.  With software updates, this may change over time.  This
> > is simply the semantics of this state leaf.
> 
> I agree. Removing the definition of the unknown bit in the second leaf
> for unknown bits is not backward compatible but that isn’t being
> proposed.
> 
> Also, one can define a new bit in an unused position in an
> augmentation - correct?

No, you cannot change the type of a leaf/leaf-list with augment.
Augment can only add new nodes.


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

Re: [netmod] Unknown bits - backwards compatibility

[Martin Björklund]

Hi,

I am quite confused after reading this thread, so I had to go back to
this first message:

"Jason Sterne (Nokia)"  wrote:
> Hi Jeff,
> 
> One topic that came up during the IETF 116 NETMOD meeting was
> backwards compatibility.
> 
> >From what I understand, a leaf (e.g. unknown-flags) that uses the
> >unknown-bits typedef would never change its definition in YANG. It
> >would always be defined as unknown-bits with all 64 bit definitions
> >even as more and more bits become "known".  *But* the system would
> >suddenly stop reporting bit-0, then bit-1 in that unknown-flags leaf
> >as those bits become known.
> 
> Strictly speaking, that should probably be considered an NBC change

Nothing has changed in the data model, so there is no way to mark the
_data model_ as NBC.

The server follows the data model, and reports which bits it doesn't
understand.  With software updates, this may change over time.  This
is simply the semantics of this state leaf.


/martin

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

Re: [netmod] Changing an identity base

[Martin Björklund]

Italo Busi  wrote:
> Martin, Jernej,
> 
> I am a bit confused by your replies
> 
> With a reference to my short example below, are you saying that NEW
> (B) provides an NBC change while NEW (A) provides a BC change for OLD?

I'm saying that A is allowed according to RFC 7950, but B is not
allowed.  And as you have demonstrated, this is a bug.

(But you have also demonstrated the workaround!)


/martin


> 
> Actually , this is exactly the result I have got by testing NEW (A)
> and NEW (B) with pyang
> 
> However, if I am not mistaken, based on section 7.18.2 of RFC7950, NEW
> (A) seems equivalent to NEW (B): if identity B (baz) is derived from A
> (foo) and C (bar) is derived from B (baz), then C (bar) is also
> derived from A (foo) ...
> 
> Italo
> 
> > -Original Message-
> > From: Jernej Tuljak 
> > Sent: martedì 31 gennaio 2023 08:19
> > To: Martin Björklund 
> > Cc: Italo Busi ; netmod@ietf.org
> > Subject: Re: [netmod] Changing an identity base
> > 
> > On 30/01/2023 11:17, Martin Björklund wrote:
> > > Hi,
> > >
> > >
> > > Jernej Tuljak  wrote:
> > >> On 30/01/2023 10:19, Italo Busi wrote:
> > >>> Yes, the intention is not to change the semantic of bar but to
> > >>> introduce a more “restricted” identity from which bar could be
> > >>> derived
> > >>>
> > >>> Something like introducing an identity for italian-car in between
> > >>> car and Ferrari identities
> > >>>
> > >> I understand your intention. I do not understand the intention behind
> > >> text in RFC 7950, however.
> > >>
> > >> My clarification request was aimed at RFC 7950 authors and whether a
> > >> revision like this could be considered as not changing the semantics
> > >> of the original identity definition because:
> > >>
> > >>     Otherwise, if the semantics of any previous definition are
> > >> changed
> > >>     (i.e., if a non-editorial change is made to any definition other
> > >> than
> > >>     those specifically allowed above), then this MUST be achieved by
> > >> a
> > >>     new definition with a new identifier.
> > >>
> > >> So, RFC authors: Is "NEWB:bar" definition semantically equivalent to
> > >> "OLD:bar" definition?
> > > I think that this change isn't allowed according to RFC 7950, but it
> > > should have been.  If there ever is a new version of YANG, this should
> > > be fixed.
> > >
> > > The quoted text says:
> > >
> > >if a non-editorial change is made to any definition other
> > >than those specifically allowed above, then this MUST be achieved
> > > by a
> > >    new definition with a new identifier
> > >
> > > This is a non-editorial change that is not "specifically allowed
> > > above".
> > 
> > That has been my interpretation as well so far. Our tools were
> > implemented
> > accordingly. I believe that the Pyang plugin also reports an error for
> > a change
> > like this.
> > 
> > Jernej
> > 
> > >
> > > /martin
> > >
> > >
> > >
> > >> Jernej
> > >>
> > >>> Italo
> > >>>
> > >>> *From:* Jernej Tuljak 
> > >>> *Sent:* lunedì 30 gennaio 2023 08:51
> > >>> *To:* Italo Busi ; netmod@ietf.org
> > >>> *Subject:* Re: [netmod] Changing an identity base
> > >>>
> > >>> On 27/01/2023 17:54, Italo Busi wrote:
> > >>>
> > >>>  According to section 11 of RFC7950, the following change is
> > >>>  considered BC:
> > >>>
> > >>>     o  A "base" statement may be added to an "identity" statement.
> > >>>
> > >>>  Since, as explained in section 7.18.2 of RFC7950, the derivation
> > >>>  of identities is transitive, my understanding is that replacing a
> > >>>  "base" statement with new  "base" statement which is derived from
> > >>>  the previous one is also a BC change.
> > >>>
> > >>>  Considering the example below, the NEW (A) change is BC according
> > >>>  to section 11

Re: [netmod] Changing an identity base

[Martin Björklund]

Hi,


Jernej Tuljak  wrote:
> On 30/01/2023 10:19, Italo Busi wrote:
> >
> > Yes, the intention is not to change the semantic of bar but to
> > introduce a more “restricted” identity from which bar could be derived
> >
> > Something like introducing an identity for italian-car in between car
> > and Ferrari identities
> >
> 
> I understand your intention. I do not understand the intention behind
> text in RFC 7950, however.
> 
> My clarification request was aimed at RFC 7950 authors and whether a
> revision like this could be considered as not changing the semantics
> of the original identity definition because:
> 
>    Otherwise, if the semantics of any previous definition are changed
>    (i.e., if a non-editorial change is made to any definition other
> than
>    those specifically allowed above), then this MUST be achieved by a
>    new definition with a new identifier.
> 
> So, RFC authors: Is "NEWB:bar" definition semantically equivalent to
> "OLD:bar" definition?

I think that this change isn't allowed according to RFC 7950, but it
should have been.  If there ever is a new version of YANG, this should
be fixed.

The quoted text says:

  if a non-editorial change is made to any definition other
  than those specifically allowed above, then this MUST be achieved by a
  new definition with a new identifier

This is a non-editorial change that is not "specifically allowed
above".


/martin



> 
> Jernej
> 
> > Italo
> >
> > *From:* Jernej Tuljak 
> > *Sent:* lunedì 30 gennaio 2023 08:51
> > *To:* Italo Busi ; netmod@ietf.org
> > *Subject:* Re: [netmod] Changing an identity base
> >
> > On 27/01/2023 17:54, Italo Busi wrote:
> >
> > According to section 11 of RFC7950, the following change is
> > considered BC:
> >
> >    o  A "base" statement may be added to an "identity" statement.
> >
> > Since, as explained in section 7.18.2 of RFC7950, the derivation
> > of identities is transitive, my understanding is that replacing a
> > "base" statement with new  "base" statement which is derived from
> > the previous one is also a BC change.
> >
> > Considering the example below, the NEW (A) change is BC according
> > to section 11 of RFC7950. However, NEW (B) is equivalent to NEW
> > (A), since the new baz is derived from foo, and therefore it is
> > also a BC change.
> >
> > Is my understanding correct?
> >
> >
> > I'd like a clarification regarding this as well.  Is "NEWB:bar"
> > definition semantically equivalent to "OLD:bar" definition?
> >
> > Jernej
> >
> >
> > Thanks, Italo
> >
> > OLD
> >
> > identity foo {}
> >
> > identity bar {
> >
> >   base foo;
> >
> > }
> >
> > NEW (A)
> >
> > identity foo {}
> >
> > identity baz {
> >
> >   base foo
> >
> > }
> >
> > identity bar {
> >
> >   base foo;
> >
> >   base baz;
> >
> > }
> >
> > NEW (B)
> >
> > identity foo {}
> >
> > identity baz {
> >
> >   base foo
> >
> > }
> >
> > identity bar {
> >
> >   base baz;
> >
> > }
> >
> >
> >
> > ___
> >
> > 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] Use of unrestricted string in YANG

[Martin Björklund]

Hi,

Italo Busi  wrote:

> BTW, what about using uri for key leafs (see for example RFC8345)?
>
> I think there are other cases where uri could be an appropriate type
> to use for a key …

This is fine if the leaf really is an URI.  Note that no examples in
RFC 8345 have valid uris.  (A uri must have a valid scheme followed by
a ":").  IMO using inet:uri for the keys in RFC 8345 was a mistake.


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

Re: [netmod] naming scope of a grouping which uses a grouping

[Martin Björklund]

tom petch  wrote:
> From: Martin Björklund 
> Sent: 19 December 2022 12:18
> To: tom petch
> 
> tom petch  wrote:
> > draft-ietf-opsawg-sap-12
> > defines a grouping sap-list which uses grouping sap-entry.  The groupings 
> > are intended for import by service specific modules.  The uses does not 
> > include a prefix; should it?
> 
> From a YANG perspective this is correct.  Since it references a
> grouping in the local module, the prefix is optional.
> 
> 
> But it will not be the local module when it is used in other modules which is 
> the only reason it is a grou[ing

It doesn't matter how sap-list is used; it is well-defined in the
module ietf-sap-ntw.  See section 5.4 in RFC 7950.


/martin


> 
> module ietf-sap-vpn
>  prefix sap-vpn
> import ietf-sap-ntw 
>  prefix sap
> container sap-l2vpn
> 
> list l2vpn-service
>  uses sap:sap-list
> .
> 
> Does it need to know where to find sap-entry which sap-list 'uses' without a 
> prefix?
> 
> Tom Petch
> 
> > The module also has my favourite YANG construct, an unrestricted string as 
> > a YANG key.
> 
> I don't think that this is a problem.  Or rather, if the theory is
> that we need to have restricted length on strings b/c otherwise an
> implementation may run out memory, then I don't think this solves that
> problem.  But perhaps there is some other reason?
> 
> 
> /martin
> 
> >
> > Copying Martin as he performed a YANG Doctor review earlier in 2022.
> >
> > Tom Petch

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

Re: [netmod] naming scope of a grouping which uses a grouping

[Martin Björklund]

tom petch  wrote:
> draft-ietf-opsawg-sap-12
> defines a grouping sap-list which uses grouping sap-entry.  The groupings are 
> intended for import by service specific modules.  The uses does not include a 
> prefix; should it?

>From a YANG perspective this is correct.  Since it references a
grouping in the local module, the prefix is optional.

> The module also has my favourite YANG construct, an unrestricted string as a 
> YANG key.

I don't think that this is a problem.  Or rather, if the theory is
that we need to have restricted length on strings b/c otherwise an
implementation may run out memory, then I don't think this solves that
problem.  But perhaps there is some other reason?


/martin

> 
> Copying Martin as he performed a YANG Doctor review earlier in 2022.
> 
> Tom Petch

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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

[Martin Björklund]

Andy Bierman  wrote:
> On Mon, Dec 5, 2022 at 2:37 PM Jürgen Schönwälder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Mon, Dec 05, 2022 at 08:19:12PM +, Kent Watsen wrote:
> > >
> > >
> > > Hi Juergen,
> > >
> > >
> > >
> > > >> 3) There are two "time-with-zone-offset" typedefs (one should be
> > "time-without-zone-offset"?)
> > > >
> > > > No, I only see one.
> > >
> > > My bad, I didn't see the subtype.
> > >
> > > But I may've been thrown off by the following "no-zone" types...should
> > they be named consistently?
> > >
> > >- date-no-zone  -->  date-no-zone-offset  or  date-without-zone-offset
> > >- time-no-zone  -->  time-no-zone-offset  or  time-without-zone-offset
> >
> > The 'no-zone' indicates no zone information, neither by offset nor by zone
> > name.
> >
> > >
> > > >> 4) Is the "-offset" postfix needed?  Or maybe remove the "-zone" part
> > and only have "-offset"?
> > > >
> > > > As noted on a private communication, I looked at what some of the more
> > > > modern programming language libraries do. So let me shre this here:
> > > >
> > > > * Python (datetime)
> > > >
> > > >  They distinguish 'aware' and 'naive' dates.
> > > >
> > > >Date and time objects may be categorized as "aware" or "naive"
> > > >depending on whether or not they include timezone information.
> > > >[...]
> > > >An aware object represents a specific moment in time that is not
> > > >open to interpretation.
> > > >[...]
> > > >For applications requiring aware objects, datetime and time
> > > >objects have an optional time zone information attribute, tzinfo,
> > > >that can be set to an instance of a subclass of the abstract
> > > >tzinfo class. These tzinfo objects capture information about the
> > > >offset from UTC time, the time zone name, and whether daylight
> > > >saving time is in effect.
> > > >
> > > >  Note that there is both a zone offset and a zone name. Note that a
> > > >  zone name may resolve to different offsets depending on the timezone
> > > >  rules in effect at a given point in time.
> > > >
> > > > * Rust (chrono)
> > > >
> > > >  They also distinguish between aware and naive:
> > > >
> > > >Chrono is timezone-aware by default, with separate timezone-naive
> > > >types.
> > > >[...]
> > > >DateTime is timezone-aware and must be constructed from the
> > > >TimeZone object, which defines how the local date is converted to
> > > >and back from the UTC date. There are three well-known TimeZone
> > > >implementations [...].
> > > >
> > > >  My reading of their documentation is that their TimeZone object
> > > >  essentially resolves to an offset, not a timezone name.
> > > >
> > > > In some contexts, it may be useful to think in terms of
> > > > 2022-12-05@[Europe/Berlin] rather than 2022-12-05+01:00 (in particular
> > > > if you keep daylight saving times in your mind or changes of offsets)
> > > > and to be clear that we currently only model offsets, I decided for
> > > > the longer and more explicit name date-with-zone-offset (as there was
> > > > some push towards longer and more precise type names).
> > > >
> > > > For interested parties, there is also work in the IETF on adding
> > > > names to the RFC3339 format:
> > > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
> > > >
> > > > They discuss formats like 2022-07-08T00:14:07+01:00[Europe/Paris] and
> > > > then go into the details if the name and offset are inconsistent etc.
> > >
> > >
> > > "Offsets" are good (regional names would be too involved, IMO)
> >
> > Zone offsets change for certain locations regularly (daylight saving
> > times) and this is why many user facing interfaces configure time zone
> > locations by letting the user select a zone name like Europe/London
> > that then maps via the IANA timezone database rules to the specific
> > zone offsets.
> >
> > > My thought is only to shorten the names.  e.g., time-with-zone-offset
> > --> time-with-offset?  If it doesn't make sense, semantically, then no
> > worries keeping as is.
> >
> > Some what descriptive names, some want names to be future proof,
> > others want names that match names used elsewhere, then some prefer
> > short names, its obviously difficult. Initially we had date (with an
> > optional zone offset) plus date-no-zone without it. This matchedthe
> > good old date-and-time (which also has an optional zone offset).
> >
> > > >> 2) no deprecation of the legacy "*-address" types?
> > > >
> > > > Since there was no consensus to change (and break) definitions, I
> > > > thought we agreed to simply make no changes and to keep what we have.
> > >
> > >
> > > This was discussed at 115, on slide #8 here:
> > https://datatracker.ietf.org/meeting/115/materials/slides-115-netmod-1-session-intro-wg-status-00
> > .
> > >
> > > Lou and I are trying to break the logjam, and no one objected, so it's
> > fine to proceed now.  What I'd do:
> > >
> > >  

Re: [netmod] YANG augmentation in notification

[Martin Björklund]

Hi,

Alex Huang Feng  wrote:
> Dear NETMOD WG,
> 
> Some time ago I sent this email to the YANG doctors to check with
> them. I would also like to have your insights on mandatory augmented
> leaves.
> 
> We are working on a YANG module for the following draft:
> https://datatracker.ietf.org/doc/draft-tgraf-netconf-yang-notifications-versioning/
> 
> In this draft, we are augmenting a notification container in the YANG
> module adding new leaves.
> We would like to have some of these leaves mandatories if the current
> YANG is used but are having an error code using the pyang compiler
> (error: cannot augment with mandatory node "revision-label”).
> 
> The resulting YANG tree without the mandatory statement is the
> following:
> module: ietf-yang-push-metadata
> 
>   augment /yp:push-update:
> +--ro module? string
> +--ro namespace?  string
> +--ro revision?   rev:revision-date-or-label
> +--ro revision-label? ysver:version
> +--ro datastore-xpath-filter? yang:xpath1.0 {sn:xpath}?
> +--ro datastore-subtree-filter?{sn:subtree}?
> In RFC7950 Section 7.17, there is the following statement regarding
> the mandatory fields in augmented YANGs:
> 
> If the augmentation adds mandatory nodes (see Section 3
> ) that
>represent configuration to a target node in another module, the
 ^^^

>augmentation MUST be made conditional with a "when" statement.  Care
>must be taken when defining the "when" expression so that clients
>that do not know about the augmenting module do not break.
> 
> Does this statement applies to YANG notification containers?
> Or does this statement applies only to configuration YANG modules?

It applies to configuration nodes.

> Is this a pyang compiler bug?

Yes.


/martin



> 
> Regards,
> 
> Alex Huang Feng
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Martin Björklund]

Hi,

Regardless of pattern, the usage of this 'leaf language' seems
completely meaningless, and arbitrary.  For example, there is one leaf
'language' per entry in 'list i2nsf-cfi-policy', which is supposed to
cover all 'leaf description' in that list entry.  So I, as an operator
(i) must configure this language tag for each list entry and (ii)
ensure that all descriptions are written in the specified language.
What happens if the tag is incorrect?  How does this help the operator?


/martin




tom petch  wrote:
> A fresh belated thought.
> 
> The I2NSF I-D drew a DISCUSS from Francesca because the strings did
> not have language tags as per RFC2277.  This was added along with a
> 25-line pattern for the language tag, much simplified.  The string was
> wrong which led to a revised pattern.  Meanwhile other I2NSF I-D drew
> the same DISCUSS and were similarly revised so we have multiple
> 25-line patterns (which may now be right).
> 
> With Francesca on the IESG, I can see many YANG I-D attracting the
> same comment so rather than having dozens of copies of the pattern, an
> importable type, suitably checked by an expert (Martin Durst comes to
> mind) would seem prudent.
> 
> RFC6991-bis would seem the place to put it but it really needs to be
> now, not next year.
> 
> Tom Petch 
> 
> 
> From: netmod  on behalf of tom petch
> 
> Sent: 24 March 2022 17:17
> To: Andy Bierman; Jürgen Schönwälder
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11
> 
> From: netmod  on behalf of Jürgen Schönwälder
> 
> Sent: 22 March 2022 07:11
> 
> So we have the following options:
> 
> a) Leave revision-date to be defined in ietf-yang-revisions.
> 
> b) Define revision-date in ietf-yang-types.
> 
> c) Define a date-no-zone type (derived from the date type) which does
>not have the optional time zone offset.
> 
> 
> 
> Yes, I like c) for its simplicity and its adequacy
> 
> Tom Petch
> 
> 
> I am leaning towards option c), having a generic type for a date
> without a time zone is the most general type we can provide. If
> additional specific revision date semantics are necessary, they can be
> provided in ietf-yang-revisions. (Looking at the definition of the
> type revision-identifier in RFC 8525, this is really date-no-zone.)
> 
> /js
> 
> On Tue, Mar 15, 2022 at 08:42:31AM -0700, Andy Bierman wrote:
> > On Tue, Mar 15, 2022 at 6:01 AM Jürgen Schönwälder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Mon, Mar 14, 2022 at 05:21:01PM -0700, Andy Bierman wrote:
> > > > On Mon, Mar 14, 2022 at 4:34 PM Kent Watsen 
> > > wrote:
> > > >
> > > > > All,
> > > > >
> > > > > 1) If you provided WGLC comments on this draft, please review the -12
> > > diff
> > > > > <
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-12.txt>
> > > to
> > > > > ensure that the updates made are good.
> > > > >
> > > > > 2) Juergen notes below that he also removed the "revision-identifier"
> > > > > typedef, as it is better
> > > > > defined in the YANG versioning module.  Any objections?
> > > > >
> > > > >
> > > > Sorry for the late comment.
> > > > I think Juergen listed one option as "rename to revision-date and
> > > > leave
> > > it
> > > > in this module".
> > > > I support this option.
> > > >
> > > > There is no chance that the revision date format will be changing any
> > > time
> > > > soon.
> > > > This is useful for general applications because revision date is
> > > > widely
> > > > used.
> > > >
> > >
> > > The ietf-yang-library module (RFC 8525) currently uses its own
> > > definition of revision-identifier. While this module could adopt a
> > > common definition, the value of such a change is minor.
> > >
> > > The question where we place the definition of revision-date is likely
> > > a matter of which role we expect the versioning work to play in the
> > > future. I am relatively neutral on the placement.
> > >
> > >
> > Not that important I guess.
> > One would think the "date" typedef already in the draft would be
> > useful,
> > but it isn't, and therefore not used.
> > There is no typedef for the pattern -MM-DD.
> >
> > /js
> > >
> >
> > Andy
> >
> >
> > >
> > > --
> > > Jürgen Schönwälder  Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103 
> > >
> 
> --
> Jürgen Schönwälder  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] Does defining a feature require the module be implemented?

[Martin Björklund]

Kent Watsen  wrote:
> 
> 
> > On May 18, 2022, at 2:05 AM, Martin Björklund 
> > wrote:
> > 
> >> PS: the answer to this impacts the "crypto-types and friends" drafts
> >> in the NETCONF WG, where it is assumed (and various tools agreed, sans
> >> a recent change in `yanglint`) that the implementation-status of a
> >> module is orthogonal to what features supported.
> > 
> > Can you show a specific example where this is a problem?
> 
> 
> Background:
> 
> The genesis of this issue arises from a change (I think!) in
> instance-document validation behavior from yanglint 1.x and 2.x, which
> I've been switching to, whereby validation is now failing due to an
> assumption that a module is *implemented* when the module is targeted
> by the "--features" parameter, even if only to explicitly indicate the
> *no* features are defined (i.e., "--featues=foo:", note that there are
> no feature-names listed after the colon).  As an aside, this seems a
> bit like "the tail wagging the dog", but the reasoning was/is that
> features can only be defined if a module is implemented and therefore
> it makes sense to auto-implement a module even though it wasn't
> explicitly listed as such on the command line.
> 
> Issue:
> 
> An issue arises when a module (like ietf-keystore) defines a grouping
> (like "keystore-grouping") that is used both to allow instances in
> other data models as well as a "global" instance when the module is
> implemented.  i.e., container keystore { uses keystore-grouping; }
> 
> In ietf-keystore, a feature (central-keystore-supported) is used to
> enable leafrefs to the global instance for cases when the module is
> implemented (e.g., see local-or-keystore-symmetric-key-grouping).
> However, because it was not anticipated that a module had to be
> implemented in order for a feature to be defined (as was allowed by
> RFC 7895 YANG Library), the "central-keystore-supported" feature
> statement was NOT placed on the root node of the protocol-accessible
> tree.
> 
> So, in the case of NOT wanting the global keystore instance and yet
> there IS a desire to define another keystore feature (e.g.,
> asymmetric-keys), it seems that 1) the module MUST be implemented
> *and* the root node of the protocol-accessible tree MUST have an
> "if-feature central-keystore-supported" statement.
> 
> Closing thoughts:
> 
> 1) I'm not saying it is wrong that a module must be implemented in
> order to define features defined in it.  But I am noting that I can't
> find where this behavior is defined (e.g., in RFC 7950).  Also I note
> that RFC 7895 enabled features to be defined independent of
> implementation-status while RFC 8525 doesn't.  As a co-author of RFC
> 8525, I don't recall this being discussed and wonder what
> justification was used, as folks are pointing to and working backwards
> from RFC 8525 to indicate that it must be so.

Hmm, I don't remember why this was changed in RFC 8525.  Perhaps this
was by accident?  The only text I can find is this in RFC 7950:

  5.6.5.  Implementing a Module

 A server implements a module if it implements the module's data
 nodes, RPCs, actions, notifications, and deviations.

Which seems to indicate that "implementing a module" is NOT required
for a feature to be supported.

> 2) If it is the case that the module must be implemented to use its
> features, then I need to update some of my modules (e.g., crypto-types
> and friends) to explicitly disable the protocol-accessible tree when
> the module is implemented *only* to use its features.

Since RFC 8525 doesn't allow a feature to be supported w/o also
implementing the module, I think this is the solution for now.  And it
is not wrong even if RFC 8525 was updated to support features from
imported modules.


> 3) I wish more modules would following the pattern of having the
> global protocol accessible tree be defined via a "uses" of a grouping
> defined in the module.  In another recent project, I had to hack the
> topology modules defined in RFC 8345 (to convert the containers to
> groupings) to enable a multiplicity of "abstract network topologies"
> to be configured.  The assumption that only a single global instance
> is ever needed is proving to be invalid in my work time and again.

This is a classic problem w/ any model... And you can extend it to
other things as well, not only top-level nodes; whenever you define a
leaf, perhaps someone could support multiple instances and wished it
was a leaf-list instead?  And in a leaf-list, perhaps someone wanted
to add additional properites to each item, and wished it was a list
instead?  And so on...


/martin

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

Re: [netmod] Does defining a feature require the module be implemented?

[Martin Björklund]

Hi,

Kent Watsen  wrote:
> YANG Doctors, 
> 
> 
> Does "foo" need to be "implemented", in order for its feature to be
> define?
> 
>   module foo {
> yang-version 1.1;
> namespace "https://example.net/foo";;
> prefix "f";
> 
> feature foo-feature;
> 
>   ...
>   }
> 
> 
> Specifically, using the previous YANG Library (RFC 7895), would this
> be possible:
> 
>   {
> "name": "foo",
> "feature": [
>   "foo-feature"
> ],
> "namespace": "https://example.net/foo";,
> "conformance-type": "import"
>   },
> 
> 
> Or does "foo" also need to be "implemented", in order for its feature
> to be defined?
> 
> 
> PS: the answer to this impacts the "crypto-types and friends" drafts
> in the NETCONF WG, where it is assumed (and various tools agreed, sans
> a recent change in `yanglint`) that the implementation-status of a
> module is orthogonal to what features supported.

Can you show a specific example where this is a problem?


/martin



> 
> Thanks,
> Kent
> 
> 
> 
> ___
> 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] [Editorial Errata Reported] RFC7950 (6952)

[Martin Björklund]

Hi,

This errata report is obviously correct and should be verified.


/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/eid6952
> 
> --
> Type: Editorial
> Reported by: Andy Bierman 
> 
> Section: 10.4.2.1
> 
> Original Text
> -
>augment "/interface" {
>  when 'derived-from-or-self(type, "exif:fast-ethernet");
>  // Fast-Ethernet-specific definitions here
>}
> 
> Corrected Text
> --
>augment "/interface" {
>  when 'derived-from-or-self(type, "exif:fast-ethernet")';
>  // Fast-Ethernet-specific definitions here
>}
> 
> Notes
> -
> single quote to end complete string is missing
> 
> 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

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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Martin Björklund]

I thought the discussion was only about ipv4?


/martin


Jürgen Schönwälder  wrote:
> On Thu, Apr 14, 2022 at 03:23:31PM +0200, Martin Björklund wrote:
> > Hi,
> > 
> > First of all, I agree that if we were to design this from scratch, I
> > think we should have a type for just an ip address, and use a second
> > leaf for the zone (or interface).
> >
> 
> The notation 'fe80::4d9:ff04:4fa6:7980%en0' is widely supported in
> application space. The IPv6 working group has a recurring debate on
> the usage of zoned IPv6 address in URLs [1], where the debate is about
> the question whether the % needs to be escaped or not. I do not know
> where the latest iteration stopped, but details can be found in RFC
> 6874 and draft-carpenter-6man-rfc6874bis-03.
> 
> Philip Homburg's RIPE Labs note [2] might also be an interesting
> read. According to this, getaddrinfo() actually deals with zoned
> addresses (and hence even data model implementation that pass data to
> getaddrinfo() to obtain socket addresses may do the right thing.)
> 
> My view is that down in the network layer models, you often know the
> interface by context and ipv6-address-no-zone is sufficient. If you go
> to application space, you really want "ipv6-address-with-zone" by
> default in order to support link-local addresses.
> 
> /js
> 
> [1] http://[fe80::4d9:ff04:4fa6:7980%en0]/
> 
> [2] 
> https://labs.ripe.net/author/philip_homburg/whats-the-deal-with-ipv6-link-local-addresses/
> 
> -- 
> Jürgen Schönwälder  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] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Martin Björklund]

Hi,

First of all, I agree that if we were to design this from scratch, I
think we should have a type for just an ip address, and use a second
leaf for the zone (or interface).

"Rob Wilton (rwilton)"  wrote:
> Hi Martin,
> 
> I have several concerns with this approach:
> 
> (1) I still think that the ip-address type name still ends up being
> non-intuitive

Agreed.

> (especially for zoned IPv4 addresses - I would be
> surprised to find that there is any deployment for these at all).

Maybe, I have no idea.  What I *do* know is that lots of users
(probably most users) of YANG modules are not active in the IETF.

> I.e., the evidence seems to suggest that when engineers think of IP
> addresses, they don't seem to generally think of zoned IP addresses.
> I doubt that any fiddling of the type description is going to change
> that perception, not least when the definition is different for
> OpenConfig and in vendors models and ip-address is widely used in many
> published YANG models.
> 
> (2) It means that clients of YANG models using the ip-address type
> have no idea whether the server will support zones without either
> trying the configuration (which could subsequently become unsupported
> in the future) or requiring an out-of-band discussion with the device
> vendor.  For such as basic type this doesn't seem great.

But this is what we have had for 12 years, and from what I know we
haven't seen any real issues with this.

> (3) For IETF models, does that mean that new models should use
> ip-address-no-zone, and that we should change the approx. 200 usages
> in 40-50 published RFCs?  As mentioned previously, this doesn't seem
> pragmatic, or it will take the best part of a decade to happen.
> During that time the difference between ip-address ,
> ip-address-with-zone, and ip-address-no-zone will probably cause even
> further confusion due to the ambiguity, and differences in
> implementations.

No, the pragmatic solution I propose is to only change the description
of ip-address (and v4/v6) to match current implementations; i.e., make
it clear that an implementation doesn't have to support the optional
zone index.

Not ideal, but this is what is implemented and it seems to work.



/martin



> (4) For NMDA models, it means that clients could (but probably never
> will) receive zoned ip addresses back from .  Further, if
> zoned IP addresses are returned, then they are expected to use
> numerical IDs for the zones, which seem to be effectively opaque to
> the client (other than uniqueness).  Clients seem to have a few
> choices: ignore (error?) on zoned IP addresses, ignore the zone (does
> that make sense), or have additional code to handle a case that for
> 99% of users will probably never happen.  My point being that these is
> also a cost to keeping support for zones in the base ip-address types.
> 
> Regards,
> Rob
> 
> 
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: 12 April 2022 08:26
> > To: Rob Wilton (rwilton) 
> > Cc: netmod@ietf.org; l...@ietf.org
> > Subject: Re: [netmod] [Lsr] I-D Action:
> > draft-ietf-lsr-ospfv3-extended-lsa-yang-
> > 10.txt
> > 
> > Hi,
> > 
> > Here's another suggestion.  We keep the ip-address pattern as is, but
> > document in the description that implementations do not have to
> > support the optional zone index.  This would essentially document the
> > behavior of most current implementations.  (This is actually what I
> > suggested in the earliest thread on this topic that I could find:
> > https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-
> > fRb2hVsf4sPuCU)
> > 
> > 
> > 
> > /martin
> > 
> > 
> > "Rob Wilton \(rwilton\)"  wrote:
> > > Hi all,
> > >
> > > Thanks for the comments on this thread so far.  It would be nice if we
> > > are
> > able to come to some sort of rough consensus to a solution.
> > >
> > > I think that there is consensus that the YANG type ip-address (and the
> > > v4/v6
> > versions) are badly named as the prominent default type name has been
> > given to the unusual variant of including zone information.
> > >
> > > Based on the comments on this thread, it also seems likely to me that
> > > most
> > of the usages of ip-address in YANG RFCs is likely to be wrong, and
> > the
> > intention was that IP addresses without zones was intended.  At a
> > rough
> > count, of the published RFC YANG models at github
> > YangModels/standard/ietf/RFC/ to be:
> > >   86 uses of ip-address
> > >   68 uses of ipv4-address
> > >   66 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Martin Björklund]

Jürgen Schönwälder  wrote:
> On Tue, Apr 12, 2022 at 04:52:41PM +0200, Martin Björklund wrote:
> > Jürgen Schönwälder  wrote:
> > 
> > [...]
> > 
> > > For me, the only sensible option (other than accepting that types are
> > > named the way they are) is to introduce ip-address-with-zone and to
> > > deprecate ip-address and stop there. Yes, this means coexistance of
> > > inet:ip-address and ip-address-with-zone until YANG is getting
> > > replaced.
> > 
> > But then what would you do with inet:host?
> >
> 
> I would define ip-address-with-zone to be the same as ip-address
> (i.e., with an optional zone index) and then I would then use
> ip-address-with-zone instead of ip-address in inet:host (like we are
> all going to replace the deprecated ip-address with either
> ip-address-with-zone or ip-address-no-zone in all modules in the
> future to avoid depending on a deprecated definition).

But if people believe that we have a big problem that ip-address may
contain a zone index, don't we have the same problem w/ inet:host?
Don't we have to deprecate also inet:host for the same reason?

(To be clear: Personally, I do not think that deprecating these
typedefs is the best solution)
 
> It does not make sense to me to have a type mandating a zone since on
> all systems I know of the zone index shows up only when needed (and
> creating yet another union seems overkill).

Did anyone suggest this?  I thought ip-address-with-zone was supposed to be
exactly what ip-address is today.



/martin


> 
> /js
> 
> PS: I guess someone will propose to use ip-address-opt-zone instead
> ip-address-with-zone. ;-)
> 
> -- 
> Jürgen Schönwälder  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] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Martin Björklund]

Jürgen Schönwälder  wrote:

[...]

> For me, the only sensible option (other than accepting that types are
> named the way they are) is to introduce ip-address-with-zone and to
> deprecate ip-address and stop there. Yes, this means coexistance of
> inet:ip-address and ip-address-with-zone until YANG is getting
> replaced.

But then what would you do with inet:host?


/martin

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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Martin Björklund]

Hi,

Here's another suggestion.  We keep the ip-address pattern as is, but
document in the description that implementations do not have to
support the optional zone index.  This would essentially document the
behavior of most current implementations.  (This is actually what I
suggested in the earliest thread on this topic that I could find:
https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-fRb2hVsf4sPuCU)



/martin


"Rob Wilton \(rwilton\)"  wrote:
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are 
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6 
> versions) are badly named as the prominent default type name has been given 
> to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most of 
> the usages of ip-address in YANG RFCs is likely to be wrong, and the 
> intention was that IP addresses without zones was intended.  At a rough 
> count, of the published RFC YANG models at github 
> YangModels/standard/ietf/RFC/ to be:
>   86 uses of ip-address
>   68 uses of ipv4-address
>   66 uses of ipv6-address
> 
>   1 use of ip-address-no-zone
>   4 uses of ipv4-address-no-zone
>   4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
> quick guess/check it looks like these 49 YANG modules may appear in 40-50 
> RFCs.
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig 
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone 
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP 
> addresses in the latest OpenConfig github repository.  However, approximately 
> a third of the IP address types are still to the ietf-inet-types.yang rather 
> than openconfig-inet-types.yang, so in theory some of those 58 entries could 
> still intentionally be supporting zoned IP addresses, but I would expect that 
> the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way 
> in both IETF and OC YANG, and I believe that the OC folks have got the 
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is 
> effectively optional, and implementations are not really obliged to implement 
> it.  I don't find that argument compelling, at least not with the current 
> definition of ip-address in RFC 6991.  I see a clear difference between a 
> type defined with an incomplete regex that may allow some invalid values and 
> a type that is explicitly defined to included additional values in the 
> allowable value space.  Further, I believe that a client just looking at the 
> YANG module could reasonably expect a server that implements a data node 
> using ip-address would be expected to support IP zones, where they are 
> meaningful, or otherwise they should deviate that data node to indicate that 
> they don't conform to the model.
> 
> We also need to be realistic as to what implementations will do.  They are 
> not going to start writing code to support zones just because they are in the 
> model.  They will mostly reject IP addresses with zone information.  Perhaps 
> some will deviate the type to ip-address-no-zone, but probably most won't.
> 
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
> appealing.  This would take a significant amount of time/effort and I think 
> that we will struggle to find folks who are willing to do this.  Although 
> errata could be used to point out the bug, then can't be used to fix it, all 
> the errata would be "hold for document update" at best.  Further, during the 
> time that it would take us to fix it, it is plausible that more incorrect 
> usages of ip-address will likely occur (but perhaps could be policed via 
> scripted checks/warnings).
> 
> 
> I still feel the right long-term solution here is to get to a state where the 
> "ip-address" type means what 99% of people expect it to mean, i.e., excluding 
> zone information.
> 
> Given the pushback on making a single non-backwards compatible change to the 
> new definition, I want to ask whether the following might be a possible path 
> that gains wider consensus:
> 
> (1) In RFC 6991 bis, I propose that we:
> (i) define new ip-address-with-zone types (and v4 and v6 versions) and keep 
> the -no-zone versions.
> (ii) we change the description of "ip-address" to indicate:
> - Although the type allows for zone information, many implementations are 
> unlikely to accept zone information in most scenarios (i.e., so the 
> description of the type more accurately reflects reality).
> - A new ip-address-with-zone type has been introduced to use where zoned IP 
> addresses are required/usef

Re: [netmod] Tree diagram comment lines

[Martin Björklund]

tom petch  wrote:
> Can a YANG tree diagram contain comment lines?
> 
> draft-ietf-teas-yang-te has a tree diagram of 40 pages and since the
> IETF has abolished the page number, then any reference into it could
> be a challenge.  For a YANG module, this can be ameliorated by
> inserting comment lines every page or two.
> 
> Can this be done with tree diagrams?

Yes, "//" introduces a (line) comment.  See 2.5 of RFC 8340.

But a 40 page tree diagram isn't very useful anyway, imo.  If I want
the full tree diagram I can run a tool to generate it.  Tree diagrams
are best used in combination with explanatory text to explain certain
aspects of the module design.  Perhaps section 3.4 in RFC 8407 should
be updated to explain this.


/martin




> 
> Tom Petch
> ___
> 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] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Martin Björklund]

Andy Bierman  wrote:
> On Thu, Apr 7, 2022 at 9:11 AM tom petch  wrote:
> 
> > From: Lsr  on behalf of Rob Wilton (rwilton)
> > 
> > Sent: 07 April 2022 10:25
> >
> > I basically agree with Acee, and I think that we should do (b):
> >
> > b) Change the types as suggested and accept that doing so breaks
> > modules where zone indexes are meaningful.
> >
> > 
> >
> > I am concerned that such behaviour will damage the standing of the IETF at
> > large.
> >
> >
> MAY for the client means MUST for the server.

I'm not sure what you mean here.

But I'm also not sure I understand what the real problem is.  Just b/c
the type allows a zone doesn't mean that all leafs that use this type
MUST support a zone.  Compare with the value "0.0.0.0".  It is a legal
value according to the pattern, but it will not be valid in all places
where this type is used.  And even when an implementation supports
zones, it will not accept all legal (according to the pattern) values
for the zone index.  Perhaps the solution is to explain this
better in the description?


> But if no servers actually support it, because the YANG does not match
> the operational requirements, then is it really a MUST requirement?
> 
> This seems like a bugfix, and the worst thing the IETF could do wrt/
> standing
> is to force the world to change every module that imports the typedef.
> Since many people were not aware of the full syntax, it is not clear that
> the WG intent was to include a zone.

It is pretty clear IMO that this was not a mistake.  The text
explicitly says:

  The IPv4 address may include a zone
  index, separated by a % sign.

> 
> Seems like a bugfix to a pattern, like we have done several times already.

I don't think this is a bugfix.


/martin


> 
> Andy
> 
> 
> 
> > We clearly laid down rules as to what updates were regarded as compatible
> > so that authors of software could be confident that their work was robust
> > and future-proof.  We did it with SNMP, inter alia, and we have carried
> > that forward with YANG.  To tear up that understanding , creating who knows
> > how much disruption, can only harm the standing of IETF.
> >
> > Much has been said about how implementations have assumed that the address
> > types do not include a zone but no evidence has been put forward for that
> > assertion.
> >
> > I have always assumed that software uses libraries and that the libraries
> > have been written with an understanding of the specifications such that if
> > a zone is received over the wire in conformance with the specification but
> > where the display, field or such like does not allow for a zone, then,
> > tolerant of what to accept, the zone is silently discarded and the address
> > is used without the zone.  But, like the assertion that keeping the zone
> > will cause who knows what damage, I have not done the research to
> > substantiate that assumption.
> >
> > Tom Petch
> >
> > I appreciate that this is an NBC change, but I believe that this is the
> > most intuitive definition and is the best choice longer term.  I also note
> > that the base ipv4-address/ipv6-address types in OpenConfig (where they use
> > the OC copy/version of inet-types and not ietf-inet-types) don't allow a
> > zone to be specified and assumes the default zone.  They have separate
> > types in cases where a zone is allowed to be specified, i.e., aligned to
> > what (b) proposes.
> >
> > For modules that are using/wanting zones (if any), then they can migrate
> > to the new explicit zone type.   draft-ietf-netmod-yang-module-versioning,
> > if it keeps its import "revision-or-derived" extension, would also allow
> > such modules to indicate the dependency on the updated revision/definition
> > of ietf-inet-types.yang.
> >
> > Of course, the description associated with the updated
> > ietf-inet-types.yang revision should clearly highly the
> > non-backwards-compatible change to the types.
> >
> > Rob
> >
> >
> > -Original Message-
> > From: iesg  On Behalf Of Jürgen Schönwälder
> > Sent: 07 April 2022 08:35
> > To: Acee Lindem (acee) 
> > Cc: l...@ietf.org; The IESG ; netmod@ietf.org
> > Subject: Re: [netmod] [Lsr] I-D Action:
> > draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> >
> > Here is roughly what happened:
> >
> > - RFC 6020 (published ~12 years ago) introduced the ip-address
> >   type. It included an optional zone index part since zone indexes
> >   are necessary in certain situations (e.g., configuring services
> >   listening on link-local addresses or clients connecting to services
> >   listening on link-local addresses).
> >
> > - RFC 6991 (published ~9 years ago) added the ip-address-no-zone types
> >   since people felt that it is useful to also an ip address type
> >   without the optional zone part for situations where a zone is not
> >   applicable. The name 'ip-address-no-zone' was picked since the name
> >   ip-address was already taken.
> >
> > I understand that the names resulting from

Re: [netmod] [Editorial Errata Reported] RFC8528 (6857)

[Martin Björklund]

Hi,

Chris Smiley  wrote:
> 
> Greetings,
> 
> EID 6857 is almost identical to EID 5797.  They differ in the enabled field 
> (one says true, one says false). Please let me know which errata is correct.


EID 5797 is the correct one.

For some reason, EID 6857 has mistyped the *original* text (according
to EID 6857, the original text has "enabled": false, but RFC 8528 has
"enabled": true).


/martin


> 
> Thank you.
> 
> RFC Editor/cs
> 
> 
> > On Feb 21, 2022, at 11:31 PM, RFC Errata System  
> > wrote:
> > 
> > The following errata report has been submitted for RFC8528,
> > "YANG Schema Mount".
> > 
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6857
> > 
> > --
> > Type: Editorial
> > Reported by: Kokkiknamtan 
> > 
> > Section: A.2
> > 
> > Original Text
> > -
> >  {
> > "ietf-interfaces:interfaces": {
> >   "interface": [
> > {
> >   "name": "eth0",
> >   "type": "iana-if-type:ethernetCsmacd",
> >   "enabled": false,
> >   "ietf-logical-network-element:bind-lne-name": "eth0"
> > }
> >   ]
> > },
> > 
> > 
> > Corrected Text
> > --
> > {
> > "ietf-interfaces:interfaces": {
> >   "interface": [
> > {
> >   "name": "eth0",
> >   "type": "iana-if-type:ethernetCsmacd",
> >   "enabled": false,
> >   "ietf-logical-network-element:bind-lne-name": "lne-1"
> > }
> >   ]
> > },
> > 
> > 
> > Notes
> > -
> > leafref is for an LNE name, not an interface name
> > 
> > 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. 
> > 
> > --
> > RFC8528 (draft-ietf-netmod-schema-mount-12)
> > --
> > Title   : YANG Schema Mount
> > Publication Date: March 2019
> > Author(s)   : M. Bjorklund, L. Lhotka
> > 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

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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Martin Björklund]

Jürgen Schönwälder  wrote:
> On Tue, Mar 08, 2022 at 11:20:57AM +0100, Martin Björklund wrote:
> > Hi,
> > 
> > You didn't answer my first question about what we actually mean - do
> > we mean the "URI"
> 
> "The uri type represents a Uniform Resource Identifier
>  (URI) as defined by STD 66. [...]"
> 
> STD 66 resolves to RFC 3986. Maybe I do not understand your question.

RFC 3986 defines the syntax for "URI" and "URI-reference", see
specifically section 4 and 4.1 of RFC 3986.  To avoid confusion, I
suggest:

 "The uri type represents a Uniform Resource Identifier
  (URI) as defined by the rule 'URI' in RFC 3986.

or "the ABNF rule 'URI'..."

(side note, is it better to refer to STD 66 rather than the RFC?)



/martin







>  
> > I agree with you re the problem with pattern in this case.
> > 
> > The simplest pattern would be:
> > 
> >   pattern "[a-z][a-z0-9+.-]*:.*"; // matches the mandatory scheme
> > 
> > but I think you will say that either we have a complete correct
> > pattern, or no pattern at all ;-)
> 
> I personally do not believe that a pattern needs to catch every
> nuance. The only requirement is that a pattern must not reject any
> valid values. For me, the description ultimately defines the type and
> a pattern merely helps to catch some of the syntactic details in an
> automated fashion.
> 
> My experience is that people have different ideas about how many
> details a pattern should capture and hence pattern have a tendency to
> grow increasingly complex over time.
> 
> I am happy to add the proposed pattern since covering the scheme part
> is apparently better than having nothing (but I am sure this will be
> the beginning of a journey and not its end).
> 
> /js
> 
> -- 
> Jürgen Schönwälder  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] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Martin Björklund]

Hi,

You didn't answer my first question about what we actually mean - do
we mean the "URI"


I agree with you re the problem with pattern in this case.

The simplest pattern would be:

  pattern "[a-z][a-z0-9+.-]*:.*"; // matches the mandatory scheme

but I think you will say that either we have a complete correct
pattern, or no pattern at all ;-)


/martin


Jürgen Schönwälder  wrote:
> Martin,
> 
> the problem is finding a pattern that is guaranteed to not exclude
> anything valid and which is simple enough to be understood and put in
> a YANG module. People on the Internet tried to literally capture the
> ABNF rules of RFC 3986 leading to regular expression monsters.
> 
> I am open for concrete suggestions. ;-)
> 
> /js
> 
> On Tue, Mar 08, 2022 at 09:52:23AM +0100, Martin Björklund wrote:
> > Hi,
> > 
> > While reviewing draft-ietf-opsawg-sap-02, I had to study the type
> > inet:uri again.
> > 
> > I assume that the type "uri" is supposed to mean the type that is
> > defined by the ABNF rule "URI" in RFC 3986.  If my assumption is
> > correct I think we should make this clear in 6991bis.  If my
> > assumption is not correct, then we definitely should add some text
> > that describes what is meant.
> > 
> > Since (?) inet:uri is defined simply as "string" w/o any pattern, some
> > RFCs have been published with URIs such as "D1" and "1-0-1" (RFC
> > 8345).
> > 
> > 
> > 
> > /martin
> 
> -- 
> Jürgen Schönwälder  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] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Martin Björklund]

Hi,

While reviewing draft-ietf-opsawg-sap-02, I had to study the type
inet:uri again.

I assume that the type "uri" is supposed to mean the type that is
defined by the ABNF rule "URI" in RFC 3986.  If my assumption is
correct I think we should make this clear in 6991bis.  If my
assumption is not correct, then we definitely should add some text
that describes what is meant.

Since (?) inet:uri is defined simply as "string" w/o any pattern, some
RFCs have been published with URIs such as "D1" and "1-0-1" (RFC
8345).



/martin

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

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

[Martin Björklund]

Hi,

The main reason that keys are encoded first is that it allows for
efficient streaming parsing.  The reciever can act on an instance as
soon as the keys are received, w/o having to buffer the entire
document.  For example, in the implementation that I used to work
with, a copy-config a get-config's result used more or less a constant
amount of memory, regardless of the size of the config.

This optimization is not possible if JSON is used.


/martin



"SADOVNIKOV, ALEXEI"  wrote:
> On Mon, Feb 28, 2022 at 06:42:56PM +, Sterne, Jason (Nokia - CA/Ottawa) 
> wrote:
> > Thx.  I probably went too far in my statement about XML documents being 
> > unordered. But isn't it true that for YANG modelled data, the order of the 
> > XML *shouldn't* matter ?  It should ideally be processed atomically (i.e. 
> > after being fully processed/loaded it should be non-ambiguous if you 
> > assumed every statement was applied at the same instant) ?
> 
> In addition to what Andy said (which I agree with)…
> 
> Ordered-by-user, is a special case – this is where the order is significant.  
> For completeness it would be significant even in JSON encapsulation (arrays 
> are ordered).  Unlike other XML ordering cases, the order in ordered-by-user 
> is simply significant by itself.
> 
> In other scenarios of ordering of XML document as described in RFC 7950 there 
> are two different aspects (and sticking with your terminology):
> 
> 
> 
>   1.  The way RFC 7950 stands, the order of XML does matter.  Consequently, 
> and XML document which is ordered differently does not have to be 
> “processed/ordered”; it is totally legitimate for such XML document to be 
> rejected.
> 
> This could also allow parser of XML document to be more efficient in 
> processing data taking an account model order.
> 
> 
> 
> For example, in your earlier example of ,, vs to 
> ,,, one is correct ordering and will be “processed” 
> correctly; the other one is wrong ordering and may result in processing 
> failure.
> 
> 
> 
>   1.  The second aspect, which I think you talking about, is the significance 
> of such ordering required by RFC.  I do agree with you, there is nothing 
> which prevents correct “processed/ordered” to be done.  In other words, the 
> processor knows what the keys are and which order the keys are in, and he can 
> get them from XML document.  Further, if payload comes as JSON, the ordering 
> is not there, so if processor can consume both JSON and XML he is already 
> implementing order independent processing for JSON.
> 
> Another point relevant to this conversation hides in section 
> 6.4.  XPath 
> Evaluations, which states
> 
>The data tree has no concept of document order.  An implementation
>needs to choose some document order, but how it is done is an
>implementation decision.  This means that XPath expressions in YANG
>modules SHOULD NOT rely on any specific document order.
> 
> Couple point to note here:
> 
>   *   The XPATH has document order axes, e.g. ‘preceding-sibling’ hence it 
> can interrogate document order
>   *   RFC says that this is implementation specific (e.g. it does not need to 
> follow the order of XML encapsulation described elsewhere).
> Consequently, in your keys example, it is implementation dependent which is 
> preceding-sibling key-2, and it can be different from what it is in XML 
> document encoding the data.
> 
> Not being an original contributor of this RFC, I really cannot tell why 
> ordering requirements (other than ordered-by-user) are in RFC, nor what good 
> do such requirements do.
> 
> I can say though that this ordering is not a discussion of RFC 7950, which 
> sets the requirements, nor a discussion of this errata, which was about 
> wording used to set requirements.  It could be part of YANG NEXT discussion :)
> 
> Best regards,
> 
> Alexei Sadovnikov
> Principal System Architect
> Business Solutions
> AT&T Business
> 
> AT&T Services, Inc.
> 550 Cochituate Road, Framingham, MA 01701
> m  781.249.1516 |  o  781.249.1516 |  as5...@att.com
> 
> This e-mail and any files transmitted with it are AT&T property, are 
> confidential, and are intended solely for the use of the individual or entity 
> to whom this e-mail is addressed. If you are not one of the named 
> recipient(s),  or otherwise have reason to believe that you have received 
> this message in error, please notify the sender and delete this message 
> immediately from your computer. Any other use, retention, dissemination, 
> forwarding, printing, or copying of this e-mail is strictly prohibited.
> 
> 
> 
> From: Andy Bierman 
> Date: Monday, February 28, 2022 at 2:06 PM
> To: Jürgen Schönwälder , "Sterne, Jason 
> (Nokia - CA/Ottawa)" , as549r , "Rob 
> Wilton (rwilton)" , Andy Bierman , 
> "m...@tail-f.com" , "war...@kumari.net" , 
> "netmod@ietf.org" , RFC Errata System 
> 
> Subject: Re: [netmod] [Technical Errata Repo

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

[Martin Björklund]

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi all,
> 
> There is an interesting consequence of the wording for lists.
> 
> > The list's key nodes are encoded as subelements to the list's
> > identifier element, in the same order as they are defined within the
> > "key" statement.
> >
> > The rest of the list's child nodes are encoded as subelements to the
> > list element, after the keys.  If the list defines RPC or action
> > input or output parameters, the subelements are encoded in the same
> > order as they are defined within the "list" statement.  Otherwise,
> > the subelements are encoded in any order.
> 
> The first paragraph says the key nodes are encoded in the same order
> as the key statement.  But then the 2nd paragraph says the subelements
> are encoded in the order they are defined.  But it isn't super-clear
> if that entire second paragraph only applies to the "rest of the"
> nodes (i.e. not the keys). The last sentence seems to apply to the
> keys as well (outside of an RPC/action input/output).

IMO the first paragraph is very clear; it talks about the keys - all
keys are encoded in the order the are defined in the "key" statement.
There is no text that suggests that this encoding is optional.

IMO the second paragraph is also clear; it talks about the *rest* (non
keys) - it says that the rest of the child nodes are encoded *after
the keys*, and then defines the order in which they are encoded.

*If* the intention had been that all elements are always encoded in
any order, the first paragraph wouldn't have been there.

> I believe it is legal to define a YANG list that has a different order
> for the items in the "key" element than in the definition of the key
> leafs right ?

Yes.

> For example:
> 
> list foo {
> key "key-1 key-2 key-3"
> leaf key-1 { … }
> leaf key-3 { … }
> leaf key-2 { … }
> leaf some-other-leaf-a
> leaf some-other-leaf-b
> }
> [not that I'd recommend modelling like that]
> 
> Is it clear enough that the encoding order of the subelements matching
> the YANG-order only applies to the elements *besides* the keys ?

Yes.


/martin


> 
> It is interesting that there is a small inconsistency here. Looking
> purely at the order of the leafs won't match the XML encoding for key
> leafs.
> 
> i.e. maybe some implementations will order the XML this way (doesn't
> match the order of *all* leafs):
> …
> …
> …
> …
> …
> and might some do this (matches the order of *all* leafs, but then
> contradicts the first paragraph):
> …
> …
> …
> …
> …
> 
> Jason
> 
> From: netmod  On Behalf Of SADOVNIKOV, ALEXEI
> Sent: Tuesday, February 22, 2022 11:28 AM
> To: Rob Wilton (rwilton) ; Kent Watsen
> 
> Cc: m...@tail-f.com; netmod@ietf.org; war...@kumari.net; RFC Errata
> System 
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
> 
> Thank you, Rob.
> 
> Best regards,
> 
> Alexei Sadovnikov
> Principal System Architect
> Business Solutions
> AT&T Business
> 
> AT&T Services, Inc.
> 550 Cochituate Road, Framingham, MA 01701
> m 781.249.1516 | o 781.249.1516 |
> as5...@att.com
> 
> This e-mail and any files transmitted with it are AT&T property, are
> confidential, and are intended solely for the use of the individual or
> entity to whom this e-mail is addressed. If you are not one of the
> named recipient(s), or otherwise have reason to believe that you have
> received this message in error, please notify the sender and delete
> this message immediately from your computer. Any other use, retention,
> dissemination, forwarding, printing, or copying of this e-mail is
> strictly prohibited.
> 
> 
> 
> From: "Rob Wilton (rwilton)"
> mailto:rwil...@cisco.com>>
> Date: Tuesday, February 22, 2022 at 10:21 AM
> To: Kent Watsen mailto:kent+i...@watsen.net>>,
> as549r mailto:as5...@att.com>>
> Cc: RFC Errata System
> mailto:rfc-edi...@rfc-editor.org>>,
> "m...@tail-f.com"
> mailto:m...@tail-f.com>>,
> "war...@kumari.net"
> mailto:war...@kumari.net>>, Joel Jaeggli
> mailto:joe...@bogus.com>>, Lou Berger
> mailto:lber...@labn.net>>, Randy Presuhn
> mailto:randy_pres...@alumni.stanford.edu>>,
> "netmod@ietf.org"
> mailto:netmod@ietf.org>>
> Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)
> 
> Hi,
> 
> I basically agree with Kent, Randy, Andy.
> 
> Alexi,
> 
> Thanks for flagging this, and the subsequent discussion.
> 
> I can see your point of view that MUST is used in other similar
> places, and I'm sure that in hindsight it would be nice if the
> language was used consistently in equivalent places.
> 
> However, I don't think that the lack of a MUST statement makes the
> other text any less normative, or ambiguous.  In particular, there is
> this paragraph of R

Re: [netmod] JSON encoding of anydata: approximating an operational leaf-list

[Martin Björklund]

Jan Kundrát  wrote:
> Hi,
> last year we published some work [1] about using IETF YANG-push for
> telemetry streaming in the context of optical networks. One of the use
> cases was continualy sending spectral scans, and for us that meant
> updating a list of roughly 15-20k items at least once per second.
> 
> Think of this as a list of (frequency, power) pairs where the
> "frequency" can be implied, so the data was really a "a long vector of
> numbers". We were not able to use either `list` or a `leaf-list`
> directly for performance reasons. The root cause is that `leaf-list`
> traditionally used to be "an ordered set". It was changed to allow
> duplicate values in YANG 1.1, and that for ops data only. Still,
> various implementations try to look at the operational leaf-lists and
> helpfully compute diffs, they look for item moves, etc. This is not
> cheap for 15-20k items.
> 
> In the end we used a model like this:
> 
> leaf lowest-frequency {
>   type frequency-ghz;
>   config false;
>   mandatory true;
>   description "Lowest frequency slice in the `p` list.";
> }
> 
> leaf step {
>   type frequency-ghz;
>   config false;
>   mandatory true;
>   description "Each subsequent `p` result is this far from the previous
>   one.";
> }
> 
> anydata p {
>   config false;
>   description "Measured power. Sorted by frequency, starting at
>   `lowest-frequency`, step size `step`. Individual items are decimal64
>   numbers.";
> }
> 
> The JSON-encoded data looked like this:
> 
> {
>   "something: {
> "lowest-frequency": 123456,
> "step": 1,
> "p": ["0.003", "0.001", "0.001", "0.24", "0.37"]
>   }
> }
> 
> Our internal implementation uses libyang, and we're now updating form
> libyang v1 to libyang v2, which assumes that our `p` has to be encoded
> as JSON object. This of course produces an invalid JSON:
> 
>"p": {["0.003", "0.001", "0.001", "0.24", "0.37"]}
> 
> I have a few questions:
> 
> - Can `anydata` represent a JSON array directly?

No.

> On one hand the
>   standard says that "An anydata instance is encoded in the same way as
>   a container, i.e., as a name/object pair", but then it also allows the
>   `empty` thing via `[null]`. Or is it perhaps allowed only for
>   *members* of this faux container?

RFC 7950 says:

   The "anydata" statement is used to represent an unknown set of nodes
   that can be modeled with YANG, [...]

And 7951 says:

   An anydata instance is encoded in the same way as a container, i.e.,
   as a name/object pair.

So with "anydata p", a correct JSON example could be:

  "p": {"x": ["0.003", "0.001", "0.001", "0.24", "0.37"]}

The "could be modeled with YANG" part is satisfied with for example:

  leaf-list x {
config false;
type decimal-64 {
  fraction-digits 3;
}
  }


> 
> - In case `anydata` is not a good match, I suppose `anyxml` will work
>   fine because the example in the RFC is already using an array. Perhaps
>   we could also use JSON numbers directly without encoding as a string
>   as well.

I guess this could work.  I don't know if implementations handle
anyxml consistently.


> 
> - Is there a better approach than this one? Can I reasonably expect "all
>   the YANG implementations out there" to stop looking at operational
>   leaf-lists as essentially ordered sets? I think the answer is "no",
>   but I am looking for suggestions.

It is clear from RFC 7950 that duplicate values are allowed in
operational state.


/martin



> 
> With kind regards,
> Jan
> 
> [1] https://ieeexplore.ieee.org/document/9457112
> 
> ___
> 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] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Martin Björklund]

Hi,

I didn't find any discussion about the new percent types in the list
archives.  Do we really need three types for percent?  We can now
express 4294967295 percent, but not 10.5 percent.

The new tables look good.  s/6020/6021/g though.



/martin


Jürgen Schönwälder  wrote:
> On Tue, Feb 15, 2022 at 12:12:04PM +, maqiufang (A) wrote:
> 
> > I have only one comment: It seems that Table 2 doesn’t list all the
> > types defined in “ietf-inet-types” YANG module, e.g.,
> > protocol-number, ip-address-link-local, ip-address-and-prefix…
> > Should this be fixed?
> 
> Yes, this should be fixed. When the initial version was produced,
> there was quite some concern about consistency with SMIv2 definitions
> and this lead to the tables. Meanwhile, I assume the purpose of the
> tables is more to provide a quick overview. Hence I propose to split
> the tables into (i) tables that provide an overview of all types
> defined in the YANG modules and (ii) tables that detail equivalent
> SMIv2 types where they exist (short tables). For the overview tables,
> I suggest to add some more information. I am thinking of overview
> tables like these (keep scrolling, there is more text below):
> 
> * ietf-yang-types
> 
>   | Typedef   | Type  | Introduced |
>   |---+---+|
>   | counter32 | uint32| RFC 6021   |
>   | zero-based-counter32  | uint32| RFC 6021   |
>   | counter64 | uint64| RFC 6021   |
>   | zero-based-counter64  | uint64| RFC 6021   |
>   | gauge32   | uint32| RFC 6021   |
>   | gauge64   | uint64| RFC 6021   |
>   |---+---+|
>   | object-identifier | string| RFC 6021   |
>   | object-identifier-128 | object-identifier | RFC 6021   |
>   |---+---+|
>   | date-and-time | string| RFC 6021   |
>   | date  | string| RFC    |
>   | time  | string| RFC    |
>   |---+---+|
>   | hours32   | int32 | RFC XXX|
>   | minutes32 | int32 | RFC XXX|
>   | seconds32 | int32 | RFC XXX|
>   | centiseconds32| int32 | RFC XXX|
>   | milliseconds32| int32 | RFC XXX|
>   | microseconds32| int32 | RFC XXX|
>   | microseconds64| int64 | RFC XXX|
>   | nanoseconds32 | int32 | RFC XXX|
>   | nanoseconds64 | int64 | RFC XXX|
>   | timeticks | int32 | RFC 6020   |
>   | timestamp | timeticks | RFC 6020   |
>   |---+---+|
>   | phys-address  | string| RFC 6020   |
>   | mac-address   | string| RFC 6020   |
>   |---+---+|
>   | xpath1.0  | string| RFC 6020   |
>   | hex-string| string| RFC 6991   |
>   | uuid  | string| RFC 6991   |
>   | dotted-quad   | string| RFC 6991   |
>   | yang-identifier   | string| RFC 6991   |
>   | revision-identifier   | date  | RFC    |
>   |---+---+|
>   | percent-i32   | int32 | RFC    |
>   | percent-u32   | uint32| RFC    |
>   | percent   | uint8 | RFC    |
>   |---+---+|
> 
> * ietf-inet-types
> 
>   | Typedef | Type | Introduced |
>   |-+--+|
>   | ip-version  | enum | RFC 6021   |
>   | dscp| uint8| RFC 6021   |
>   | ipv6-flow-label | uint32   | RFC 6021   |
>   | port-number | uint16   | RFC 6021   |
>   | protocol-number | uint8| RFC    |
>   | as-number   | uint32   | RFC 6021   |
>   |-+--+|
>   | ip-address  | union| RFC 6021   |
>   | ipv4-address| string   | RFC 6021   |
>   | ipv6-address| string   | RFC 6021   |
>   | ip-address-no-zone  | union| RFC 6991   |
>   | ipv4-address-no-zone| ipv4-address | RFC 6991   |
>   | ipv6-address-no-zone| ipv6-address | RFC 6991   |
>   | ip-address-link-local   | union| RFC    |
>   | ipv4-address-link-local | ipv4-address | RFC    |
>   | ipv6-address-link-local | ipv6-address | RFC    |
>   | ip-prefix   

Re: [netmod] Use XML namespaces in YANG document examples

[Martin Björklund]

Jernej Tuljak  wrote:
> 
> 
> On 04/02/2022 08:18, Martin Björklund wrote:
> > Tim Bray  wrote:
> >> On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund 
> >> wrote:
> >>
> >>> If an XML document has , won't the XML processor
> >>> pass the attribute "xmlns:bar" and its value to the application?  This
> >>> should be enough even if the XML processor doesn't provide a mapping
> >>> table between prefix and namespace (it requires more work in the
> >>> application of course).
> >>>
> >> Nope, there's no requirement that they do and some don't.
> > Does this mean that an XML processor might not pass attributes in
> > general to the application?  If so, we might have other similar
> > problems.  Or does it mean that an XML processor might just not pass
> > these "special" attributes?  If so, where is that specified?  (I tried
> > to find this info in the spec, but didn't find it).
> 
> Names that start with "xml" (case insensitive) are reserved by XML 1.0
> specification, "xmlns" in an attribute name included (2.3 Common
> Syntactic Constructs). They are special. There is also a guideline on
> colon usage within names.

Yes, I know.  But I can't see that the spec says that attributes w/
reserved names should be treated differently wrt. the application than
other attributes.

> All processors I'm aware of differentiate between attributes and
> namespace attributes in their APIs. What Tim is probably saying is
> that some XML processors either don't implement Namespaces in XML 1.0
> or need to be explicitly configured to become "namespace aware". If
> not configured as namespace aware, they might simply ignore namespace
> attributes therefore not passing them. If they are configured as
> namespace aware, they might remove prefix information and pass only
> "namespace : local-name" pairs where required (and that excludes text
> node content).

I guess I wonder if this is b/c the specification says so, or that
some implementations choose to do so.


/martin



> 
> Jernej
> 
> >
> >
> > /martin
> >
> >
> >>> I think that if special text is needed for identityref values in XML,
> >>> that text should go in to the YANG specification (RFC 7950).  All
> >>> these other drafts just follow the rules defined in RFC 7950.
> >>>
> >> Agreed.
> >>
> >>
> >>
> >>>
> >>> /martin
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Andy
> >>>>>
> >>>>>
> >>>>>> I've excerpted an email exchange with Ian Farrer that I think makes
> >>> the
> >>>>>> potential problem concrete:
> >>>>>>
> >>>>>> Hi Ian, I don't think we've met.  I'm the grumpy person on the "XML
> >>>>>> Directorate" who's been whining about the namespace prefixes in YANG
> >>>>>> internet-drafts. One quick issue: I'm a little surprised, is anyone
> >>> still
> >>>>>> using XML in this kind of thing any more in 2021?
> >>>>>>
> >>>>>> Anyhow, below I've excerpted the issue that's still troubling me.
> >>> Here's
> >>>>>> the XML:
> >>>>>>
> >>>>>>>>>>>>   xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>>>>>   
> >>>>>> eth0
> >>>>>> ianaift:ethernetCsmacd
> >>>>>> DHCPv6 Relay Interface
> >>>>>> true
> >>>>>>   
> >>>>>> 
> >>>>>>
> >>>>>> So my question is, I see the XML namespace prefix and the prefix for
> >>> the
> >>>>>>  element content are identical. Is this a coincidence?  For
> >>> example,
> >>>>>> would the following work, changing the namespace prefix to "foo"?
> >>>>>>
> >>>>>>
> >>>>>>>>>>>>   xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>>>>>   
> >>>>>> eth0
> >>>>>>

Re: [netmod] Use XML namespaces in YANG document examples

[Martin Björklund]

Tim Bray  wrote:
> On Thu, Feb 3, 2022 at 10:21 AM Martin Björklund  wrote:
> 
> >
> > If an XML document has , won't the XML processor
> > pass the attribute "xmlns:bar" and its value to the application?  This
> > should be enough even if the XML processor doesn't provide a mapping
> > table between prefix and namespace (it requires more work in the
> > application of course).
> >
> 
> Nope, there's no requirement that they do and some don't.

Does this mean that an XML processor might not pass attributes in
general to the application?  If so, we might have other similar
problems.  Or does it mean that an XML processor might just not pass
these "special" attributes?  If so, where is that specified?  (I tried
to find this info in the spec, but didn't find it).


/martin


> 
> > I think that if special text is needed for identityref values in XML,
> > that text should go in to the YANG specification (RFC 7950).  All
> > these other drafts just follow the rules defined in RFC 7950.
> >
> 
> Agreed.
> 
> 
> 
> >
> >
> > /martin
> >
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >> I've excerpted an email exchange with Ian Farrer that I think makes
> > the
> > > >> potential problem concrete:
> > > >>
> > > >> Hi Ian, I don't think we've met.  I'm the grumpy person on the "XML
> > > >> Directorate" who's been whining about the namespace prefixes in YANG
> > > >> internet-drafts. One quick issue: I'm a little surprised, is anyone
> > still
> > > >> using XML in this kind of thing any more in 2021?
> > > >>
> > > >> Anyhow, below I've excerpted the issue that's still troubling me.
> > Here's
> > > >> the XML:
> > > >>
> > > >>   > > >>  xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
> > > >>  
> > > >>eth0
> > > >>ianaift:ethernetCsmacd
> > > >>DHCPv6 Relay Interface
> > > >>true
> > > >>  
> > > >>
> > > >>
> > > >> So my question is, I see the XML namespace prefix and the prefix for
> > the
> > > >>  element content are identical. Is this a coincidence?  For
> > example,
> > > >> would the following work, changing the namespace prefix to "foo"?
> > > >>
> > > >>
> > > >>   > > >>  xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
> > > >>  
> > > >>eth0
> > > >>ianaift:ethernetCsmacd
> > > >>DHCPv6 Relay Interface
> > > >>true
> > > >>  
> > > >>
> > > >>
> > > >> [if - This example would not work and fails validation with yanglint:
> > > >>
> > > >> $ yanglint --strict --verbose -t config -p $IETFYANG
> > > >> $IETFYANG/iana-if-type.yang $IETFYANG/ietf-interfaces.yang test1.xml
> > > >> err : Invalid value "ianaift:ethernetCsmacd" in "type" element.
> > > >> (/ietf-interfaces:interfaces/interface[name='eth0']/type)
> > > >> ]
> > > >>
> > > >>
> > > >> Follow-up, would the following work, foo for both namespace and
> > content
> > > >> prefix?
> > > >>
> > > >>  > > >>  xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
> > > >>  
> > > >>eth0
> > > >>foo:ethernetCsmacd
> > > >>DHCPv6 Relay Interface
> > > >>true
> > > >>  
> > > >>
> > > >>
> > > >> Thanks in advance!
> > > >>
> > > >>
> > > >> [if - This does validate with yanglint, however the convention in the
> > > >> IETF examples I’ve seen seems to be to use the prefix that is defined
> > in
> > > >> the original YANG module for imports for consistency, e.g. (from
> > > >> iana-if-type.yang):
> > > >>
&g

Re: [netmod] Use XML namespaces in YANG document examples

[Martin Björklund]

Hi,

Tim Bray  wrote:
> On Thu, Feb 3, 2022 at 9:46 AM Andy Bierman  wrote:
> 
> >
> > libxml2 has an API to get the namespace for a string node.
> >
> 
> Just to get the terms correct, it's not the "namespace" you need to get,
> you need to get the XML prefix mapped to that namespace, and the prefix has
> to be the same inside the element.
> 
> Not all XML is processed with libxml2, and not all XML processors make the
> namespace prefixes available, and such processors won't be able to process
> these YANG instances correctly.

If an XML document has , won't the XML processor
pass the attribute "xmlns:bar" and its value to the application?  This
should be enough even if the XML processor doesn't provide a mapping
table between prefix and namespace (it requires more work in the
application of course).

> > A YANG parser needs to know identityref is handled differently than a
> > plain string.
> >
> Exactly.  In particular, it must uses prefixes that are consistent with
> those declared in the "xmlns:whatever" attribute. So, the RFC should say
> that.

I think that if special text is needed for identityref values in XML,
that text should go in to the YANG specification (RFC 7950).  All
these other drafts just follow the rules defined in RFC 7950.


/martin



> 
> 
> 
> 
> 
> >
> >
> > Andy
> >
> >
> >> I've excerpted an email exchange with Ian Farrer that I think makes the
> >> potential problem concrete:
> >>
> >> Hi Ian, I don't think we've met.  I'm the grumpy person on the "XML
> >> Directorate" who's been whining about the namespace prefixes in YANG
> >> internet-drafts. One quick issue: I'm a little surprised, is anyone still
> >> using XML in this kind of thing any more in 2021?
> >>
> >> Anyhow, below I've excerpted the issue that's still troubling me. Here's
> >> the XML:
> >>
> >>   >>  xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>  
> >>eth0
> >>ianaift:ethernetCsmacd
> >>DHCPv6 Relay Interface
> >>true
> >>  
> >>
> >>
> >> So my question is, I see the XML namespace prefix and the prefix for the
> >>  element content are identical. Is this a coincidence?  For example,
> >> would the following work, changing the namespace prefix to "foo"?
> >>
> >>
> >>   >>  xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>  
> >>eth0
> >>ianaift:ethernetCsmacd
> >>DHCPv6 Relay Interface
> >>true
> >>  
> >>
> >>
> >> [if - This example would not work and fails validation with yanglint:
> >>
> >> $ yanglint --strict --verbose -t config -p $IETFYANG
> >> $IETFYANG/iana-if-type.yang $IETFYANG/ietf-interfaces.yang test1.xml
> >> err : Invalid value "ianaift:ethernetCsmacd" in "type" element.
> >> (/ietf-interfaces:interfaces/interface[name='eth0']/type)
> >> ]
> >>
> >>
> >> Follow-up, would the following work, foo for both namespace and content
> >> prefix?
> >>
> >>  >>  xmlns:foo="urn:ietf:params:xml:ns:yang:iana-if-type">
> >>  
> >>eth0
> >>foo:ethernetCsmacd
> >>DHCPv6 Relay Interface
> >>true
> >>  
> >>
> >>
> >> Thanks in advance!
> >>
> >>
> >> [if - This does validate with yanglint, however the convention in the
> >> IETF examples I’ve seen seems to be to use the prefix that is defined in
> >> the original YANG module for imports for consistency, e.g. (from
> >> iana-if-type.yang):
> >>
> >>
> >> On Thu, Feb 3, 2022 at 8:03 AM Andy Bierman  wrote:
> >>
> >>> Hi,
> >>>
> >>> I think the text from sec 4 refers to the usage within an application.
> >>> The XML instance document is the on-the-wire representation and
> >>> the I-D example looks correct.
> >>>
> >>> https://www.w3.org/TR/xml-names/#ns-qualnames
> >>>
> >>>
> >>> Andy
> >>>
> >>>
> >>> On Thu, Feb 3, 2022 at 3:53 AM tom petch  wrote:
> >>>
>  From: netmod  on behalf of ianfar...@gmx.com <
>  ianfar...@gmx.com>
>  Sent: 03 February 2022 09:37
> 
>  Hi,
> 
>  A draft I have been working on (
>  https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/) contains
>  a number of XML configuration examples. During the XML expert review, a
>  question has been raised about the use of XML namespaces in these 
>  examples.
>  I’m raising it here as I don’t have the XML knowledge to answer.
> 
>  
> 
>  Ian
> 
>  This looks like the issue I raised on this list 14jan2022 with a
>  subject line of
>  XML and prefix
>  although I have not checked that the usage is exactly the same; the
>  'XML Expert' comment would appear to be.
> 
>  Tom Petch
> 
>  In my example:
> 
>   
>   xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
>   
> eth0
> ianaift:ethernetCsmacd
> DHCPv6 Relay Interface
> true
>   
> 
> 
>  The question is related to the use of the ‘ianaift:’ prefix. This is
> >

Re: [netmod] Should an empty enumeration be allowed within a union?

[Martin Björklund]

Hi,

Nick Hancock  wrote:
> Hi,
> 
> We need some advice on whether the following can be considered as 
> valid YANG syntax and whether the behavior is that which we expect.
> 
> We have a use case (simplified in the example below) where a client is
> required to define a certain concrete integer value for a server to 
> use for some purpose, which is represented by the leaf 'foo' in the 
> example below. 
> 
> On some servers we want to offer an additional option of an automatic 
> assignment of this value by the server. To this end, we defined a 
> union of an integer type and an enumeration with one enum 
> 'auto-select', as shown below. Since the support of 'auto-select' is 
> optional, it is tagged with an if-feature statement. Note that there 
> will also be additional data nodes in the schema tree that are 
> associated with this configuration and will also be dependent on this 
> feature.
>   
>   leaf foo {
> type union {
>   type uint8;
>   type enumeration {
> enum auto-select {
>   if-feature "auto-select-foo";
>   description
> "The server automatically selects a value for foo.";
> }
>   }
> }
> mandatory true;
> description
>   "The value of foo.";
>   }
>   
> According to RFC 7950 section 9.6.4, an enum statement must be 
> present within an enumeration definition. If the feature 'auto-select-
> foo' is not supported by a server, does the enumeration still comply 
> with this requirement given that there is an enum statement present? 
> 
> According to yanger it does not. Is yanger wrong? 
> 
> If the YANG is compiled without the feature, yanger currently reports 
> the following error:
>   "error: a type enumeration must have at least one enum statement".
> 
> The requirement that an enumeration must have at least one enum
> would make sense, if the type for a leaf was just an enumeration, 
> because otherwise a client would not be able to configure a valid 
> value. 
> 
> However, it could be argued that in the case of the union, there would
> be no issue with the enumeration being an empty set as the client 
> would nevertheless be able to define a valid value and fulfill the 
> 'mandatory' requirement as a result of the other types in the union, 
> in the example above the uint8.

I agree.

> What is NETMOD's opinion on this? Could the above example be seen as 
> valid YANG syntax?

I think so.  I think yanger is wrong in this case.  Perhaps it would
be possible to come up with some clever little rules in the spec that
make this case legal, but make the same enumeration w/o the union
illegal.  But I don't think it would be worth it; with the
expressiveness of YANG it is possible to create models that don't make
any sense, e.g.,

  type string {
pattern "x";
pattern "x" {
  modifier invert-match;
}
  }

or

  leaf foo {
type int32;
mandatory true;
  }
  leaf bar {
mandatory true;
type int32;
must "../foo = 'hello'";
  }

etc.

So I think that even this nonsensical example is "legal":

  leaf foo {
type enumeration {
  enum x {
if-feature bar;
  }
}
  }


> If this is not the case, then we have an issue as we would have to 
> remove the if-feature statement from the enum. Having done this, a 
> client would then be able to configure the value 'auto-select' on 
> servers that do not support the feature, which is of course is
> undesirable.
> 
> Assuming that the use of an empty enumeration is valid, if the feature
> 'auto-select-foo' is not supported, is it true that only an integer of
> type unit8 would then be allowed?

Yes, that's the only reasonable interpretation.


/martin

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

Re: [netmod] XML and prefix

[Martin Björklund]

tom petch  wrote:
> From: Martin Björklund 
> Sent: 14 January 2022 11:23
> 
> Hi,
> 
> Ok, I think I understand what he means.  With this XML:
> 
>   
>   nsfmi:memory-alarm
>   
> 
> the prefix "nsfmi" is present in the element data, which means that
> in order to implement this properly, the XML parser must pass the
> namespace mappings to the user code.
> 
> So he proposes to add to the draft:
> (from https://mailarchive.ietf.org/arch/msg/i2nsf/06kJ7vS6X-0hUmGHrCWN-jVzU7M)
> 
> 11.  XML Examples for I2NSF NSF Monitoring
> 
>This section shows the XML examples of I2NSF NSF Monitoring data
>delivered via Monitoring Interface from an NSF.  In order for the XML
>to work, the prefix in the element that uses "identityref" type
>(e.g., /i2nsf-event/i2nsf-system-detection-alarm/alarm-category/) in
>the YANG module described in this document MUST be the same as the
>namespace prefix for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
>monitoring.  The XML software MUST be chosen that makes the namespace
>prefix information available.
> 
> 
> I think this is a bit odd.  Who is supposed to act on the first MUST?
> This text is about an example, which is what it is, and it happens to
> be correct.
> 
> Also, the text about XML software seems unnecessary to me.  It follows
> from the definition of an identityref in RFC 7950 that the namespace
> mapping is needed to parse this correctly.
> 
> 
> 
> Martin,
> 
> Again, thank you.  My initial take was that defining the prefix in 
> alarm-category makes that the default so that the prefix is not needed on 
> 'memory-alarm' but my XML is getting a bit rusty!

Almost ;-)  RFC 7950 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 in this particular case, the example could instead be written as:

  memory-alarm

b/c the default namespace in effect is

  urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring


/martin



> 
> Tom Petch
> /martin
> 
> 
> 
> 
> 
> Ladislav Lhotka  wrote:
> > On 14. 01. 22 11:39, Martin Björklund wrote:
> > > Hi,
> > > I don't understand the problem either.  He writes:
> > >
> > >> Sorry, but this has the same problem in figure 11.1 that we've just
> > >> been
> > >> discussing with Ian.
> > > Can you send a pointer to that discussion?  Perhaps there's more
> > > context there.
> >
> > Right. I also suspect that the last sentence should have been
> >
> > "I don't think it's OK for the draft to say those things."
> >
> > Lada
> >
> > > /martin
> > > tom petch  wrote:
> > >> I see that IANA have taken to asking XML Registry experts about the
> > >> registration of YANG namespaces at Last Call, or perhaps they have
> > >> always done this but have only recently put the e-mail on a public
> > >> list.  Anyhow, the experts have taken it upon themselves to comment on
> > >> the XML examples and I do not understand this comment.  This comes
> > >> from
> > >> [IANA #1217705] Expert Review for
> > >> draft-ietf-i2nsf-nsf-monitoring-data-model-12 (xml-registry)
> > >> by Tim Bray 17 dec 2021 03:03
> > >>
> > >> ===
> > >> Sorry, but this has the same problem in figure 11.1 that we've just
> > >> been
> > >> discussing with Ian.
> > >>
> > >> For it to work, (a) the prefix in the alarm-category element MUST be
> > >> the
> > >> same as the namespace prefix for
> > >> urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring, which means
> > >> that XML
> > >> software MUST be chosen that makes the namespace prefix information
> > >> available.  I don't think it's OK for the draft not to say those
> > >> thigns.
> > >>
> > >>  > >> xmlns:nsfmi="urn:ietf:params:xml:ns:yang:\
> > >>ietf-i2nsf-nsf-monitoring">
> > >> nsfmi:memory-alarm
> > >>   
> > >> =
> > >> a) I am unclear what the problem is - I thought that XML allowed great
> > >> freedom with prefix even if the IETF would rather not
> > >> b) this suggestion seems to be that all I-D with XML examples, which
> > >> is pretty much every I-D with a YANG module in it, needs to carry a
> > >> warning about what XML software to choose, which seems rather a
> > >> burden.  Thoughts?
> > >>
> > >> Tom Petch
> > >>
> > >>
> > >>
> > >>
> > >> ___
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] XML and prefix

[Martin Björklund]

Hi,

Ok, I think I understand what he means.  With this XML:

  
  nsfmi:memory-alarm
  

the prefix "nsfmi" is present in the element data, which means that
in order to implement this properly, the XML parser must pass the
namespace mappings to the user code.

So he proposes to add to the draft:
(from https://mailarchive.ietf.org/arch/msg/i2nsf/06kJ7vS6X-0hUmGHrCWN-jVzU7M)

11.  XML Examples for I2NSF NSF Monitoring

   This section shows the XML examples of I2NSF NSF Monitoring data
   delivered via Monitoring Interface from an NSF.  In order for the XML
   to work, the prefix in the element that uses "identityref" type
   (e.g., /i2nsf-event/i2nsf-system-detection-alarm/alarm-category/) in
   the YANG module described in this document MUST be the same as the
   namespace prefix for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
   monitoring.  The XML software MUST be chosen that makes the namespace
   prefix information available.


I think this is a bit odd.  Who is supposed to act on the first MUST?
This text is about an example, which is what it is, and it happens to
be correct.

Also, the text about XML software seems unnecessary to me.  It follows
from the definition of an identityref in RFC 7950 that the namespace
mapping is needed to parse this correctly.


/martin





Ladislav Lhotka  wrote:
> On 14. 01. 22 11:39, Martin Björklund wrote:
> > Hi,
> > I don't understand the problem either.  He writes:
> > 
> >> Sorry, but this has the same problem in figure 11.1 that we've just
> >> been
> >> discussing with Ian.
> > Can you send a pointer to that discussion?  Perhaps there's more
> > context there.
> 
> Right. I also suspect that the last sentence should have been
> 
> "I don't think it's OK for the draft to say those things."
> 
> Lada
> 
> > /martin
> > tom petch  wrote:
> >> I see that IANA have taken to asking XML Registry experts about the
> >> registration of YANG namespaces at Last Call, or perhaps they have
> >> always done this but have only recently put the e-mail on a public
> >> list.  Anyhow, the experts have taken it upon themselves to comment on
> >> the XML examples and I do not understand this comment.  This comes
> >> from
> >> [IANA #1217705] Expert Review for
> >> draft-ietf-i2nsf-nsf-monitoring-data-model-12 (xml-registry)
> >> by Tim Bray 17 dec 2021 03:03
> >>
> >> ===
> >> Sorry, but this has the same problem in figure 11.1 that we've just
> >> been
> >> discussing with Ian.
> >>
> >> For it to work, (a) the prefix in the alarm-category element MUST be
> >> the
> >> same as the namespace prefix for
> >> urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring, which means
> >> that XML
> >> software MUST be chosen that makes the namespace prefix information
> >> available.  I don't think it's OK for the draft not to say those
> >> thigns.
> >>
> >>  >> xmlns:nsfmi="urn:ietf:params:xml:ns:yang:\
> >>ietf-i2nsf-nsf-monitoring">
> >> nsfmi:memory-alarm
> >>   
> >> =
> >> a) I am unclear what the problem is - I thought that XML allowed great
> >> freedom with prefix even if the IETF would rather not
> >> b) this suggestion seems to be that all I-D with XML examples, which
> >> is pretty much every I-D with a YANG module in it, needs to carry a
> >> warning about what XML software to choose, which seems rather a
> >> burden.  Thoughts?
> >>
> >> Tom Petch
> >>
> >>
> >>
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] XML and prefix

[Martin Björklund]

Hi,

I don't understand the problem either.  He writes:

> Sorry, but this has the same problem in figure 11.1 that we've just been
> discussing with Ian.

Can you send a pointer to that discussion?  Perhaps there's more
context there.


/martin


tom petch  wrote:
> I see that IANA have taken to asking  XML Registry experts about the 
> registration of YANG namespaces at Last Call, or perhaps they have always 
> done this but have only recently put the e-mail on a public list.  Anyhow, 
> the experts have taken it upon themselves to comment on the XML examples and 
> I do not understand this comment.  This comes from  
> [IANA #1217705] Expert Review for 
> draft-ietf-i2nsf-nsf-monitoring-data-model-12 (xml-registry)
> by Tim Bray 17 dec 2021 03:03
> 
> ===
> Sorry, but this has the same problem in figure 11.1 that we've just been
> discussing with Ian.
> 
> For it to work, (a) the prefix in the alarm-category element MUST be the
> same as the namespace prefix for
> urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring, which means that XML
> software MUST be chosen that makes the namespace prefix information
> available.  I don't think it's OK for the draft not to say those thigns.
> 
> xmlns:nsfmi="urn:ietf:params:xml:ns:yang:\
>   ietf-i2nsf-nsf-monitoring">
>nsfmi:memory-alarm
>  
> =
> a) I am unclear what the problem is - I thought that XML allowed great 
> freedom with prefix even if the IETF would rather not
> b) this suggestion seems to be that all I-D with XML examples, which is 
> pretty much every I-D with a YANG module in it,  needs to carry a warning 
> about what XML software to choose, which seems  rather a burden.  Thoughts?
> 
> Tom Petch
> 
> 
> 
> 
> ___
> 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 'when' with absolute path

[Martin Björklund]

Hi,

Ladislav Lhotka  wrote:
> Carsten Bormann  writes:
> 
> > On 2021-12-30, at 13:29, tom petch  wrote:
> >> 
> >>   when "../../../../../../nw:network-types/tet:te-topology/“
> >
> > I’m probably showing my ignorance about YANG again, but what is the reason 
> > this is not phrased as
> >
> >   when "./ancestor::nw:network-types/tet:te-topology/“
> 
> Yes, this would work, with a minor correction:
> 
> when "./ancestor::node()/nw:network-types/tet:te-topology"
> 
> because 'nw:network-types' isn't an ancestor of the context node. Also, the 
> initial './' isn't actually needed, hence
> 
> when "ancestor::node()/nw:network-types/tet:te-topology"

Or the more direct:

when "ancestor::nw:network/nw:network-types/tet:te-topology"

This style works if we can guarantee that there will be exactly one
node "nw:network" among our ancestors.

It is perhaps easier to get this style right w/o a YANG compiler
(which would detect if the number of ".." in the relative path is
wrong), but the relative path might be easier to understand for a
casual reader.



/martin



> 
> Lada
> 
> >
> > ?
> >
> > Grüße, Carsten
> >
> > ___
> > 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] YANG 'when' with absolute path

[Martin Björklund]

Hi,


tom petch  wrote:
> Any one of many, many YANG modules from such as TEAS and CCAMP have dozens 
> and dozens of augment, some more than a 100, almost all controlled by 'when'. 
>  The 'when' are almost all performing the same test for a presence container 
> for the network type but because the tree is ten deep and the augments take 
> place at different levels and the 'when' use the relative form of the Xpath 
> statement, then the 'when' take many different forms and it is not obvious 
> that they are correct.
> 
> Is there a drawback to using the absolute form of the Xpath statement which 
> would then always be the same?
> 
> Thus
>A YANG Data Model for Flexi-Grid Optical Networks
>draft-ietf-ccamp-flexigrid-yang-11
> has
> 
>when "../../../../../../nw:network-types/tet:te-topology/"
>   + "flexgt:flexi-grid-topology" {
>when "../../../../../nw:network-types/tet:te-topology/"
>   + "flexgt:flexi-grid-topology" {
>when "../../../../nw:network-types/tet:te-topology/"
>   + "flexgt:flexi-grid-topology" {
> 
> which could be 
>when "/nw:networks/nw:network/nw:network-types"
>   + "/tet:te-topology/flexgt:flexi-grid-topology" {

This is not the same as the relative paths, since "nw:network" is a
list.  If there is one network with
nw:network-types/tet:te-topology/flexgt:flexi-grid-topology set, then
this expression always returns true!


/martin




> 
> if I understand aright.
> 
> Tom Petch
> ___
> 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] Must offline-validation of alone be valid?

[Martin Björklund]

Hi,

Kent Watsen  wrote:
> Andy, et. al., 
> 
> 
> >> I cannot find any RFC text that says  has only nodes created
> >> by a client.
> > 
> > Really?  Interesting.  Still, I know it’s a mantra we’ve held closely
> > for many year, right?
> > 
> > No. Quite the opposite.  
> 
> There was a brouhaha back when I proposed the "keystore” draft have an
> “action” called “generate-private-key” that would insert the generated
> key into .  Claims were made by prominent members of this
> list that it’s bad form for anything but a client to edit .

The problem with an action that is supposed to modify the running
config is that it also has to be prepared to handle systems with
, handle locks etc.  And if you don't have  you
may want to add the private-key together with other data in one go;
this is not possible if it was added by an action.

For the purpose of adding "built-in list instances" (which seems to be
the use case for the proposed solution), I think the factory-default
datastore can be used.  (this is actually better than the server
"acting as a client").


/martin


> 
> As a result, extensive effort was spent defining a mechanism enabling
> the generated key to be returned in the RPC-reply in an encrypted form
> (such that only the server that generated the key could decrypt it),
> all so the client could immediately return it to the server via a
> config push in order to preserve the sanctity of client read-backs.
> 
> If current claims were true then, why didn’t someone just say it’s
> okay since the server is acting like a client under the hood?
> 
> K.
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Can a derived type of instance-identifier change the require-instance property?

[Martin Björklund]

Hi,


"Fengchong \(frank\)"  wrote:
> Hi all and martin,
> 
> If I have defined a typedef a
> typedef a {
>   type instance-identifier {
>   require-instance false;
>   }
> }
> 
> And then I define another typedef b
> 
> typedef b {
>   type a {
> require-instance true;
>   }
> 
> }
> 
> Is it correct?

Yes.  However, it is not clear if this is allowed:

   typedef c {
 type b {
   require-instance false;
 }
   }

Note how section 7.4 in RFC 7950 says:

   The "type" statement takes as an argument a string that is the name
   of a YANG built-in type (see Section 9) or a derived type (see
   Section 7.3), followed by an optional block of substatements that is
   used to put further restrictions on the type.
   

This implies that a subtype cannot expand the value space, which would
make "c" above illegal.

This was the intention, but it could be made more clear.  In many
other cases it is explicitly mentioned, e.g. in 9.4.5:

   If a pattern restriction is applied to a type that is already
   pattern-restricted, values must match all patterns in the base type,
   in addition to the new patterns.

> The same scenario is leafref.

Same answer as above.


/martin



> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI, 
> which is intended only for the person or entity whose address is listed 
> above. Any use of the information contained herein in any way (including, but 
> not limited to, total or partial disclosure, reproduction, or dissemination) 
> by persons other than the intended recipient(s) is prohibited. If you receive 
> this e-mail in error, please notify the sender by phone or email immediately 
> and delete it!
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Must offline-validation of alone be valid?

[Martin Björklund]

Hi,

Kent Watsen  wrote:
> Hi Andy,

> > I cannot find any RFC text that says system-injected config is
> > special, especially since
> > server implementations exist that treat these edits as just another
> > client
> > (although probably a 'root' user client).
> 
> Very true (and Juergen’s point as well).  I’ve seen this done before.
> Unhappy results.

Can you elaborate on this, or send a pointer if it has been documented
somewhere?

I will also add a +1 to letting the system "act as a client" and put
data into running.  This is what we do in our current project.

A few other comments.

The name "system" for this new proposed datastore is perhaps not the
best, since RFC 8342 already defines this term, and associated
semantics.

If the new proposed datastore is supposed to add static data like
"built-in profiles and policies", it is rather limited, compared to
"system config" as defined in RFC 8342.  The reason is that system
config can be injected at various levels in the config hierarchy;
specifically also under user-defined list entries.   And if this is
indeed the use case you (as in all proponents of the proposal) have in
mind, I think the solution with adding this to  works.  (But
I am curious to hear your experience of this).


> 
> 
> As a co-author, I know this was the intention of RFC 8342, which is
> supported by, for instance:
> 
> 
> Section 4.1:
> 
>o  Several implementations have proprietary mechanisms that allow
>   clients to store inactive data in .  Inactive data is
>   conceptually removed before validation.
> 
>o  Some implementations have proprietary mechanisms that allow
>   clients to define configuration templates in .  These
>   templates are expanded automatically by the system, and the
>   resulting configuration is applied internally.

Right, and in both cases, the idea was that  contains all
data needed for the transformation into .  So a client that
wants to do "offline" validation would need the data + the
transformation algorithms.  But no additional data.


/martin



> 
> Section 5:
> 
>  // subject to validation
> 
> Section 5.1.4:
> 
> is tightly coupled to .  Whenever data is written
>to , the server MUST also immediately update and validate
>.
> 
> 
> 
> 
> 
> Of course, some will point to Section 5.1.3:
> 
>However,  MUST always be a valid configuration data tree,
>as defined in Section 8.1 of [RFC7950]
>.
> 
> But it has to be obvious that this is a bug.  For instance,
> 
>   - YANG defines a leaf is of type union { uint8 | variable }
>   -  defines the leaf having value “MAX_FOOBAR” 
> with a template that defines MAX_FOOBAR=1000.
>   - so,  would be syntactically valid but
> semantically invalid.
> 
> Or a more egregious example:
> 
>   - YANG defines a "max-elements" value “MAX_FOOBAR”
>- how is this possible when RFC 7950 says max-elements
>   Is a positive integer or the string “unbounded”?
>- so now we’re into YANG-next territory as far as
>  templates are concerned, but hang with me a little
>  while longer…
>   -  has a template that defines MAX_FOOBAR=3
>   - how coulda server validate if ’s list contained less
> than max-elements?  Worse, what if the result of another 
> template added more elements to the list?
> 
> 
> I may have taken off the flame suit too early  ;)
> 
> K.
> 
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Resolving schema node identifier

[Martin Björklund]

Michal Vaško  wrote:
> > > Michal Vaško  wrote:
> > > > > Michal Vaško  wrote:
> > > > > > Hello,
> > > > > > > I would like to get some input for a use-case I came across, which
> > > > > > > to>
> > > > > > > me does not seem to have any consistent rules that can be applied.
> > > > > > > module mod_b {
> > > > > > namespace "x:example:mod_b";
> > > > > > prefix "mb";
> > > > > > > grouping mylist_wrapper {
> > > > > > list mylist {
> > > > > > key "name";
> > > > > > unique "value";
> > > > > > leaf name {
> > > > > > type string;
> > > > > > }
> > > > > > leaf value {
> > > > > > type uint32;
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > > > list mylist2 {
> > > > > > key "a";
> > > > > > leaf a {
> > > > > > type string;
> > > > > > }
> > > > > > leaf b {
> > > > > > type string;
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > > > > module mod_a {
> > > > > > namespace "x:example:mod_a";
> > > > > > prefix "ma";
> > > > > > > import mod_b { prefix "mb"; }
> > > > > > > container root {
> > > > > > uses mb:mylist_wrapper;
> > > > > > }
> > > > > > > augment /mb:mylist2 {
> > > > > > leaf c {
> > > > > > type string;
> > > > > > }
> > > > > > }
> > > > > > > deviation /mb:mylist2 {
> > > > > > deviate add {
> > > > > > unique "mb:b c";
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > > > The focus is on the "unique" statements and how to resolve
> > > > > > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > > > > > of schema node identifiers"[1], which use "current module" for
> > > > > > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > > > > > years back what current module means and the answer I got was the> >
> > > > > > > module where the statement is defined.
> > > > > > > So let's get to the examples. As they are written, the unique in
> > > > > > "mylist" should be wrong because the node "value" belongs to the
> > > > > > module "mod_a" when the grouping is instantiated there, but unique
> > > > > > is>
> > > > > > defined in the module "mod_b".
> > > > > > > But even if we use the other understanding of current module and
> > > > > > interpret is as the module of the context node of the statement
> > > > > > (corresponds to the "current()" XPath function), then the other
> > > > > > "unique" in the deviation cannot be resolved. It is referencing node
> > > > > > "c", which belongs to the module "mod_a" (added by an augment) but
> > > > > > the
> > > > > > current module would then be "mod_b".
> > > > > > > To summarize, if strictly following the specs, the "unique" in the
> > > > > > "mylist" should probably reference "value" with a prefix, but that
> > > > > > is>
> > > > > > not possible because "mod_a" is not even imported and it generally
> > > > > > does not make sense. But then I cannot think of any consistent rule
> > > > > > to
> > > > > > successfully resolve both "unique" statements in this example. Can
> > > > > > anyone help me with this, please?
> > > > > > > Compare with this:
> > > > > > >  grouping mylist_wrapper {
> > > > >  list mylist {
> > > > >  key "name";
> > > > >  unique "value";
> > > > >  must "value > 42";
> > > > >  leaf name {
> > > > >  type string;
> > > > >  }
> > > > >  leaf value {
> > > > >  type uint32;
> > > > >  }
> > > > >  }
> > > > >  }
> > > > > > > I think the rules for the prefixes in "unique" should be the same
> > > > > > > as
> > > > > for "must".  So I think that the correct syntax is to not use any
> > > > > prefix in "unique".
> > > > > > > And the deviation that adds a unique statement look correct.
> > > > > Thanks for the reply but I do not think you have answered my
> > > > question. Please formulate a formal rule how to assign modules to
> > > > non-prefixed identifiers, whether they be in "unique", "must", or any>
> > > > other statement with identifiers. That is what I need to implement it>
> > > > properly and I am simply not able to come up with any that would be
> > > > consistent and compliant with the specification.
> > > 
> > > Interpret the unique argument the same way as an XPath expression, and
> > > apply (from 6.4.1):
> > > 
> > >o  Names without a namespace prefix belong to the same namespace as
> > >   the identifier of the current node.  Inside a grouping, that
> > >   namespace is affected by where the grouping is used
> > > 
> > > So "value" in the unique statement will refer to "value" in "mod_a"
> > > when the grouping is used in "mod_a".
> > 
> > I see. Okay, this should be possible to implement, thanks.
> 
> I

Re: [netmod] Resolving schema node identifier

[Martin Björklund]

Michal Vaško  wrote:
> > Michal Vaško  wrote:
> > > Hello,
> > > > I would like to get some input for a use-case I came across, which to>
> > > > me does not seem to have any consistent rules that can be applied.
> > > > module mod_b {
> > > namespace "x:example:mod_b";
> > > prefix "mb";
> > > > grouping mylist_wrapper {
> > > list mylist {
> > > key "name";
> > > unique "value";
> > > leaf name {
> > > type string;
> > > }
> > > leaf value {
> > > type uint32;
> > > }
> > > }
> > > }
> > > > list mylist2 {
> > > key "a";
> > > leaf a {
> > > type string;
> > > }
> > > leaf b {
> > > type string;
> > > }
> > > }
> > > }
> > > > > module mod_a {
> > > namespace "x:example:mod_a";
> > > prefix "ma";
> > > > import mod_b { prefix "mb"; }
> > > > container root {
> > > uses mb:mylist_wrapper;
> > > }
> > > > augment /mb:mylist2 {
> > > leaf c {
> > > type string;
> > > }
> > > }
> > > > deviation /mb:mylist2 {
> > > deviate add {
> > > unique "mb:b c";
> > > }
> > > }
> > > }
> > > > The focus is on the "unique" statements and how to resolve
> > > non-prefixed identifiers. RFC 7950 says that the argument is a "list
> > > of schema node identifiers"[1], which use "current module" for
> > > non-prefixed identifiers[2]. I have asked on this mailing list a few
> > > years back what current module means and the answer I got was the
> > > module where the statement is defined.
> > > > So let's get to the examples. As they are written, the unique in
> > > "mylist" should be wrong because the node "value" belongs to the
> > > module "mod_a" when the grouping is instantiated there, but unique is>
> > > defined in the module "mod_b".
> > > > But even if we use the other understanding of current module and
> > > interpret is as the module of the context node of the statement
> > > (corresponds to the "current()" XPath function), then the other
> > > "unique" in the deviation cannot be resolved. It is referencing node
> > > "c", which belongs to the module "mod_a" (added by an augment) but the
> > > current module would then be "mod_b".
> > > > To summarize, if strictly following the specs, the "unique" in the
> > > "mylist" should probably reference "value" with a prefix, but that is>
> > > not possible because "mod_a" is not even imported and it generally
> > > does not make sense. But then I cannot think of any consistent rule to
> > > successfully resolve both "unique" statements in this example. Can
> > > anyone help me with this, please?
> > 
> > Compare with this:
> > 
> >  grouping mylist_wrapper {
> >  list mylist {
> >  key "name";
> >  unique "value";
> >  must "value > 42";
> >  leaf name {
> >  type string;
> >  }
> >  leaf value {
> >  type uint32;
> >  }
> >  }
> >  }
> > 
> > I think the rules for the prefixes in "unique" should be the same as
> > for "must".  So I think that the correct syntax is to not use any
> > prefix in "unique".
> > 
> > And the deviation that adds a unique statement look correct.
> 
> Thanks for the reply but I do not think you have answered my
> question. Please formulate a formal rule how to assign modules to
> non-prefixed identifiers, whether they be in "unique", "must", or any
> other statement with identifiers. That is what I need to implement it
> properly and I am simply not able to come up with any that would be
> consistent and compliant with the specification.

Interpret the unique argument the same way as an XPath expression, and
apply (from 6.4.1):

   o  Names without a namespace prefix belong to the same namespace as
  the identifier of the current node.  Inside a grouping, that
  namespace is affected by where the grouping is used

So "value" in the unique statement will refer to "value" in "mod_a"
when the grouping is used in "mod_a".


/martin

> 
> > /martin
> > 
> > > Finally, I am asking because I am trying to implement this correctly
> > > in yanglint. I have also tried to test these examples with pyang,
> > > which, however, seems to not have any consistent rules applied because
> > > it loads these examples without warnings. No warnings are printed even
> > > if the "unique" in the deviation is changed to "b c", which is
> > > definitely wrong since node "b" belongs to "mod_b" and node "c"
> > > belongs to "mod_a".
> > > > Thanks,
> > > Michal
> > > > [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3
> > > [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5
> > > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/

Re: [netmod] Resolving schema node identifier

[Martin Björklund]

Hi,

Michal Vaško  wrote:
> Hello,
> 
> I would like to get some input for a use-case I came across, which to
> me does not seem to have any consistent rules that can be applied.
> 
> module mod_b {
> namespace "x:example:mod_b";
> prefix "mb";
> 
> grouping mylist_wrapper {
> list mylist {
> key "name";
> unique "value";
> leaf name {
> type string;
> }
> leaf value {
> type uint32;
> }
> }
> }
> 
> list mylist2 {
> key "a";
> leaf a {
> type string;
> }
> leaf b {
> type string;
> }
> }
> }
> 
> 
> module mod_a {
> namespace "x:example:mod_a";
> prefix "ma";
> 
> import mod_b { prefix "mb"; }
> 
> container root {
> uses mb:mylist_wrapper;
> }
> 
> augment /mb:mylist2 {
> leaf c {
> type string;
> }
> }
> 
> deviation /mb:mylist2 {
> deviate add {
> unique "mb:b c";
> }
> }
> }
> 
> The focus is on the "unique" statements and how to resolve
> non-prefixed identifiers. RFC 7950 says that the argument is a "list
> of schema node identifiers"[1], which use "current module" for
> non-prefixed identifiers[2]. I have asked on this mailing list a few
> years back what current module means and the answer I got was the
> module where the statement is defined.
> 
> So let's get to the examples. As they are written, the unique in
> "mylist" should be wrong because the node "value" belongs to the
> module "mod_a" when the grouping is instantiated there, but unique is
> defined in the module "mod_b".
> 
> But even if we use the other understanding of current module and
> interpret is as the module of the context node of the statement
> (corresponds to the "current()" XPath function), then the other
> "unique" in the deviation cannot be resolved. It is referencing node
> "c", which belongs to the module "mod_a" (added by an augment) but the
> current module would then be "mod_b".
> 
> To summarize, if strictly following the specs, the "unique" in the
> "mylist" should probably reference "value" with a prefix, but that is
> not possible because "mod_a" is not even imported and it generally
> does not make sense. But then I cannot think of any consistent rule to
> successfully resolve both "unique" statements in this example. Can
> anyone help me with this, please?

Compare with this:

 grouping mylist_wrapper {
 list mylist {
 key "name";
 unique "value";
 must "value > 42";
 leaf name {
 type string;
 }
 leaf value {
 type uint32;
 }
 }
 }

I think the rules for the prefixes in "unique" should be the same as
for "must".  So I think that the correct syntax is to not use any
prefix in "unique".

And the deviation that adds a unique statement look correct.


/martin

> Finally, I am asking because I am trying to implement this correctly
> in yanglint. I have also tried to test these examples with pyang,
> which, however, seems to not have any consistent rules applied because
> it loads these examples without warnings. No warnings are printed even
> if the "unique" in the deviation is changed to "b c", which is
> definitely wrong since node "b" belongs to "mod_b" and node "c"
> belongs to "mod_a".
> 
> Thanks,
> Michal
> 
> [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.8.3
> [2] https://datatracker.ietf.org/doc/html/rfc7950#section-6.5
> 
> ___
> 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] too long lines from IANA module inclusion

[Martin Björklund]

Kent Watsen  wrote:
> 
> 
> > On Dec 12, 2021, at 5:11 PM, Michael Richardson
> >  wrote:
> > 
> > 
> > Carsten Bormann  wrote:
> >> On 2021-12-12, at 22:17, Michael Richardson 
> >> wrote:
> > 
> >>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it
> >>> RFC8791.
> >> […]
> >>> What I don't know how to deal with:
> > 
> >> RFC 8792?
> > 
> > If I put \ into the original .yang file, then it won't process.
> > So if RFC8792 is the solution, then I think that I probably prefer to
> > have
> > ::include do it.  Otherwise, I have to add another step to the
> > workflow.
> > 
> > I'd also want assurance that the YANG module extractor knows about
> > 8792.
> > Maybe given that Kent is a leader author on that... it's already taken
> > care of.
> 
> `pyang` and I think `yanglint` also know how to extract folded
>  and  elements.

Just a correction; pyang doesn't extract anything, but rfcstrip does,
and it supports folded artwork, and in the latest greatest 1.3 release
it even reconizes the proper RFC8792-defined magic strings ;-)


/martin


> 
> That said, I have never needed to fold a YANG module in an I-D.  As
> Juergen mentioned, YANG’s built-in mechanisms have always enabled me
> to fit within 69-columns.
> 
> Unsure about module-extractor.  My guess is that it will barf   ;)
> 
> K.
> 
> 
> ___
> 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 the case statement's sub-statements

[Martin Björklund]

Hi,


"Fengchong \(frank\)"  wrote:
> Hi folks and martin,
>   I’m writing a yang parser. I notice the case statement has no 
> ‘notification’ and ‘action’ sub-statements, but have ‘uses’ sub-statement. 
> And the ‘grouping’ statement has ‘action’ and ‘notification’ sub-statements. 
> If case’s use statement point to a grouping(we assume the grouping has action 
> and notification statements),

This is not allowed.

Section 7.15 says:

   Since an action cannot be defined at the top level of a module or in
   a "case" statement, it is an error if a grouping that contains an
   action at the top of its node hierarchy is used at the top level of a
   module or in a case definition.


Section 7.16 says:

   Since a notification cannot be defined in a "case" statement, it is
   an error if a grouping that contains a notification at the top of its
   node hierarchy is used in a case definition.


(But see https://github.com/netmod-wg/yang-next/issues/84)



/martin


> The case statement in fact has ‘action’ and ‘notification’ 
> sub-statements(expanded by uses).
>   So, why case statement can not support define ‘action’ and ‘notification’ 
> sub-statements directly?




> 
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI, 
> which is intended only for the person or entity whose address is listed 
> above. Any use of the information contained herein in any way (including, but 
> not limited to, total or partial disclosure, reproduction, or dissemination) 
> by persons other than the intended recipient(s) is prohibited. If you receive 
> this e-mail in error, please notify the sender by phone or email immediately 
> and delete it!
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

[Martin Björklund]

Jürgen Schönwälder  wrote:
> I personally believe this notion of a system datastore is actually a
> bad idea. A loopback interface, for example, is system generated and
> it exists in operational but usually not in intended. I think it is
> wrong to think that a system datastore feeds into intended. After all,
> system config also comes and goes at the will of the system. I am not
> following this in detail but I fear this work likely creates more
> damage than that is solves serious real-world problems.

I strongly agree.  I didn't understand that part of the proposal.  I
guess the discussion about origin system confused me; if system feeds
into intended then the origin will be intended.


/martin



> 
> /js
> 
> On Thu, Nov 25, 2021 at 09:45:56AM +, Rob Wilton (rwilton) wrote:
> > Hi Martin,
> > 
> > I think that the proposal is that  should feed into  
> > rather than directly into .  The reasoning for this is to 
> > allow configuration to depend on system defined configuration during 
> > validation without requiring that configuration to be copied into 
> > .  Clients would still be allowed to explicitly express the system 
> > configuration is running as well - e.g., if they wanted a full 
> > configuration that they can validate off box.
> >  
> > In your example below, I would probably mark the origin of the lo 
> > interface, the name leaf, and description leaf as "intended", but the type 
> > is "system".  I think that this would be similar to how I would expect a 
> > default value to be reported.  I.e., if the running config explicitly sets 
> > a leaf to its default value, I think that it is more informative to report 
> > that as origin "intended" rather than "origin" default.  But I don't think 
> > that RFC 8342 proscribes what is be used in these cases.
> > 
> > Regards,
> > Rob
> > 
> > // As a contributor
> > 
> > 
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin Björklund
> > > Sent: 24 November 2021 10:44
> > > To: j.schoenwael...@jacobs-university.de
> > > Cc: maqiufang1=40huawei@dmarc.ietf.org; netmod@ietf.org
> > > Subject: Re: [netmod] Should the origin="system" be required for system
> > > configurations copied/pasted into ?
> > > 
> > > Jürgen Schönwälder  wrote:
> > > > On Wed, Nov 24, 2021 at 03:21:14AM +, maqiufang (A) wrote:
> > > > >
> > > > > But suppose the node is a list entry (e.g., an interface) or a leaf 
> > > > > with the
> > > same value.  In this case, it is not clear which origin should be used.  
> > > I think it
> > > would be ok to use "system" in this case.
> > > >
> > > > For me,  is explicit config and hence it has precedence. The
> > > > precedence must be a function of how the datastores related, it should
> > > > not depend on which values a config leaf has.
> > > 
> > > Here's a simple example.
> > > 
> > > Suppose  has:
> > > 
> > >
> > >  lo
> > >  loopback
> > >  added by system
> > >
> > > 
> > > and  has:
> > > 
> > >
> > >  lo
> > >  set by a client
> > >
> > > 
> > > Now we follow the picture in RFC 8342:
> > > 
> > >   ++
> > >   |  | // subject to validation
> > >   | (ct, ro)   |
> > >   ++
> > > |// changes applied, subject to
> > > |// local factors, e.g., missing
> > > |// resources, delays
> > > |
> > >dynamic  |   + learned configuration
> > >configuration|   + system configuration
> > >datastores -+|   + default configuration
> > >||   |
> > >vv   v
> > > +---+
> > > |  | <-- system state
> > > | (ct + cf, ro) |
> > > +---+
> > > 
> > > 
> > > So now we merge intended and system into operational state.  First we
> > > add system to get:
> > > 
> > >   
> > > lo
> > > loopback
> > > added by system
> > >   
> > > 
> > > and then we add intended to arrive at:
> > > 
> > >   
> > > lo
> > > loopback
> > > set by a client
> > >   
> > > 
> > > 
> > > Doesn't this make sense?
> > > 
> > > 
> > > 
> > > /martin
> > > 
> > > ___
> > > 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 <https://www.jacobs-university.de/>

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

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

[Martin Björklund]

Jürgen Schönwälder  wrote:
> On Wed, Nov 24, 2021 at 03:21:14AM +, maqiufang (A) wrote:
> > 
> > But suppose the node is a list entry (e.g., an interface) or a leaf with 
> > the same value.  In this case, it is not clear which origin should be used. 
> >  I think it would be ok to use "system" in this case.
> 
> For me,  is explicit config and hence it has precedence. The
> precedence must be a function of how the datastores related, it should
> not depend on which values a config leaf has.

Here's a simple example.

Suppose  has:

   
 lo
 loopback
 added by system
   

and  has:

   
 lo
 set by a client
   

Now we follow the picture in RFC 8342:

  ++
  |  | // subject to validation
  | (ct, ro)   |
  ++
|// changes applied, subject to
|// local factors, e.g., missing
|// resources, delays
|
   dynamic  |   + learned configuration
   configuration|   + system configuration
   datastores -+|   + default configuration
   ||   |
   vv   v
+---+
|  | <-- system state
| (ct + cf, ro) |
+---+


So now we merge intended and system into operational state.  First we
add system to get:

  
lo
loopback
added by system
  

and then we add intended to arrive at:

  
lo
loopback
set by a client
  


Doesn't this make sense?



/martin

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

Re: [netmod] Should the origin="system" be required for system configurations copied/pasted into ?

[Martin Björklund]

Hi,

"maqiufang \(A\)"  wrote:
> Hi, all
> 
> There is still another issue which is about origin metadata
> annotation: should the origin="system" be required for system
> configurations copied/pasted into ?

I think the question is "if a node is present both in  and
in , which origin does it have in "?

(NOTE: it doesn't matter if the value was "copy & pasted" from
 or entered in some other way.)

Obviously, if a leaf node is present in both, but its value differ,
the origin must indicate which datastore had precedence.

But suppose the node is a list entry (e.g., an interface) or a leaf
with the same value.  In this case, it is not clear which origin
should be used.  I think it would be ok to use "system" in this case.
(But also perhaps it doesn't matter much).


> Currently any system configuration explicitly declared in  in
> order to configure its descendant nodes or maintain 
> offline-valid will show up in  with origin=intended.
> The question behind this issue is whether we want a copied/pasted
> system defined data node to override and take precedence over
> .
> 
> The choices and some considerations of this issue received so far:
> o Origin=system IS required for system configuration copied/pasted
> into 
> ?  I believe that "system" reflects the most accurate source in this
> case. And only in this way, a server can allow a read-only system
> configuration to be declared in (e.g., in order to valid
> ) by the clients.

What do you mean with "a read-only system configuration [...] be
declared in "?   is a separate datastore that clients
can read, right?



/martin



> ?  The challenge for this choice is on the server side. It MUST be
> able to recognize a particular data node which explicitly defined in
>  is actually a mirror of what is in .
> o Origin=system is NOT required for system configuration copied/pasted
> into 
> ?  Good consistency. For all configurations explicitly defined in
> , if they appear in , the origin value is
> "intended" with no exceptions.
> o Define a system-mode which is similar to with-defaults basic mode
> and allow a server to advertise a particular behavior
> ?  Does it mean we could get the Pros from both choices?
> Any other thoughts?

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

Re: [netmod] Module updating rules - removing base statements from an "identityref" type

[Martin Björklund]

Jernej Tuljak  wrote:
> 
> 
> On 30/09/2021 10:48, Martin Björklund wrote:
> > Hi,
> >
> > Jernej Tuljak  wrote:
> >> Hi,
> >>
> >> can someone clarify the meaning of the following bullet in Section 11,
> >> RFC7950:
> >>
> >> o  A "base" statement may be removed from an "identityref" type,
> >>provided there is at least one "base" statement left.
> >>
> >> This seems to enable the value space of a definition to narrow across
> >> revisions of the same module.
> > "base" statements are ANDed, so removing one expands the value space.
> >
> > 9.10.2 says:
> >
> > Valid values for an identityref are any identities derived from all
> > the identityref's base identities.
> >
> 
> Oh, my. That is not how I understood "identityref"s with multiple
> bases worked at all.

If you want OR-semantics you can use a union.


/martin


> 
> Jernej
> 
> > /martin
> >
> >
> >> Most other changes in this section seem
> >> to only allow expansion of the value space, relaxing of constraints,
> >> etc. What kind of revisions does this bullet cover?
> >>
> >> Jernej
> >>
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Module updating rules - removing base statements from an "identityref" type

[Martin Björklund]

Hi,

Jernej Tuljak  wrote:
> Hi,
> 
> can someone clarify the meaning of the following bullet in Section 11,
> RFC7950:
> 
>o  A "base" statement may be removed from an "identityref" type,
>   provided there is at least one "base" statement left.
> 
> This seems to enable the value space of a definition to narrow across
> revisions of the same module.

"base" statements are ANDed, so removing one expands the value space.

9.10.2 says:

   Valid values for an identityref are any identities derived from all
   the identityref's base identities. 


/martin


> Most other changes in this section seem
> to only allow expansion of the value space, relaxing of constraints,
> etc. What kind of revisions does this bullet cover?
> 
> Jernej
> 

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

Re: [netmod] [babel] NULL value for uint16

[Martin Björklund]

Mahesh Jethanandani  wrote:
> Hi Juergen,
> 
> > On Sep 14, 2021, at 10:17 AM, Jürgen Schönwälder 
> >  wrote:
> > 
> > On Tue, Sep 14, 2021 at 01:51:36PM +, STARK, BARBARA H wrote:
> > 
> >> As I mentioned, BBF TR-181 uses int with range -1:65535 with -1 
> >> meaning NULL. So I certainly have no issue with that approach. The 
> >> language in RFC9046 was intended to make sure this approach was allowed, 
> >> since this is how it's done in TR-181.
> >> I guess I am a bit surprised to learn that YANG doesn't seem to have a 
> >> preferred way to handle this. Unfortunately, given my considerable lack of 
> >> YANG expertise, I can't recommend the "right" way to model this in YANG. I 
> >> can only insist that the model be able to express a value in the range 0 
> >> to 2^16 and NULL value for these parameters. 
> >> Independent of the fact that the words in RFC9046 don't seem to have 
> >> expressed this perfectly clearly, that is absolutely the intent of those 
> >> words. I apologize that the RFC9046 words don't seem to be sufficiently 
> >> clear. 
> >> 
> >> Since you do mention the possibility of using -1 for NULL, I'd like to 
> >> understand who might find this approach unacceptable? The language in the 
> >> information model was definitely intended to express the acceptability of 
> >> using this approach from a Babel WG perspective (because I knew that's how 
> >> it would be done in TR-181). Would this be unacceptable to people with 
> >> YANG expertise? I think my preference would be to use this approach, since 
> >> it would provide additional consistency between the TR-181 and YANG models.
> > 
> > If other data models use an extended integer range and -1 to indicate
> > a special case, then this may be a strong reason to do the same in the
> > IETF YANG data model. Consistency across data models is a value, in
> > particular for systems that may have to support multiple. While the
> > conversion of different notations no hard, its one more thing to
> > potentially get wrong.
> > 
> > If you were starting with a blank sheet of paper, then the YANG idiom
> > would likely be to use a union of a 16-bit integer and a special
> > (string) value, which might even be of type empty.
> 
> I hear two suggestions on what the “other” construct should be in the union 
> statement. Use ‘empty’ as you suggest, or use ‘boolean’. Are there any 
> pros/cons for either of the approaches?

'boolean' doesn't seem right, since that would mean that you could see
the values 'true' | 'false' | .

If you want a union I suggest a union with one enum, perhaps:

  type union {
type enumeration {
  enum null;
}
type uint16;
  }

But Jürgens point about using a solution that other data models use
makes sense.

Yet another alternative could be to not instantiate this leaf when the
value in the information model is null.



/martin





> 
> > 
> > One of the reasons to have no common approach to these kind of
> > questions is to provide the flexibility needed to do the right thing
> > in different contexts. Of course, you may want to stay consistent in a
> > data model or a collection of related data model.
> > 
> > I skimmed RFC 8407 and it seems we do not have text discussion this
> > specific situation. Perhaps we should have text, perhaps I have
> > overlooked it. ;-) I think there are different patterns to choose from
> > to handle this situation with their various pros and cons.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Björklund]

This is clearly a typo.  The errata should be verified.


/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/eid6655
> 
> --
> Type: Editorial
> Reported by: Viktor Leijon 
> 
> Section: 10.6.1.1
> 
> Original Text
> -
>leaf flags {
>type bits {
>  bit UP;
>  bit PROMISCUOUS
>  bit DISABLED;
>}
>   }
> 
> Corrected Text
> --
>leaf flags {
>type bits {
>  bit UP;
>  bit PROMISCUOUS;
>  bit DISABLED;
>}
>   }
> 
> Notes
> -
> The missing semicolon makes the YANG snippet invalid.
> 
> 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

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

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

[Martin Björklund]

Hi,

This errata is correct and should be verified.


/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/eid6570
> 
> --
> Type: Technical
> Reported by: Jernej Tuljak 
> 
> Section: 11
> 
> Original Text
> -
>o  New typedefs, groupings, rpcs, notifications, extensions,
>   features, and identities may be added.
> 
> Corrected Text
> --
>o  New typedefs, groupings, rpcs, actions, notifications,
>   extensions, features, and identities may be added.
> 
> Notes
> -
> The original text unintentionally fails to mention actions. A definition in a 
> published module may be revised by adding actions to this definition.
> 
> 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

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

Re: [netmod] Module updating rules (adding actions)

[Martin Björklund]

Jernej Tuljak  wrote:
> Hi,
> 
> while re-reading RFC7950, Section 11, I noticed that adding an
> "action" to an existing "container" or "list" does not appear to be
> among the permitted changes while updating a module to a newer
> revision.
> 
> Seems like an unintentional omission in text?

Yes!

FWIW, pyang --check-update allows adding actions.


/martin


> 
> OLD:
> 
>    o  New typedefs, groupings, rpcs, notifications, extensions,
>   features, and identities may be added.
> 
> NEW:
> 
>    o  New typedefs, groupings, rpcs, actions, notifications,
>   extensions, features, and identities may be added.
> 
> 
> Jernej
> 
> ___
> 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] review of state NBC rules in yang-module-versioning-02

[Martin Björklund]

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi guys,
> 
> Let's take this model for a leaf (line numbers for reference):
> 
> 10 leaf foo {
> 20  type uint8 {
> 30range "5..101";
> 40  }
> 50 }
> 
> When I've been talking about "type" I've only been talking about
> line 20.  The base type of the leaf.
> 
> But are you guys considering that the term "type" includes 20 and 30
> ?

Yes; the definition in RFC 7950 is:

   o  value space: For a data type; the set of values permitted by the
  data type.  For a leaf or leaf-list instance; the value space of
  its data type.

So line 20 and 30 together defines the set of values permitted byu
this type.

> I'm not sure that RFC7950 is terribly clear when it mentions "data
> type" below. Isn't that a bit ambiguous as to whether it includes
> line 30 or not?
> 
> In the example above I think the value space is 5..101. Is that correct?

Yes.

> But what about a description like this ?
> 
> 10 leaf bar {
> 20  type uint8 {
> 30range "5..101";
> 40  }
> 50  description "actually only takes values 5..88 in all current 
> supported implementations";
> 60 }
> 
> That description isn't a substatement of the "type" statement. Is
> the value space 5..101 or 5..88 ?

Perhaps a better example is inet:uri from RFC 6991, which is defined
as:

 typedef uri {
   type string;
   description
"The uri type represents a Uniform Resource Identifier
 (URI) as defined by STD 66.

 Objects using the uri type MUST be in US-ASCII encoding,
 and MUST be normalized as described by RFC 3986 Sections
 6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
 percent-encoding is removed, and all case-insensitive
 characters are set to lowercase except for hexadecimal
 digits, which are normalized to uppercase as described in
 Section 6.2.2.1.

 The purpose of this normalization is to help provide
 unique URIs.  Note that this normalization is not
 sufficient to provide uniqueness.  Two URIs that are
 textually distinct after this normalization may still be
 equivalent.

 Objects using the uri type may restrict the schemes that
 they permit.  For example, 'data:' and 'urn:' schemes
 might not be appropriate.

 A zero-length URI is not a valid URI.  This can be used to
 express 'URI absent' where required.

 In the value set and its semantics, this type is equivalent
 to the Uri SMIv2 textual convention defined in RFC 5017.";
   reference
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
   Group: Uniform Resource Identifiers (URIs), URLs,
   and Uniform Resource Names (URNs): Clarifications
   and Recommendations
 RFC 5017: MIB Textual Conventions for Uniform Resource
   Identifiers (URIs)";
 }

The value space is all legal URIs, even though there is no pattern
defined.  An implementation may hook up a standard uri parser to
objects of this type.

Are we discussing a real problem here?



/martin


> 
> Jason
> 
> > -Original Message-
> > From: tom petch 
> > Sent: Tuesday, March 30, 2021 11:51 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin
> > Björklund ; j.schoenwael...@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-
> > 02
> > 
> > From: netmod  on behalf of Sterne, Jason
> > (Nokia - CA/Ottawa) 
> > Sent: 30 March 2021 13:13
> > Subject: Re: [netmod] review of state NBC rules in yang-module-versioning-
> > 02
> > 
> > Hi guys,
> > 
> > The text in 7950 doesn't mention anything about semantics in the
> > description. That is part of what made me feel it isn't accurate or 
> > complete.
> > 
> > It also doesn't mention constraints like range or pattern. It only mentions 
> > the
> > type.
> > 
> > 
> > I am with Martin and Juergen on this one.  You pick on two of the ten
> > substatements for type but all are part of the definition of a type and are
> > relevant in defining the value space; and elsewhere in the RFC, e.g.
> > decimal64, there are explicit descriptions of the value space.  Whereas if 
> > you
> > take, say, uint32 what more do you need to say to describe the value space?
> > 
> > Tom Petch
> > 
> > Jason
> > 
> 

Re: [netmod] review of state NBC rules in yang-module-versioning-02

[Martin Björklund]

Juergen Schoenwaelder  wrote:
> On Tue, Mar 30, 2021 at 01:55:18AM +, Sterne, Jason (Nokia - CA/Ottawa) 
> wrote:
> > Hi all,
> > 
> > I took a look at section "3.1.2 Backwards-compatibility rules for config 
> > false and output data" of 
> > https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02.
> > 
> > Here are some suggestions (mostly just editorial - I agree with the general 
> > spirit of what's in here).
> > 
> > (A) Valuespace
> > 
> > Valuespace is defined in module versioning 02:
> >o  Valuespace: The valuespace of a leaf or leaf-list is the set of
> >   values that the schema node may have according to the type and
> >   constraint statements of the YANG model.
> > 
> > It seems to be a more complete definition than "value space" in RFC7950 
> > (which doesn't seem to take into account "range", "pattern", etc 
> > statements):
> > 
> >o  value space: For a data type; the set of values permitted by the
> > 
> >   data type.  For a leaf or leaf-list instance; the value space of
> > 
> >   its data type.
> > 
> > Should we mention that this definition replaces/supercedes that of 7950 (at 
> > least for the scope of the module versioning doc) ?
> 
> Please no. RFC 7950 says data type and for me this includes everything
> that defines a type, including the semantics carried in the type's
> description statement.
> 
> We do not need to fix what is not broken. Why do we need a new
> definition at all?  If definitions in RFC 7950 are broken, then we
> need to fix it in YANG next.

+1.  I don't think the text in RFC 7950 is broken.  It is better if
the new document refers to the defintion in RFC 7950, rather than
providing its own defintion with new words.


/martin



>  
> /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] type equivalence

[Martin Björklund]

"Rob Wilton \(rwilton\)"  wrote:
> Sorry, but I wish to raise another question regarding changing types.
> 
> Are you allowed to change from one type to another type that
> 'contains' the first type.
> 
> typedef smallInt {
>   type int8 { range "0..100"; };
> }
> 
> typedef biggerInt {
>   type int8 { range "0..200"; };
> }
> 
> Can I change leaf foo from:
> 
> leaf foo {
>   type smallInt;
> }
> 
> to:
> 
> leaf foo {
>   type biggerInt;
> }

Yes, this was clearly the intention.

We have these two rules:

   o  A "range", "length", or "pattern" statement may expand the allowed
  value space.

   o  A "type" statement may be replaced with another "type" statement
  that does not change the syntax or semantics of the type.  For
  example, an inline type definition may be replaced with a typedef,
  but an int8 type cannot be replaced by an int16, since the syntax
  would change.

But I assume you mean that the second bullet doesn't allow an expanded
value space?


/martin



> 
> I'm not sure that the chapter 11 rules in RFC 7950 formally allow this 
> (either with or without the proposed errata), but intuitively I would 
> expected this to be allowed by commutativity, since this change is clearly 
> legal if you go via a third intermediate type.
> 
> E.g., you could change leaf foo from using smallInt to a new tempInt:
> 
> typedef tempInt {
>   type int8 { range "0..100"; };
> }
> 
> Then, as a second update, change the range in tempInt:
> 
> typedef tempInt {
>   type int8 { range "0..200"; };
> }
> 
> And in the final step change leaf foo from using tempInt to use biggerInt.
> 
> Rob
> 
> 
> > -Original Message-
> > From: Rob Wilton (rwilton)
> > Sent: 26 February 2021 19:06
> > To: Juergen Schoenwaelder 
> > Cc: NetMod WG 
> > Subject: RE: [netmod] type equivalence
> > 
> > 
> > 
> > > -Original Message-
> > > From: Juergen Schoenwaelder 
> > > Sent: 26 February 2021 17:55
> > > To: Rob Wilton (rwilton) 
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] type equivalence
> > >
> > > On Fri, Feb 26, 2021 at 03:27:39PM +, Rob Wilton (rwilton) wrote:
> > > >
> > > > Sure, but if we are going to submit an errata for this definition, we
> > > want to ensure that updated definition is clear in all axes, not only
> > the
> > > specific issue that was originally raised.
> > > >
> > >
> > > This is where the IETF shines, there is an attempt to fix a minor
> > > problem and the result is N additional possible problems are put on
> > > the table to be considered as well before the minor problem can be
> > > fixed. My interest was the original question since I did run into it,
> > > my interest is low in fixing all other possible problems that people
> > > can think of.
> > [RW]
> > 
> > I'm not convinced that accurately describes the situation.
> > 
> > If it helps to clarify, I have three specific goals here:
> > 
> > (1) Check that the proposed corrected text doesn't contain further bugs
> > that also need to be fixed.  After all you cannot file an errata on an
> > errata, and it doesn't look great for me if I have to request that a
> > verified errata is changed to rejected because it contains further issues
> > in a two sentence paragraph.
> > 
> > (2) Workout whether the errata can be marked as verified, hold for update,
> > or needs to be rejected.
> > 
> > (3) Check that the same bug doesn't exist in other places.  I agree that
> > this is a tangential goal, and I have already forked this into a separate
> > thread, as you had requested.
> > 
> > I am not asking you to generically fix or define "semantics", but I really
> > would like our proposed replacement text to be entirely unambiguous, and
> > contain no further issues.
> > 
> > E.g., I'm wondering, would your proposed new definition allow us to change
> > from the IETF to IEEE MAC address definition?  The underlying type is the
> > same (String), and arguably the semantics of both types is the same (i.e.,
> > they both represent an IEEE 802 MAC address), but the syntax of the two
> > types clearly differs.
> > 
> > Regards,
> > Rob
> 
> ___
> 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] type equivalence

[Martin Björklund]

"Rob Wilton (rwilton)"  wrote:
> 
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: 26 February 2021 16:30
> > To: a...@yumaworks.com
> > Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
> > 
> > Andy Bierman  wrote:
> > > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund 
> > wrote:
> > >
> > > > "Rob Wilton \(rwilton\)"  wrote:
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: netmod  On Behalf Of Juergen
> > > > Schoenwaelder
> > > > > > Sent: 24 February 2021 20:39
> > > > > > To: netmod@ietf.org
> > > > > > Subject: Re: [netmod] type equivalence
> > > > > >
> > > > > > Here is an attempt to come up with better wording. If people agree
> > on
> > > > > > a new wording, I volunteer to submit an errata.
> > > > > >
> > > > > > OLD
> > > > > >
> > > > > >o  A "type" statement may be replaced with another "type"
> > statement
> > > > > >   that does not change the syntax or semantics of the type.
> > For
> > > > > >   example, an inline type definition may be replaced with a
> > > > typedef,
> > > > > >   but an int8 type cannot be replaced by an int16, since the
> > syntax
> > > > > >   would change.
> > > > > >
> > > > > > NEW
> > > > > >
> > > > > >o  A "type" statement may be replaced with another "type"
> > statement
> > > > > >   that does not change the semantics of the type or the
> > underlying
> > > > > >   built-in type.  For example, an inline type definition may
> > be
> > > > > >   replaced with a semantically equivalent typedef derived from
> > the
> > > > > >   same built-in type, but an int8 type cannot be replaced by
> > an
> > > > > >   int16, since the underlying built-in type would change.
> > > >
> > >
> > >
> > > I think the NEW text captures the original intent and is OK for an
> > errata.
> > 
> > +1
> > 
> > 
> > > I believe the use-case discussed at the time of writing was simply
> > > replacing an inline
> > > type with the identical type but within a typedef-stmt instead of
> > > inline
> > > within a leaf or leaf-list.
> > >
> > > Perhaps this rule is too strict.
> > > There is a simple way to defeat it:
> > >
> > > Change all
> > >type foo {  ... }
> > > to
> > >type union {
> > >   type foo { ... }
> > > }
> > >
> > > Now you can add new values and semantics without taking away the
> > original
> > > syntax and semantics.
> > >
> > >  type union {
> > >   type foo { ... }
> > >   type bar { ... }   // note new member types added at end of list
> > > }
> > >
> > > But it is not clear that this would be legal or completely BC. It
> > certainly
> > > could change the encoding in JSON and CBOR.
> > 
> > It is not allowed by sec 11 in 7950, since it changes the syntax of
> > the type.
> [RW] 
> 
> But the proposed errata removes the text about not changing the
> syntax, or are you referring to other text?

The new text says that the built-in type cannot change, which it does
if we add a type to a union.  Hmm, perhaps this isn't clear.


/martin


> 
> Rob
> 
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > >
> > >
> > > Andy
> > >
> > >
> > > > [RW]
> > > > >
> > > > > Would the text be more clear it is just specified what is allowed,
> > e.g.,
> > > > >
> > > > >  o  A "type" statement may be replaced with another "type"
> > statement
> > > > > that resolves to the same underlying built-in type.  For
> > example,
> > > > > ...
> > > > >
> > > > >
> > > > > What does "semantics of the type" cover?
> > > >
> > > > Suppose you have:
> > > >
> > > &

Re: [netmod] type equivalence

[Martin Björklund]

Andy Bierman  wrote:
> On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund  wrote:
> 
> > "Rob Wilton \(rwilton\)"  wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: netmod  On Behalf Of Juergen
> > Schoenwaelder
> > > > Sent: 24 February 2021 20:39
> > > > To: netmod@ietf.org
> > > > Subject: Re: [netmod] type equivalence
> > > >
> > > > Here is an attempt to come up with better wording. If people agree on
> > > > a new wording, I volunteer to submit an errata.
> > > >
> > > > OLD
> > > >
> > > >o  A "type" statement may be replaced with another "type" statement
> > > >   that does not change the syntax or semantics of the type.  For
> > > >   example, an inline type definition may be replaced with a
> > typedef,
> > > >   but an int8 type cannot be replaced by an int16, since the syntax
> > > >   would change.
> > > >
> > > > NEW
> > > >
> > > >o  A "type" statement may be replaced with another "type" statement
> > > >   that does not change the semantics of the type or the underlying
> > > >   built-in type.  For example, an inline type definition may be
> > > >   replaced with a semantically equivalent typedef derived from the
> > > >   same built-in type, but an int8 type cannot be replaced by an
> > > >   int16, since the underlying built-in type would change.
> >
> 
> 
> I think the NEW text captures the original intent and is OK for an errata.

+1


> I believe the use-case discussed at the time of writing was simply
> replacing an inline
> type with the identical type but within a typedef-stmt instead of inline
> within a leaf or leaf-list.
> 
> Perhaps this rule is too strict.
> There is a simple way to defeat it:
> 
> Change all
>type foo {  ... }
> to
>type union {
>   type foo { ... }
> }
> 
> Now you can add new values and semantics without taking away the original
> syntax and semantics.
> 
>  type union {
>   type foo { ... }
>   type bar { ... }   // note new member types added at end of list
> }
> 
> But it is not clear that this would be legal or completely BC. It certainly
> could change the encoding in JSON and CBOR.

It is not allowed by sec 11 in 7950, since it changes the syntax of
the type.


/martin



> 
> 
> Andy
> 
> 
> > [RW]
> > >
> > > Would the text be more clear it is just specified what is allowed, e.g.,
> > >
> > >  o  A "type" statement may be replaced with another "type" statement
> > > that resolves to the same underlying built-in type.  For example,
> > > ...
> > >
> > >
> > > What does "semantics of the type" cover?
> >
> > Suppose you have:
> >
> >typedef "timestamp" {
> >  type yang:date-time;
> >  description
> >"The time that an event occurred";
> >}
> >
> > then you can't change it to:
> >
> >typedef "timestamp" {
> >  type yang:date-time;
> >  description
> >"The time that an event was received.";
> >}
> >
> > The syntax is the same, but the semantics are different.
> >
> >
> > /martin
> >
> >
> >
> >
> > >
> > > If I have this type:
> > >
> > >   typedef "timestamp" {
> > > type "string";
> > > description
> > >   "The time of day that an event occurred, in any format";
> > >   }
> > >
> > > then can I replace it with this definition:
> > >
> > >   typedef "timestamp" {
> > > type "string";
> > > description
> > >   "The time of day, and optionally date, that an event
> > >occurred, in any format";
> > >   }
> > >
> > >
> > >
> > > Tangentially, it is worth noting the RFC 8342 also writes about syntactic
> > > constraints covering types:
> > >
> > > 5.3.  The Operational State Datastore ()
> > >
> > >Syntactic constraints MUST NOT be violated, including hierarchical
> > >organization, identifiers, and type-based constraints.  If a node in
> > > does not meet the

Re: [netmod] What operational values can NMDA return?

[Martin Björklund]

"Rob Wilton \(rwilton\)"  wrote:
> 
> 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > Sent: 26 February 2021 14:28
> > To: Rob Wilton (rwilton) 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
> > 
> > On Fri, Feb 26, 2021 at 12:21:26PM +, Rob Wilton (rwilton) wrote:
> > >
> > > Tangentially, it is worth noting the RFC 8342 also writes about
> > syntactic
> > > constraints covering types:
> > >
> > > 5.3.  The Operational State Datastore ()
> > >
> > >Syntactic constraints MUST NOT be violated, including hierarchical
> > >organization, identifiers, and type-based constraints.  If a node in
> > > does not meet the syntactic constraints, then it
> > >MUST NOT be returned, and some other mechanism should be used to flag
> > >the error.
> > >
> > > I'm not sure how clear RFC 8342 section 5.3 is about returning values
> > > that can be represented by the underlying built-in-type, but are
> > > outside
> > > the value space defined by a range, length, or pattern statement.
> > >
> > > My memory during the discussions was that it is allowed to return a
> > value
> > > outside arange, length, pattern statement, as long as it is contained
> > > in the value space of the built-in-type.  E.g., cannot return 257 in a
> > > uint8, but can return 11 even if the type range is 1..10.
> > >
> > > But, I'm not sure that is what the text actually states.
> > 
> > Perhaps this requires a separate thread. Perhaps 'syntactic
> > constraints' was not a good choice and yes different people might
> > understand 'type-based constraints' differently. RFC 7950 says:
> > 
> >The following properties are true in all data trees:
> > 
> >o  All leaf data values MUST match the type constraints for the leaf,
> >   including those defined in the type's "range", "length", and
> >   "pattern" properties.
> [RW] 
> 
> But RFC 8342 also states:
> 
> SHOULD conform to any constraints specified in the data
>model, but given the principal aim of returning "in use" values, it
>is possible that constraints MAY be violated under some circumstances
>(e.g., an abnormal value is "in use", the structure of a list is
>being modified, or remnant configuration (see Section 5.3.1) still
>exists).  Note that deviations SHOULD be used when it is known in
>advance that a device does not fully conform to the 
>schema.
> 
>Only semantic constraints MAY be violated.  These are the YANG
>"when", "must", "mandatory", "unique", "min-elements", and
>"max-elements" statements; and the uniqueness of key values.
> 
>Syntactic constraints MUST NOT be violated, including hierarchical
>organization, identifiers, and type-based constraints.  If a node in
> does not meet the syntactic constraints, then it
>MUST NOT be returned, and some other mechanism should be used to flag
>the error.
> 
> The first paragraph to me suggests that it is right to return an
> abnormal value.
> 
> E.g., perhaps the IPv6 MTU is only allowed to be configured to values
> greater than 1280, but due to a bug, what actually gets programmed is
> 1000.  Should the device return the "in use" MTU value?  My
> understanding of the NMDA architecture is that it should.

No, you have to read the full text.  The 3rd paragraph makes it clear
that 1000 is not legal in this case.

(You know what Juergen says, you MUST NOT have any bugs :)

> However, the second paragraph doesn't list length, pattern, or range
> as constraints that can be violated, so perhaps it is not allowed.
> But I'm not convinced that is what was originally intended ...

I think it was.


/martin




> 
> Regards,
> Rob
> 
>   
> 
> 
> 
> > 
> > So I am not sure about returning 11 for a range 1..10.
> > 
> > /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] type equivalence

[Martin Björklund]

"Rob Wilton \(rwilton\)"  wrote:
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
> > 
> > Here is an attempt to come up with better wording. If people agree on
> > a new wording, I volunteer to submit an errata.
> > 
> > OLD
> > 
> >o  A "type" statement may be replaced with another "type" statement
> >   that does not change the syntax or semantics of the type.  For
> >   example, an inline type definition may be replaced with a typedef,
> >   but an int8 type cannot be replaced by an int16, since the syntax
> >   would change.
> > 
> > NEW
> > 
> >o  A "type" statement may be replaced with another "type" statement
> >   that does not change the semantics of the type or the underlying
> >   built-in type.  For example, an inline type definition may be
> >   replaced with a semantically equivalent typedef derived from the
> >   same built-in type, but an int8 type cannot be replaced by an
> >   int16, since the underlying built-in type would change.
> [RW] 
> 
> Would the text be more clear it is just specified what is allowed, e.g.,
> 
>  o  A "type" statement may be replaced with another "type" statement
> that resolves to the same underlying built-in type.  For example,
> ...
> 
> 
> What does "semantics of the type" cover?

Suppose you have:

   typedef "timestamp" {
 type yang:date-time;
 description
   "The time that an event occurred";
   }

then you can't change it to:

   typedef "timestamp" {
 type yang:date-time;
 description
   "The time that an event was received.";
   }

The syntax is the same, but the semantics are different.


/martin




> 
> If I have this type:
> 
>   typedef "timestamp" {
> type "string";
> description
>   "The time of day that an event occurred, in any format";
>   }
> 
> then can I replace it with this definition:
> 
>   typedef "timestamp" {
> type "string";
> description
>   "The time of day, and optionally date, that an event
>occurred, in any format";
>   }
> 
> 
> 
> Tangentially, it is worth noting the RFC 8342 also writes about syntactic
> constraints covering types:
> 
> 5.3.  The Operational State Datastore ()
> 
>Syntactic constraints MUST NOT be violated, including hierarchical
>organization, identifiers, and type-based constraints.  If a node in
> does not meet the syntactic constraints, then it
>MUST NOT be returned, and some other mechanism should be used to flag
>the error.
> 
> I'm not sure how clear RFC 8342 section 5.3 is about returning values
> that can be represented by the underlying built-in-type, but are outside
> the value space defined by a range, length, or pattern statement.
> 
> My memory during the discussions was that it is allowed to return a value
> outside arange, length, pattern statement, as long as it is contained
> in the value space of the built-in-type.  E.g., cannot return 257 in a
> uint8, but can return 11 even if the type range is 1..10.
> 
> But, I'm not sure that is what the text actually states.
> 
> Regards,
> Rob
> 
> 
> > 
> > /js
> > 
> > On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote:
> > > On 2021-02-22, at 15:17, Juergen Schoenwaelder  > university.de> wrote:
> > > >
> > > > I guess considering the built-in types as incompatible is the most
> > > > robust approach. If we agree that RFC 7950 tried to say this, we could
> > > > file an errata and propose clearer language.
> > >
> > > Right.  And we can keep the COMI key-to-URL mapping as is, as this
> > clarification is necessary for its correct functioning.
> > >
> > > Grüße, Carsten
> > >
> > 
> > --
> > 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] type equivalence

[Martin Björklund]

Juergen Schoenwaelder  wrote:
> Thanks Martin,
> 
> so you are saying that
> 
>   int8 { range "1..10"; }
> 
> is indeed different from
> 
>   uint8 { range "1..10"; }
> 
> and
> 
>   int32 { range "1..10"; }

Yes.

> The use of the word "syntax" in the text you quote may be a left-over
> from SMIv2 times

[That's what I thought as well, but I couldn't find it in the SMIv2
RFCs.  Perhaps it was from some sming text?]

> , it does not really seem to be aligned with how the
> term 'syntax' is used elsewhere in RFC 7950. Anyway, if the agreement
> back then was that you can't change base types (regardless of type
> restrictions), it would have been nice if the text would say this more
> clearly.

Agreed.


/martin



> 
> /js
> 
> On Mon, Feb 22, 2021 at 10:49:38AM +0100, Martin Björklund wrote:
> > Hi,
> > 
> > Section 11 of RFC 7950 says:
> > 
> >o  A "type" statement may be replaced with another "type" statement
> >   that does not change the syntax or semantics of the type.  For
> >   example, an inline type definition may be replaced with a typedef,
> >   but an int8 type cannot be replaced by an int16, since the syntax
> >   would change.
> > 
> > If we're just considering XML, then the syntax or encoding wouldn't
> > change if we went from
> > 
> >   type int64 { range "2..4"; }
> > 
> > to
> > 
> >   type string { pattern "2|3|4"; }
> > 
> > or
> > 
> >   type enumeration {
> > enum 2;
> > enum 3;
> > enum 4;
> >   }
> > 
> > or
> > 
> >   type union {
> > type uint8 { range "2"; }
> > type string { pattern "3"; }
> > type enumeration { enum 4; }
> >   }
> > 
> > 
> > But I don't think this is reasonable, and not the intention.  I think
> > that changing the base built-in type always should be considered
> > non-backwards compatible (which the quoted text above seems to imply).
> > 
> > 
> > /martin
> > 
> > 
> > 
> > 
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
> > > > 
> > > > 
> > > > > On 2021-02-19, at 19:18, Juergen Schoenwaelder 
> > > > >  wrote:
> > > > > 
> > > > > I think the CBOR encoding picks different tags depending on the
> > > > > signedness of the base type and this is why things are not that simple
> > > > > anymore.
> > > > 
> > > > (This is not the CBOR encoding, but the COMI encoding of keys in URIs.)
> > > 
> > > OK. The CBOR document indeed says:
> > > 
> > > 6.1.  The unsigned integer Types
> > > 
> > >Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
> > >a CBOR unsigned integer data item (major type 0).
> > > 
> > > 6.2.  The integer Types
> > > 
> > >Leafs of type int8, int16, int32 and int64 MUST be encoded using
> > >either CBOR unsigned integer (major type 0) or CBOR negative integer
> > >(major type 1), depending on the actual value.
> > > 
> > > This means the type 'int8 { range 0..10; }' leads to the same
> > > encodings as the type 'uint8 { range 0..10; }'.
> > > 
> > > > > For the XML and JSON encodings, all definitions lead to the
> > > > > same on-the-wire representation, hence the difference is more an
> > > > > implementation detail. I have no clue what the gnmi people do. The
> > > > > more diverse encodings we add, the more complex things get.
> > > > 
> > > > Well, if the equivalence expectation that I was trying to describe 
> > > > actually is ingrained, then whoever designs an encoding (COMI for its 
> > > > URI encoding included) needs to respect it.  That would be important to 
> > > > know.
> > > > 
> > > 
> > > Exactly. I think we never defined this. And of course, this can get
> > > even more fun if you consider string based encodings. The type
> > > 
> > >type string { pattern "1|2|3|4"; }
> > > 
> > > yields the same _XML encoded_ value space as
> > > 
> > >type int32 { range "1..4"; }
> > > 
> > > but as far as I recall the JSON/CBOR encodings will treat these two
> > > differently. So yes, ideally the YANG language would have clear rules
> > > what YANG's type equivalences are.
> > > 
> > > /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
> 
> -- 
> 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] type equivalence

[Martin Björklund]

Hi,

Section 11 of RFC 7950 says:

   o  A "type" statement may be replaced with another "type" statement
  that does not change the syntax or semantics of the type.  For
  example, an inline type definition may be replaced with a typedef,
  but an int8 type cannot be replaced by an int16, since the syntax
  would change.

If we're just considering XML, then the syntax or encoding wouldn't
change if we went from

  type int64 { range "2..4"; }

to

  type string { pattern "2|3|4"; }

or

  type enumeration {
enum 2;
enum 3;
enum 4;
  }

or

  type union {
type uint8 { range "2"; }
type string { pattern "3"; }
type enumeration { enum 4; }
  }


But I don't think this is reasonable, and not the intention.  I think
that changing the base built-in type always should be considered
non-backwards compatible (which the quoted text above seems to imply).


/martin




Juergen Schoenwaelder  wrote:
> On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
> > 
> > 
> > > On 2021-02-19, at 19:18, Juergen Schoenwaelder 
> > >  wrote:
> > > 
> > > I think the CBOR encoding picks different tags depending on the
> > > signedness of the base type and this is why things are not that simple
> > > anymore.
> > 
> > (This is not the CBOR encoding, but the COMI encoding of keys in URIs.)
> 
> OK. The CBOR document indeed says:
> 
> 6.1.  The unsigned integer Types
> 
>Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
>a CBOR unsigned integer data item (major type 0).
> 
> 6.2.  The integer Types
> 
>Leafs of type int8, int16, int32 and int64 MUST be encoded using
>either CBOR unsigned integer (major type 0) or CBOR negative integer
>(major type 1), depending on the actual value.
> 
> This means the type 'int8 { range 0..10; }' leads to the same
> encodings as the type 'uint8 { range 0..10; }'.
> 
> > > For the XML and JSON encodings, all definitions lead to the
> > > same on-the-wire representation, hence the difference is more an
> > > implementation detail. I have no clue what the gnmi people do. The
> > > more diverse encodings we add, the more complex things get.
> > 
> > Well, if the equivalence expectation that I was trying to describe actually 
> > is ingrained, then whoever designs an encoding (COMI for its URI encoding 
> > included) needs to respect it.  That would be important to know.
> > 
> 
> Exactly. I think we never defined this. And of course, this can get
> even more fun if you consider string based encodings. The type
> 
>type string { pattern "1|2|3|4"; }
> 
> yields the same _XML encoded_ value space as
> 
>type int32 { range "1..4"; }
> 
> but as far as I recall the JSON/CBOR encodings will treat these two
> differently. So yes, ideally the YANG language would have clear rules
> what YANG's type equivalences are.
> 
> /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] Clarification on deviating type resolve scope?

[Martin Björklund]

Hi Peter,

[Kul att se dig här!]

"Peter Lundell \(plundell\)"  wrote:
> Hi all.
> 
> I'm working with an issue involving a deviate replace type and the problem is
> where the type should be resolved.
> 
> The scope in which the deviated property is resolved in is not explicitly
> stated in RFC 7950 (7.20.3.2). This would have impact when replacing the type,
> both when it's prefixed and when it's not.
> It does seem logical, and also in line with the rest of the RFC, to evaluate 
> the
> replaced property in deviating module scope and not target module scope.

Section 5.1 says:

   Statements in the module or submodule can
   reference definitions in the external module using the prefix
   specified in the "import" statement.

   [...]

   When a definition in an external module is referenced, a locally
   defined prefix MUST be used, followed by a colon (":") and then the
   external identifier.  References to definitions in the local module
   MAY use the prefix notation.

This is a general rule, and it is not repeated in every place where
it applies.  So it applies to this case as well.



/martin



> Can deviating module scope be assumed?
> Should the RFC be clarified and the scope explicitly stated?
> 
> BR
> /Peter Lundell
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Structuring a DHCP module

[Martin Björklund]

tom petch  wrote:
> From: Ladislav Lhotka 
> Sent: 21 January 2021 12:58
> 
> Hi,
> 
> in my YD review 4.5 years ago I actually recommended to use separate
> modules:
> 
> https://mailarchive.ietf.org/arch/msg/yang-doctors/GXHkGqZeIidMzpziZmK_ICrKPs4/
> 
> I think it is a matter of how much the different part overlap. For an
> implementer, it seems to be easier to pick just the relevant parts,
> provided they are easy to locate and identify.
> 
> 
> Thank you for all the responses;  I did look at the data tracker to see if 
> there had been any reviews, thinking that a previous review would be  the 
> right place to start, and it said 'No reviews'!  Perhaps these time out.
> 
> I am not comfortable with the seven modules seeing four as better, a common 
> which is then augmented with server, relay, client, with the common 
> containing the role(s), whereas at present it is the three role modules that 
> contain the role which then drives having the three option modules so each 
> option module only imports one role module, and that is the bit I find most 
> awkward. 
> 
> How best to select the three roles?  As I said upthread, I have seen the role 
> specified with features, with augment/when based on identityref (although not 
> with the three identity defined in the three role modules), presence 
> containers and so on (I have probably seen that and more in the history of 
> this I-D:-).

Is "role" the same as "node-type"?  Each of these module define their
own copy of a leaf called "dhcpv6-node-type".  I am not sure I
understand what purpose this leaf serves.  It seems to me that it can
be removed, but perhaps I am missing something.

> 
> My instinct would be to put the three identity definitions into common with a 
> dhcpv6 container, which is then augmented by the three role modules, the YANG 
> 'when' referring to role leaf in the common.  Any better ways?  

Why do augment at all?  Why not just have a top-level container in
each module; 'dhcpv6-client', 'dhcpv6-server' etc?


/martin



> 
> Tom Petch
> 
> Lada
> 
> On 21. 01. 21 13:42, Martin Björklund wrote:
> > Hi,
> >
> > I think it is a matter of taste and perhaps future extensibility if
> > this model is done as one or more YANG modules.  It can certainly be
> > done in one module, with features for client, server and relay, but it
> > is also ok to have 3 modules for the different functions.  And once
> > you have these 3 modules, it is natural to have a "common" module,
> > leading to 4 modules.  In order to keep the number of modules down,
> > perhaps the various -options modules could be merged into the other
> > 3, probably with a feature each.
> >
> > One comment is that it might be wise to avoid having a rfc number in
> > the identifier.  What happens if/when that RFC is revised for any
> > reason?
> >
> >
> > /martin
> >
> >
> > tom petch  wrote:
> >>
> >> Inline 
> >>
> >> From: Andy Bierman 
> >> Sent: 20 January 2021 18:32
> >>
> >> On Wed, Jan 20, 2021 at 8:41 AM tom petch 
> >> mailto:ie...@btconnect.com>> wrote:
> >> Juergen, Lada, Martin, Andy
> >>
> >> I wonder if one of you, or perhaps another on this list, would be willing 
> >> to give advice on the
> >> structuring of  the YANG module for DHCP.  It has been revised and 
> >> restructured several times and, to me, is not progressing.
> >>
> >> It models three roles - client, server, relay - and a dozen optional 
> >> function which can appear in one or more roles.  A node will likely have 
> >> only one role but may have many options.
> >>
> >> There are, at present, seven modules
> >> server which defines a server identity  based on common identity inter alia
> >> relay which defines relay identity ditto
> >> client which defines client identity ditto
> >> server options which has groupings for each option for a server
> >> client options which has groupings for each option for a relay
> >> relay options which has groupings for each option for a client
> >> common which defines the common identity inter alia
> >> Since options are common across roles, some groupings are replicated in 
> >> the three options modules.  Three separate option modules were created to 
> >> avoid problems with imports as Ian explains below.  The I-D is 
> >> draft-ietf-dhc-dhcpv6-yang
> >>
> >> My take is that one module is best, using 'when' or if-feature to select, 
&

Re: [netmod] Structuring a DHCP module

[Martin Björklund]

Hi,

I think it is a matter of taste and perhaps future extensibility if
this model is done as one or more YANG modules.  It can certainly be
done in one module, with features for client, server and relay, but it
is also ok to have 3 modules for the different functions.  And once
you have these 3 modules, it is natural to have a "common" module,
leading to 4 modules.  In order to keep the number of modules down,
perhaps the various -options modules could be merged into the other
3, probably with a feature each.

One comment is that it might be wise to avoid having a rfc number in
the identifier.  What happens if/when that RFC is revised for any
reason?


/martin


tom petch  wrote:
> 
> Inline 
> 
> From: Andy Bierman 
> Sent: 20 January 2021 18:32
> 
> On Wed, Jan 20, 2021 at 8:41 AM tom petch 
> mailto:ie...@btconnect.com>> wrote:
> Juergen, Lada, Martin, Andy
> 
> I wonder if one of you, or perhaps another on this list, would be willing to 
> give advice on the
> structuring of  the YANG module for DHCP.  It has been revised and 
> restructured several times and, to me, is not progressing.
> 
> It models three roles - client, server, relay - and a dozen optional function 
> which can appear in one or more roles.  A node will likely have only one role 
> but may have many options.
> 
> There are, at present, seven modules
> server which defines a server identity  based on common identity inter alia
> relay which defines relay identity ditto
> client which defines client identity ditto
> server options which has groupings for each option for a server
> client options which has groupings for each option for a relay
> relay options which has groupings for each option for a client
> common which defines the common identity inter alia
> Since options are common across roles, some groupings are replicated in the 
> three options modules.  Three separate option modules were created to avoid 
> problems with imports as Ian explains below.  The I-D is 
> draft-ietf-dhc-dhcpv6-yang
> 
> My take is that one module is best, using 'when' or if-feature to select, 
> which is what I see with OSPF, PCE, TCP, IGMP and almost everything else but 
> am struggling to convince others, especially  the author Ian.  [IF] in the 
> e-mail extract below
> 
> I suggested asking a YANG Doctor, NOT to look at the module but rather to 
> advise on a structure given the requirements to which Ian said that he had 
> not had much joy with YANG Doctors.  I append our most recent exchange in 
> which he responds to my query as to why there are seven modules; formatting 
> is a bit of a mess I am afraid.  The posts are to the DHCWG mail list.
> 
> Any advice appreciated even if it is that Ian is on just the right track!
> 
> 
> Either approach is valid so multi-module vs. single module w/ features is more
> of an overall system maintenance issue.  7 modules seems like a lot for DHCP 
> but
> I have no objective criteria to back that up.
> 
> There is some confusion about the import-stmt, which leads to many YANG 
> modules.
> In compiler terms, importing a module merely makes the symbols available for 
> parsing in the current module.
> The import-stmt implies no conformance requirements whatsoever.
> Only statements that use the imported module can do that.
> (So a server module importing a module that has client groupings is not 
> actually a problem.)
> 
> 
> 
> Andy, Juergen,
> 
> Thank you for the replies.  What Ian said about the import is
> 
> > [IF] The separation of the option modules came at a later stage based on 
> > import dependencies of a single options module. When the options module 
> > imports the client/server/relay modules so it can augment the relevant 
> > module based on identity, an implementation also needs to import these 
> > modules and will declare them in it’s capabilities as available even though 
> > it doesn’t implement them. Dividing the options modules avoids the need for 
> > deviations.
> 
>  that is, the prefix for dhcpv6-server is defined in the server module,
>module ietf-dhcpv6-server {
> ...
>  prefix "dhcpv6-server";
> ...
>  identity server {
>base "dhcpv6-common:dhcpv6-node";
>description "DHCPv6 server identity.";  }
>  leaf dhcpv6-node-type {
>type identityref {
>  base "dhcpv6-common:dhcpv6-node";}
>description "Type for a DHCPv6 server."; }
> 
> and the prefix for dhcpv6-relay in the relay module etc so having a single 
> module for options which needs to augment options to the server module needs 
> to import the server module so that the dhcpv6-server prefix is defined, 
> ditto relay and client so the single module for options then imports server 
> and relay and client modules.
> 
> With three options modules, each only imports one of server, relay, client 
> but the groupings are then replicated across the three options modules.
> 
> Logical if you agree with the initial premise (which I do not!). 
> 
> The seven Y

Re: [netmod] grouping prefix Re: [Teas] Yangdoctors early review of draft-ietf-teas-yang-path-computation-11

[Martin Björklund]

Hi,


tom petch  wrote:
> Sorry about the incomplete e-mail.  Try again
> 
> From: Teas  on behalf of Martin Björklund via
> Datatracker 
> Sent: 17 December 2020 18:58
> 
> Reviewer: Martin Björklund
> Review result: Ready with Nits
> 
> 
> o  Validation
> 
>The module fails YANG validation, but that is really due to errors
>in ietf...@2020-07-12.yang.  Specifially, the leafref in the
>grouping "path-compute-info" must have prefixes in its path.
>Without prefixes, the path refers to nodes in the module that uses
>the grouping.  (same for other groupings in that module).
> 
> 
> Martin,
> 
> I am confused (which is why I will never be a YANG doctor:-(.
> 
> RFC7950 p.104 says
>   Identifiers appearing inside
>the grouping are resolved relative to the scope in which the grouping
>is defined, not where it is used.
> I recall much debate about paths and their resolution but I cannot
> find a statement that paths are resolved where they are used in
> RFC7950, nor in the many Errata.

p. 104 further says:

   Prefix mappings, type names,
   grouping names, and extension usage are evaluated in the hierarchy
   where the "grouping" statement appears.


But in this case we have a leafref path w/o prefixes.

Section 6.4.1 says:

   o  Names without a namespace prefix belong to the same namespace as
  the identifier of the current node.  Inside a grouping, that
  namespace is affected by where the grouping is used (see
  Section 7.13).

And 7.13 says:

   The effect of a "uses" reference to a grouping is that the nodes
   defined by the grouping are copied into the current schema tree and
   are then updated according to the "refine" and "augment" statements.

   The identifiers defined in the grouping are not bound to a namespace
   until the contents of the grouping are added to the schema tree via a
   "uses" statement that does not appear inside a "grouping" statement,
   at which point they are bound to the namespace of the current module.





/martin



> And while I find teas-te almost impossible to understand because of
> how it is structured, yet
> the elements in
> type leafref {
> path "/te/globals/named-path-constraints/"
>+ "named-path-constraint/name";
>   }
> 
> would all appear to be in teas-te and not imported from
> e.g. te-typesin, in which case prefix are not needed.
> 
> So while I am sure you are right, and this is a significant problem,
> yet I cannot see the chapter and verse to back it up.
> 
> In passing, this construct, in teas-yang-path-computation has a
> history of YANG difficulties.
> 
> Tom petch
> 
> 
> 
> 
> 
> 
> 
> 
> /martin
> 
> 
> 
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 
> ___
> 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] Adveritzing submodule in

[Martin Björklund]

Hi,

Ram Polisetty Subbaiah  wrote:
> Thanks Martin,
> 
> One more follow up question:
> 
> If in case both Client and Server are compatible only with Yang 1.0,
> how client/server are supposed to
> handle capabilities advertisement for submodules? By any chance is it
> a limitation in 1.0?

If the module uses include-by-revision (which it should ;-) then both
sides know which revisions of the submodules a given revision of the
module refers to.

In any case, a server that implements YANG 1 can implement YANG
library revision 2016-06-21, which includes info about the submodules.


/martin




> 
> Thanks,
> Ram
> 
> On 20/10/20, 7:34 PM, "Martin Björklund"
> mailto:mbj+i...@4668.se>> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Ram Polisetty Subbaiah
> mailto:ramas=40juniper@dmarc.ietf.org>>
> wrote:
> Hi,
> 
> As per RFC 6020:
> 
> ===
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc6020*section-5.6.4.1__;Iw!!NEt6yMaO-gk!ViE3k69OOP_eUBbCYJQj30wOp5eFP5wV5Bex288dxmJ2T--9Z1TTLAk4tCUc3Q$<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6020*section-5.6.4.1__;Iw!!NEt6yMaO-gk!ViE3k69OOP_eUBbCYJQj30wOp5eFP5wV5Bex288dxmJ2T--9Z1TTLAk4tCUc3Q$>
> Modules
> Servers indicate the names of supported modules via the 
> message.  Module namespaces are encoded as the base URI in the
> capability string, and the module name is encoded as the "module"
> parameter to the base URI.
> 
> A server MUST advertise all revisions of all modules it implements.
> 
> For example, this  message advertises one module "syslog".
> 
> 
>   
> 
> https://urldefense.com/v3/__http://example.com/syslog?module=syslog&revision=2008-04-01__;!!NEt6yMaO-gk!ViE3k69OOP_eUBbCYJQj30wOp5eFP5wV5Bex288dxmJ2T--9Z1TTLAmPyrVZPQ$<https://urldefense.com/v3/__http:/example.com/syslog?module=syslog&revision=2008-04-01__;!!NEt6yMaO-gk!ViE3k69OOP_eUBbCYJQj30wOp5eFP5wV5Bex288dxmJ2T--9Z1TTLAmPyrVZPQ$>
>   
> 
> ===
> 
> My question is, if there are some submodules, should server advertise
> the submodules also in ?
> 
> No.
> 
> Note that module advertisement is done through YANG library in YANG
> 1.1 (RFC 7950).  Submodules are present in the YANG library (RFC
> 8525).
> 
> 
> /martin
> 
> 
> If so, what is the defined format for advertising the same?
> 
> Thanks,
> Ram
> 
> 
> Juniper Business Use Only
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!ViE3k69OOP_eUBbCYJQj30wOp5eFP5wV5Bex288dxmJ2T--9Z1TTLAlL7Ma5-A$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!NEt6yMaO-gk!ViE3k69OOP_eUBbCYJQj30wOp5eFP5wV5Bex288dxmJ2T--9Z1TTLAlL7Ma5-A$>
> 
> 
> 
> Juniper Business Use Only

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

Re: [netmod] Adveritzing submodule in

[Martin Björklund]

Ram Polisetty Subbaiah  wrote:
> Hi,
> 
> As per RFC 6020:
> 
> ===
> https://tools.ietf.org/html/rfc6020#section-5.6.4.1   Modules
>Servers indicate the names of supported modules via the 
>message.  Module namespaces are encoded as the base URI in the
>capability string, and the module name is encoded as the "module"
>parameter to the base URI.
> 
>A server MUST advertise all revisions of all modules it implements.
> 
>For example, this  message advertises one module "syslog".
> 
>
>  
>http://example.com/syslog?module=syslog&revision=2008-04-01
>  
>
> ===
> 
> My question is, if there are some submodules, should server advertise
> the submodules also in ?

No.

Note that module advertisement is done through YANG library in YANG
1.1 (RFC 7950).  Submodules are present in the YANG library (RFC
8525).


/martin


> If so, what is the defined format for advertising the same?
> 
> Thanks,
> Ram
> 
> 
> Juniper Business Use Only
> ___
> 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] [Technical Errata Reported] RFC7950 (6258)

[Martin Björklund]

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:
> https://www.rfc-editor.org/errata/eid6258
> 
> --
> Type: Technical
> Reported by: Fred Gan 
> 
> Section: 5.6.5
> 
> Original Text
> -
> For example, with these modules:
> 
>  module a {
>yang-version 1.1;
>namespace "urn:example:a";
>prefix "a";
> 
>import b {
>  revision-date 2015-01-01;
>}
>import c;
> 
>revision 2015-01-01;
> 
> 
> Corrected Text
> --
> For example, with these modules:
> 
>  module a {
>yang-version 1.1;
>namespace "urn:example:a";
>prefix "a";
> 
>import b {
>  revision-date 2015-01-01;
>  prefix b;
>}
>import c {
>  prefix c;
>}
> 
>revision 2015-01-01;
> 
> 
> Notes
> -
> As is considered in 7.1.5, The mandatory "prefix" substatement
> assigns a prefix for the imported module that is scoped to the
> importing module or submodule.
> 
> So, there should be a prefix substatement in the "import b" and
> "import c" statement respectively.
> 
> 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
> 

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

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Martin Björklund]

"Rob Wilton (rwilton)"  wrote:
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Ladislav Lhotka
> > Sent: 12 August 2020 08:43
> > To: Martin Björklund 
> > Cc: jclarke=40cisco@dmarc.ietf.org; netmod@ietf.org
> > Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace
> > changes and versioning
> > 
> > Martin Björklund  writes:
> > 
> > > Hi,
> > >
> > >
> > > Ladislav Lhotka  wrote:
> > >>
> > >>
> > >> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
> > >> > At the IETF 108 virtual meeting, Lada asked about what would happen
> > if he converted a YANG module to YIN syntax (or vice versa, or to some
> > other format).  This was during the discussion of the issue of what
> > should
> > happen if a module changes and the only changes are insignificant
> > whitespaces (e.g., strip trailing spaces, change line length of
> > descriptions, etc.).
> > >> >
> > >> > The authors/contributors discussed on this on our weekly calls, and
> > we propose:
> > >> >
> > >> > If a module changes and those changes are only insignificant
> > whitespace changes and the syntax of the module remains the same
> > (i.e.,
> > YANG to YANG, YIN, YIN, etc.), a new revision of the module MUST be
> > created.  If you are using YANG semver as your revision scheme, you
> > MUST
> > apply a PATCH version bump to that new module revision to indicate an
> > editorial change.
> > >> >
> > >> > The reasoning behind this decision is that it makes it very clear and
> > unambiguous to consumers that this module has been consciously
> > changed,
> > and those changes are only editorial.  This way one won’t be concerned
> > if
> > they note that a module of a given syntax with the same version but
> > different checksums and diffs wasn’t otherwise manipulated.
> > >> >
> > >> > That said, if a module changes format from one syntax to another but
> > maintains semantic equivalency, then the revision and YANG semver MUST
> > be
> > the same.  In that case, one will use the extension to realize that
> > this
> > module file cannot be directly compared to one of another syntax
> > without
> > looking at compiled or semantic representation.
> > >>
> > >> The last paragraph means that after a round trip YANG -> YIN -> YANG
> > the
> > >> initial and final YANG modules MUST have the same revision. However,
> > >> depending on the conversion tools used, they may easily differ in
> > >> whitespace, so their byte-oriented checksums won't be equal.
> > >>
> > >> I think there are in fact three cases:
> > >>
> > >> 1. Whitespace outside statement arguments - I believe this should
> > >> never
> > >> be significant.
> > >
> > > Agreed.
> > >
> > >> 2. Whitespace in the argument of "contact", "description",
> > >> "error-message" and "organization" - this is tricky because tools may
> > >> format such arguments differently. I am leaning towards making
> > >> whitespace insignificant in this case as well.
> > >>
> > >> 3. Whitespace in other arguments has to be significant and lead to a
> > >> revision bump.
> > >
> > > I think that any change in an argument string is an editorial change.
> > >
> > > For example, compare these two changes:
> > >
> > >A1.  description "a server.";
> > >A2.  description "A server.";
> > >
> > >B1.  description "A  server.";
> > >B2.  description "A server.";
> > >
> > > These are editorial changes, and thus the revision should be changed.
> > 
> > But consider
> > 
> >description
> >"A server and
> > its data.";
> > 
> > versus
> > 
> >description
> >"A server and
> >its data.";
> > 
> > Here the difference is only in presentation - a YANG parser gives the
> > same
> > string in both cases. Another awkward case is whitespace before a line
> > break.
> [RW] 
> 
> [As an individual contributor]
> 
> What about:
> 
> description
> "A server and
>  its data.";
>  
&g

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Martin Björklund]

Juergen Schoenwaelder  wrote:
> On Tue, Aug 11, 2020 at 05:06:13PM +0200, Martin Björklund wrote:
> > 
> > I think that any change in an argument string is an editorial change.
> > 
> > For example, compare these two changes:
> > 
> >A1.  description "a server.";
> >A2.  description "A server.";
> > 
> >B1.  description "A  server.";
> >B2.  description "A server.";
> > 
> > These are editorial changes, and thus the revision should be changed.
> > 
> > Note however that the following change might look like an editorial
> > whitespace change in the argument, but in fact it is not:
> > 
> >   C1.
> >   description
> >   "A server and
> >its data.";
> > 
> >   C2.
> >   description
> > "A server and
> >  its data.";
> 
> +1
> 
> I agree since whitespace outside YANG strings is insignificant.
> 
> Lets raise this to the next level. What about the following?
> 
>D1. description "A server.";
>D2. description "A server.";  // not very descriptive
> 
>E1. description "A server.";  // not   very descriptive
>E2. // not very descriptive
>description "A server.";

I think that comments should be treated as insignificant whitespace.

Comments in YANG are not tied to a specific statement, so it is
difficult to e.g. translate them to YIN properly.  For example to
which statement does the comment below belong?

  container foo {
 container bar; /* beware */ container baz;
  }


/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] IETF 108: Summary of insignificant whitespace changes and versioning

[Martin Björklund]

Hi,

"Joe Clarke (jclarke)"  wrote:
> 
> 
> > On Aug 11, 2020, at 10:45, Martin Björklund  wrote:
> > 
> > Hi,
> > 
> > "Joe Clarke \(jclarke\)"  wrote:
> >> At the IETF 108 virtual meeting, Lada asked about what would happen if
> >> he converted a YANG module to YIN syntax (or vice versa, or to some
> >> other format).  This was during the discussion of the issue of what
> >> should happen if a module changes and the only changes are
> >> insignificant whitespaces (e.g., strip trailing spaces, change line
> >> length of descriptions, etc.).
> >> 
> >> The authors/contributors discussed on this on our weekly calls, and we
> >> propose:
> >> 
> >> If a module changes and those changes are only insignificant
> >> whitespace changes and the syntax of the module remains the same
> >> (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module
> >> MUST be created.  If you are using YANG semver as your revision
> >> scheme, you MUST apply a PATCH version bump to that new module
> >> revision to indicate an editorial change.
> >> 
> >> The reasoning behind this decision is that it makes it very clear and
> >> unambiguous to consumers that this module has been consciously
> >> changed, and those changes are only editorial.  This way one won’t be
> >> concerned if they note that a module of a given syntax with the same
> >> version but different checksums and diffs wasn’t otherwise
> >> manipulated.
> > 
> > I think this is the wrong way to go.  I clean up formatting issues all
> > the time, including IETF modules.  I am pretty sure that if you
> > retrieve modules like "ietf-interfaces" or "ietf-yang-types" from
> > different vendors' products, you will get modules with differences in
> > whitespace - and this is not a problem AFAIK.
> > 
> > I think it is ok that a simple "diff" show whitespace changes in this
> > case.  I don't think it leads to any real problems.
> 
> We discussed this on the call.  The thinking was that a long diff
> output would essentially be unwieldy for some modules and important
> changes might be lost.  If the versions were the same, it would be
> ambiguous to the consume as to whether or not the module was only
> changed in trivial (i.e., less-than-editorial) or if more substantive
> changes happened.  If you trust the producer, maybe you assume they
> regenerated the module without trailing whitespace (or the like).  We
> felt there should be a more explicit signal.

But if you don't trust the producer, perhaps they didn't update the
revision according to the rules anyway?  I think we should have sound
rules and if people don't follow the rules then it's up to them.

> >> That said, if a module changes format from one syntax to another but
> >> maintains semantic equivalency, then the revision and YANG semver MUST
> >> be the same.  In that case, one will use the extension to realize that
> >> this module file cannot be directly compared to one of another syntax
> >> without looking at compiled or semantic representation.
> > 
> > This seems a bit inconsistent.  Suppose I round-trip from YANG to YIN
> > to YANG, and the result is different whitespace in the two YANG
> > modules.  The revision is the same, as explained above.  How is this
> > different from changing the whitespace in YANG directly?
> 
> We didn’t discuss this directly, but we did discuss auto-generators
> that could do this type of round-tripping.  The general consensus was
> that you would use the same post-processing tool (e.g., pyang -f yang)
> on the result to ensure consistency.

I don't think we can or should have a solution that works only if
people are using a (specific version of a) specific tool.

> And a consumer would look to a
> canonical source (like IANA, the IETF document, or the vendor) to
> ensure a consistent module.

It is quite common that clients download the modules from the servers,
rather than from a "canonical source".

> In terms of alternate sources, I would think that if one wanted to
> trust an IETF module downloaded from some other site, they could.  If
> that site did some additional formatting, that would be up to the
> consumer to resolve compared to what might be required by a package.
> But if the publisher (IETF in this case) were to republish a module
> with these stripped whitespace line endings, then that would be a
> different revision.

I think they (IETF/IANA) should be able to change insignificant
whitespace w/o changing the revision.


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

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Martin Björklund]

Hi,


Ladislav Lhotka  wrote:
> 
> 
> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
> > At the IETF 108 virtual meeting, Lada asked about what would happen if he 
> > converted a YANG module to YIN syntax (or vice versa, or to some other 
> > format).  This was during the discussion of the issue of what should happen 
> > if a module changes and the only changes are insignificant whitespaces 
> > (e.g., strip trailing spaces, change line length of descriptions, etc.).
> > 
> > The authors/contributors discussed on this on our weekly calls, and we 
> > propose:
> > 
> > If a module changes and those changes are only insignificant whitespace 
> > changes and the syntax of the module remains the same (i.e., YANG to YANG, 
> > YIN, YIN, etc.), a new revision of the module MUST be created.  If you are 
> > using YANG semver as your revision scheme, you MUST apply a PATCH version 
> > bump to that new module revision to indicate an editorial change.
> > 
> > The reasoning behind this decision is that it makes it very clear and 
> > unambiguous to consumers that this module has been consciously changed, and 
> > those changes are only editorial.  This way one won’t be concerned if they 
> > note that a module of a given syntax with the same version but different 
> > checksums and diffs wasn’t otherwise manipulated.
> > 
> > That said, if a module changes format from one syntax to another but 
> > maintains semantic equivalency, then the revision and YANG semver MUST be 
> > the same.  In that case, one will use the extension to realize that this 
> > module file cannot be directly compared to one of another syntax without 
> > looking at compiled or semantic representation.
> 
> The last paragraph means that after a round trip YANG -> YIN -> YANG the
> initial and final YANG modules MUST have the same revision. However,
> depending on the conversion tools used, they may easily differ in
> whitespace, so their byte-oriented checksums won't be equal.
> 
> I think there are in fact three cases:
> 
> 1. Whitespace outside statement arguments - I believe this should never
> be significant.

Agreed.

> 2. Whitespace in the argument of "contact", "description",
> "error-message" and "organization" - this is tricky because tools may
> format such arguments differently. I am leaning towards making
> whitespace insignificant in this case as well.
> 
> 3. Whitespace in other arguments has to be significant and lead to a
> revision bump.

I think that any change in an argument string is an editorial change.

For example, compare these two changes:

   A1.  description "a server.";
   A2.  description "A server.";

   B1.  description "A  server.";
   B2.  description "A server.";

These are editorial changes, and thus the revision should be changed.

Note however that the following change might look like an editorial
whitespace change in the argument, but in fact it is not:

  C1.
  description
  "A server and
   its data.";

  C2.
  description
"A server and
 its data.";


/martin


> 
> And one more corner case for both 2 a 3: what if "\t" is replaced with
> the tab character in a double-quoted string? For YANG, these two strings
> are absolutely equivalent.
> 
> Lada
> 
> > 
> > Thoughts?
> > 
> > Joe
> > ___
> > 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] IETF 108: Summary of insignificant whitespace changes and versioning

[Martin Björklund]

Hi,

"Joe Clarke \(jclarke\)"  wrote:
> At the IETF 108 virtual meeting, Lada asked about what would happen if
> he converted a YANG module to YIN syntax (or vice versa, or to some
> other format).  This was during the discussion of the issue of what
> should happen if a module changes and the only changes are
> insignificant whitespaces (e.g., strip trailing spaces, change line
> length of descriptions, etc.).
> 
> The authors/contributors discussed on this on our weekly calls, and we
> propose:
> 
> If a module changes and those changes are only insignificant
> whitespace changes and the syntax of the module remains the same
> (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module
> MUST be created.  If you are using YANG semver as your revision
> scheme, you MUST apply a PATCH version bump to that new module
> revision to indicate an editorial change.
>
> The reasoning behind this decision is that it makes it very clear and
> unambiguous to consumers that this module has been consciously
> changed, and those changes are only editorial.  This way one won’t be
> concerned if they note that a module of a given syntax with the same
> version but different checksums and diffs wasn’t otherwise
> manipulated.

I think this is the wrong way to go.  I clean up formatting issues all
the time, including IETF modules.  I am pretty sure that if you
retrieve modules like "ietf-interfaces" or "ietf-yang-types" from
different vendors' products, you will get modules with differences in
whitespace - and this is not a problem AFAIK.

I think it is ok that a simple "diff" show whitespace changes in this
case.  I don't think it leads to any real problems.

> That said, if a module changes format from one syntax to another but
> maintains semantic equivalency, then the revision and YANG semver MUST
> be the same.  In that case, one will use the extension to realize that
> this module file cannot be directly compared to one of another syntax
> without looking at compiled or semantic representation.

This seems a bit inconsistent.  Suppose I round-trip from YANG to YIN
to YANG, and the result is different whitespace in the two YANG
modules.  The revision is the same, as explained above.  How is this
different from changing the whitespace in YANG directly?


/martin


> Thoughts?
> 
> 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] Issue with path statements in RPC

[Martin Björklund]

tom petch  wrote:
> From: netmod  on behalf of Martin Björklund 
> 
> Sent: 10 August 2020 10:24
> 
> Italo Busi  wrote:
> > We have found some issues with RPC XPaths when developing the YANG
> > code for
> > https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation
> >
> > As discussed during the TEAS WG session in IETF 108, this issue has
> > been raised on pyang github:
> > https://github.com/mbj4668/pyang/issues/662
> >
> > It was also suggested to check with Netmod WG what should be the
> > correct behavior according to RFC7950.
> >
> > The following code is accepted by pyang 1.75 but not by pyang 2.1:
> >
> > type leafref {
> >   path "/te:tunnels-path-compute/te:input/"
> >  + "te:path-compute-info/"
> > + "te-pc:tunnel-attributes/te-pc:tunnel-name";
> > }
> >
> > The following code instead is accepted by pyang 2.1 but not by pyang
> > 1.7.5:
> >
> > type leafref {
> >   path "/te:tunnels-path-compute/"
> >  + "te:path-compute-info/"
> > + "te-pc:tunnel-attributes/te-pc:tunnel-name";
> > }
> 
> The leafref path is an XPath expression, which operates on the data
> tree (instance data).  The "input" node is not present in the instance
> data / data tree.  See section 6.4.1 of RFC 7950.
> 
> So the latter path (as verfied by pyang 2.1) is correct.
> 
> 
> Martin,
> 
> Thank you for the clarifications.  Just looking at the first issue, what gave 
> me pause was section 9.9; the path statement is used to identify the referred 
> leaf in the schema tree and 'input' is in the schema tree.  But I can see 
> that 6.4.1 overrides that implication.

Hmm, yes that text can certainly be improved.  9.9.2 however refers to
6.4.1.


/martin



> 
> Tom Petch
> 
> 
> 
> > Moreover the following when statement, which is quite useful to
> > constraint which information is provided by the RPC output based on
> > some attributes in the RPC input, is accepted by pyang 1.7.5 but not
> > accepted by pyang 2.1;
> >
> >   augment "/te:tunnels-actions/te:output" {
> > description
> >   "Augment Tunnels Action RPC input with path delete result";
> >
> > container path-computed-delete-result {
> >   when "derived-from-or-self(../../te:input/te:action-info/"
> >  + "te:action, 'tunnel-action-path-compute-delete')";
> >   description "Path Delete RPC output";
> >   leaf-list path-compute-transaction-id {
> > type string;
> > description
> >   "The list of the transaction-id values of the
> >transient states that have been successfully deleted";
> >   }
> > }   // container path-computed-delete-result
> >   }   // path-delete rpc output
> >
> >
> > Could you please help us to understand what is the correct behavior?
> >
> > In case the correct behavior is the one of pyang 2.1, our
> > understanding is that it would not be possible to provide in YANG when
> > constraints for the data nodes in the RPC output depending on specific
> > values of the data nodes used in the RPC input. Therefore these
> > constraints should be specified as behavior and implemented in the
> > back-end.
> >
> > Is our understanding correct?
> 
> Yes, this is correct.  It is not possible to refer to the
> corresponding "input" instance data in the XPath expressions for the
> "output".
> 
> 
> /martin
> 
> 
> >
> > Thanks for your help
> >
> > Sergio and Italo (on behalf of co-authors/contributors)
> >
> > Italo Busi
> > Principal Optical Transport Network Research Engineer
> >
> > [cid:image001.jpg@01D5AC11.9575BB40]
> > 
> >
> > Huawei Technologies Italia S.r.l.
> > Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090
> > Segrate (MI)
> > Tel: +39 345 4721946 - Mobile:
> > italo.b...@huawei.com<mailto:italo.b...@huawei.com>
> >
> > __
> > Huawei Technologies Italia S.r.l. is a company registered in Italy at
> > the Company Registration Office of Milan, with registered number
> > 04501190963 and equity capital €3,000,000 fully paid up, whose
> > registered office is in Milan, Via Lorenteggio 240, Tower A, 20

Re: [netmod] Issue with path statements in RPC

[Martin Björklund]

Italo Busi  wrote:
> We have found some issues with RPC XPaths when developing the YANG
> code for
> https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation
> 
> As discussed during the TEAS WG session in IETF 108, this issue has
> been raised on pyang github:
> https://github.com/mbj4668/pyang/issues/662
> 
> It was also suggested to check with Netmod WG what should be the
> correct behavior according to RFC7950.
> 
> The following code is accepted by pyang 1.75 but not by pyang 2.1:
> 
> type leafref {
>   path "/te:tunnels-path-compute/te:input/"
>  + "te:path-compute-info/"
> + "te-pc:tunnel-attributes/te-pc:tunnel-name";
> }
> 
> The following code instead is accepted by pyang 2.1 but not by pyang
> 1.7.5:
> 
> type leafref {
>   path "/te:tunnels-path-compute/"
>  + "te:path-compute-info/"
> + "te-pc:tunnel-attributes/te-pc:tunnel-name";
> }

The leafref path is an XPath expression, which operates on the data
tree (instance data).  The "input" node is not present in the instance
data / data tree.  See section 6.4.1 of RFC 7950.

So the latter path (as verfied by pyang 2.1) is correct.

> Moreover the following when statement, which is quite useful to
> constraint which information is provided by the RPC output based on
> some attributes in the RPC input, is accepted by pyang 1.7.5 but not
> accepted by pyang 2.1;
> 
>   augment "/te:tunnels-actions/te:output" {
> description
>   "Augment Tunnels Action RPC input with path delete result";
> 
> container path-computed-delete-result {
>   when "derived-from-or-self(../../te:input/te:action-info/"
>  + "te:action, 'tunnel-action-path-compute-delete')";
>   description "Path Delete RPC output";
>   leaf-list path-compute-transaction-id {
> type string;
> description
>   "The list of the transaction-id values of the
>transient states that have been successfully deleted";
>   }
> }   // container path-computed-delete-result
>   }   // path-delete rpc output
> 
> 
> Could you please help us to understand what is the correct behavior?
> 
> In case the correct behavior is the one of pyang 2.1, our
> understanding is that it would not be possible to provide in YANG when
> constraints for the data nodes in the RPC output depending on specific
> values of the data nodes used in the RPC input. Therefore these
> constraints should be specified as behavior and implemented in the
> back-end.
> 
> Is our understanding correct?

Yes, this is correct.  It is not possible to refer to the
corresponding "input" instance data in the XPath expressions for the
"output".


/martin


> 
> Thanks for your help
> 
> Sergio and Italo (on behalf of co-authors/contributors)
> 
> Italo Busi
> Principal Optical Transport Network Research Engineer
> 
> [cid:image001.jpg@01D5AC11.9575BB40]
> 
> 
> Huawei Technologies Italia S.r.l.
> Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090
> Segrate (MI)
> Tel: +39 345 4721946 - Mobile:
> italo.b...@huawei.com
> 
> __
> Huawei Technologies Italia S.r.l. is a company registered in Italy at
> the Company Registration Office of Milan, with registered number
> 04501190963 and equity capital €3,000,000 fully paid up, whose
> registered office is in Milan, Via Lorenteggio 240, Tower A, 20147
> Milan, Italy. Huawei Technologies Italia S.r.l. is 100% owned by
> Huawei Technologies Cooperatief U.A.
> CONAI Reg. No. cc 12639454 - A.E.E. Registry No. IT1001006521 -
> Batteries and Accumulators Registry No. IT12050P2839.
> 
> This e-mail and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address
> is listed above. Any use of the information contained herein in any
> way (including, but not limited to, total or partial disclosure,
> reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error,
> please notify the sender by phone or email immediately and delete it!
> Thank you.
> 
> PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection
> Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs
> you that the personal data contained in this email will be collected
> and treated for the acquisition of information preliminary to the
> conclusion of contracts, for the definition of the contractual
> relationship, as well as for the fulfillment of legal requirements
>

Re: [netmod] [Technical Errata Reported] RFC7317 (6245)

[Martin Björklund]

Hi,

This errata is correct; the must expression in the errata reflects the
intention correctly.

But the question is if this can be fixed by an RFC errata...


/martin


RFC Errata System  wrote:
> The following errata report has been submitted for RFC7317,
> "A YANG Data Model for System Management".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6245
> 
> --
> Type: Technical
> Reported by: Maurizio Brigandi' 
> 
> Section: 6
> 
> Original Text
> -
> 
>  leaf-list user-authentication-order {
>type identityref {
>  base authentication-method;
>}
>must '(. != "sys:radius" or ../../radius/server)' 
> 
> 
> 
> Corrected Text
> --
> 
>  leaf-list user-authentication-order {
>type identityref {
>  base authentication-method;
>}
>must '(not(. = "sys:radius") or ../../radius/server)'
>  
> 
> Notes
> -
> As indicated in https://www.w3.org/TR/1999/REC-xpath-19991116/#booleans
> 
> the following expression comparing a node-set with a string
> 
>. != "sys:radius"
> 
> is true if at least one node in the node-set satisfies the boolean expression.
> 
> This is not the intention of the "must" condition.
> 
> It is necessary to use not(. = "sys:radius") to achieve the right intention 
> of the check.
> 
> 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. 
> 
> --
> RFC7317 (draft-ietf-netmod-system-mgmt-16)
> --
> Title   : A YANG Data Model for System Management
> Publication Date: August 2014
> Author(s)   : A. Bierman, M. Bjorklund
> 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

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

Re: [netmod] Revision labels for submodules

[Martin Björklund]

Martin Björklund  wrote:
> "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> > 
> > On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:
> > 
> > Hi,
> > 
> > "Reshad Rahman (rrahman)"  wrote:
> > > Hi,
> > > 
> > > This came up during this week's meeting. We briefly discussed whether
> > > there's a need to version sub-modules or can we restrict versioning to
> > > modules only. We would like to hear from the WG on this, especially
> > > those with experience managing sub-modules.
> > 
> > Yes I think this is needed.  At tail-f, there are several modules with
> > many submodules.  These modules always use include by revision, and
> > always the main module is always uddated when any submodule is
> > updated.  It doens't make much sense IMO to not use include by
> > revision.
> > 
> > > For completeness, below is an update from Jason in github:
> > > My initial reaction is that we should not preclude the use of revision
> > > label with a submodule. Submodules have their own version today. The
> > > trick is to define (or explicitly say it is out of scope) whether a
> > > module version must change if any underlying submodule versions
> > > change. That gets difficult if you consider simply moving a leaf from
> > > one sub-module to another (without changing anything else about it -
> > > its context, etc).
> > 
> > Why would this be difficult?  The revision date is updated on any
> > editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
> > from submodule A to submodule B, then their revisions are udpated, and
> > hence the module's include-by revision is udpated, and hence the
> > module's revision ois updated.
> > 
> > I think what Jason meant is that by moving a leaf between submodules,
> > it's possible the module's schema didn't change.
> > So yes revision date is updated, but you can't blindly update the
> > revision-label.
> 
> Why not?

Aha, I think I understand what you mean.  And in light of Tom's
comment in the other thread, I think that using 'revision-label' in
the module and not in sub-modules makes sense.  sub-modules can still
use the date, and be included by revision (date).


/martin



> 
> 
> /martin
> 
> 
> > 
> > Regards,
> > Reshad.
> > 
> > /martin
> > 
> > 
> > 
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)"
> > >  > > rrahman=40cisco@dmarc.ietf.org> wrote:
> > > 
> > > Hi,
> > > 
> > > https://github.com/netmod-wg/yang-ver-dt/issues/49
> > > 
> > > o  3.3
> > > 
> > > Submodules MUST NOT use revision label schemes that 
> > could
> > > be
> > > confused
> > > with the including module's revision label scheme.
> > > 
> > >   Hmm, how do I ensure that this MUST NOT is handled
> > >   correctly?
> > >   What
> > >   exactly does "could be confused with" mean?
> > > 
> > > Good point. What was meant by that the label space for modules and
> > > sub-modules are orthogonal.  e.g. the sub-module and module both 
> > have
> > > the same label, it shouldn't be inferred that the 2 are related.
> > > We'll change/clarify the text.
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman 
> > (rrahman)"
> > >  > > rrahman=40cisco@dmarc.ietf.org> wrote:
> > > 
> > > Hi Martin,
> > > 
> > > We've opened issues to track your review comments (see
> > > below). Will
> > > kick off separate therads for each issue.
> > > 
> > > 
> > https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+l

Re: [netmod] Revision labels for submodules

[Martin Björklund]

"Reshad Rahman (rrahman)"  wrote:
> Hi,
> 
> On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:
> 
> Hi,
> 
> "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> > 
> > This came up during this week's meeting. We briefly discussed whether
> > there's a need to version sub-modules or can we restrict versioning to
> > modules only. We would like to hear from the WG on this, especially
> > those with experience managing sub-modules.
> 
> Yes I think this is needed.  At tail-f, there are several modules with
> many submodules.  These modules always use include by revision, and
> always the main module is always uddated when any submodule is
> updated.  It doens't make much sense IMO to not use include by
> revision.
> 
> > For completeness, below is an update from Jason in github:
> > My initial reaction is that we should not preclude the use of revision
> > label with a submodule. Submodules have their own version today. The
> > trick is to define (or explicitly say it is out of scope) whether a
> > module version must change if any underlying submodule versions
> > change. That gets difficult if you consider simply moving a leaf from
> > one sub-module to another (without changing anything else about it -
> > its context, etc).
> 
> Why would this be difficult?  The revision date is updated on any
> editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
> from submodule A to submodule B, then their revisions are udpated, and
> hence the module's include-by revision is udpated, and hence the
> module's revision ois updated.
> 
> I think what Jason meant is that by moving a leaf between submodules,
> it's possible the module's schema didn't change.
> So yes revision date is updated, but you can't blindly update the
> revision-label.

Why not?


/martin


> 
> Regards,
> Reshad.
> 
> /martin
> 
> 
> 
> > 
> > Regards,
> > Reshad.
> > 
> > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)"
> >  > rrahman=40cisco@dmarc.ietf.org> wrote:
> > 
> > Hi,
> > 
> > https://github.com/netmod-wg/yang-ver-dt/issues/49
> > 
> > o  3.3
> > 
> > Submodules MUST NOT use revision label schemes that 
> could
> > be
> > confused
> > with the including module's revision label scheme.
> > 
> >   Hmm, how do I ensure that this MUST NOT is handled
> >   correctly?
> >   What
> >   exactly does "could be confused with" mean?
> > 
> > Good point. What was meant by that the label space for modules and
> > sub-modules are orthogonal.  e.g. the sub-module and module both 
> have
> > the same label, it shouldn't be inferred that the 2 are related.
> > We'll change/clarify the text.
> > 
> > Regards,
> > Reshad.
> > 
> > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman 
> (rrahman)"
> >  > rrahman=40cisco@dmarc.ietf.org> wrote:
> > 
> > Hi Martin,
> > 
> > We've opened issues to track your review comments (see
> > below). Will
> > kick off separate therads for each issue.
> > 
> > 
> https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> > 
> > Regards,
> > Reshad.
> > 
> > On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
> >  wrote:
> > 
> > Hi,
> > 
> > Here are my review comments of
> > draft-verdt-netmod-yang-module-versioning-01.
> > 
> > 
> > 
> > o  3.1.1
> > 
> > o In statements that have any data definition statements
> > as
> >substatements, those data definition substatements

Re: [netmod] Revision labels for submodules

[Martin Björklund]

Hi,

"Reshad Rahman (rrahman)"  wrote:
> Hi,
> 
> This came up during this week's meeting. We briefly discussed whether
> there's a need to version sub-modules or can we restrict versioning to
> modules only. We would like to hear from the WG on this, especially
> those with experience managing sub-modules.

Yes I think this is needed.  At tail-f, there are several modules with
many submodules.  These modules always use include by revision, and
always the main module is always uddated when any submodule is
updated.  It doens't make much sense IMO to not use include by
revision.

> For completeness, below is an update from Jason in github:
> My initial reaction is that we should not preclude the use of revision
> label with a submodule. Submodules have their own version today. The
> trick is to define (or explicitly say it is out of scope) whether a
> module version must change if any underlying submodule versions
> change. That gets difficult if you consider simply moving a leaf from
> one sub-module to another (without changing anything else about it -
> its context, etc).

Why would this be difficult?  The revision date is updated on any
editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
from submodule A to submodule B, then their revisions are udpated, and
hence the module's include-by revision is udpated, and hence the
module's revision ois updated.


/martin



> 
> Regards,
> Reshad.
> 
> On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> https://github.com/netmod-wg/yang-ver-dt/issues/49
> 
> o  3.3
> 
> Submodules MUST NOT use revision label schemes that could be
> confused
> with the including module's revision label scheme.
> 
>   Hmm, how do I ensure that this MUST NOT is handled correctly?
>   What
>   exactly does "could be confused with" mean?
> 
> Good point. What was meant by that the label space for modules and
> sub-modules are orthogonal.  e.g. the sub-module and module both have
> the same label, it shouldn't be inferred that the 2 are related.
> We'll change/clarify the text.
> 
> Regards,
> Reshad.
> 
> On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi Martin,
> 
> We've opened issues to track your review comments (see below). Will
> kick off separate therads for each issue.
>     
> 
> https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> 
> Regards,
> Reshad.
> 
> On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
>  wrote:
> 
> Hi,
> 
> Here are my review comments of
> draft-verdt-netmod-yang-module-versioning-01.
> 
> 
> 
> o  3.1.1
> 
> o  In statements that have any data definition statements as
>substatements, those data definition substatements MAY be
>reordered, as long as they do not change the ordering or
>any "rpc"
>"input" substatements.
> 
>   I think this needs to capture that no descendant statements to
>   "input" can be reordered.  Same for "output" (note, "input" and
>   "output" in both "rpc" and "action").
> 
> 
> o  3.3
> 
> All revision labels that match the pattern for the "version"
> typedef in the ietf-yang-semver YANG module MUST be
> interpreted as
> YANG semantic version numbers.
> 
>   I don't think this is a good idea.  Seems like a layer
>   violation.
>   What if my project use another dialect of semver, that wouldn't
>   be
>   possible with this rule.  I think this needs to be removed.
> 
> 
> o  3.3
> 
> Submodules MUST NOT use revision label schemes that could be
> confused
> with the including module's revision label