Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

[Kent Watsen]

Juergen,

Does the update address all your concerns?  Do you feel there is
a need for another LC

Hi Balazs,

Did you mean to send this to the netmod-chairs alias?  Oh well, as
 long we’re here, following are some questions/comments:

Have the YANG modules been validated and tested for formatting?
(i.e., pyang -f yang --keep-comments --yang-line-length 69 filename) 

Have the examples in the draft validated against the YANG module?

Please review the Normative/Informative status of the references.
Not looking carefully, but RFCs 2119 and 8174 should be Normative, 
and I think RFCs 3688 and 6020 should be Informative, right?

All of the “import” statements in the YANG module are missing a
“reference” statement.

Please add a paragraph to Section 5.2 preceding the YANG module
indicating all the aforementioned Normative references.

The copyright in the YANG module needs to be 2020 (not 2019)

Please ensure a blank line between paragraphs in the “description"
statements.

Please add a statement to the Introduction regarding why the module
Isn’t compliant with NMDA.

The tree diagram does not adhere to the syntax described in 
draft-ietf-netmod-yang-data-ext.  Please update the first sentence 
in Section 5.1 to also reference draft-ietf-netmod-yang-data-ext.

Please ensure that the planning-text version of the draft passes
IDNITS (https://www6.ietf.org/tools/idnits) at the “verbose output”
level and correct any issues found, or explain why they shouldn’t
be corrected.


Thanks,
Kent  // shepherd


> On Feb 14, 2020, at 11:03 AM, Balázs Lengyel  
> wrote:
> 
> Hello Chairs,
> I replied to Juergen, and exchanged some additional mails with him. I updated 
> the draft to draft-ietf-netmod-yang-instance-file-format-07. Please take it 
> forward in the process.
> 
> https://protect2.fireeye.com/v1/url?k=ed368c2e-b1bcaefa-ed36ccb5-0cc47ad93e6a-1bf0817821133165=1=b8630aed-b037-42b0-a579-0e6e8067e0eb=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netmod-yang-instance-file-format-07
> Regards Balazs
> 
> -Original Message-
> From: netmod  On Behalf Of Kent Watsen
> Sent: 2020. február 9., vasárnap 20:23
> To: netmod@ietf.org
> Subject: Re: [netmod] WG Last Call: 
> draft-ietf-netmod-yang-instance-file-format-06
> 
> This message closes the WGLC.
> 
> Authors, please respond to Juergen’s message from Jan 20, ultimately posting 
> an update to the draft.
> 
> Thanks,
> Kent // as shepherd
> 
> 
> 
>> On Jan 7, 2020, at 7:41 AM, Kent Watsen  wrote:
>> 
>> 
>> This begins a two-week Working Group Last Call (WGLC) on 
>> draft-ietf-netmod-yang-instance-file-format-06.  The WGLC ends on Jan 21.  
>> Please send your comments to the working group mailing list.
>> 
>> Positive comments, e.g., "I've reviewed this document and believe it is 
>> ready for publication", are welcome!  This is useful and important, even 
>> from authors.  Objections, concerns, and suggestions are also welcomed at 
>> this time.
>> 
>> Thank you,
>> NETMOD 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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Randy Presuhn]

Hi -

On 2/14/2020 3:21 AM, Christian Hopps wrote:

How about I add this to the description of "typedef tag" in the module:

description
  "A tag is a type 'string' value that does not include carriage
   return, newline or tab characters. It SHOULD begin with a
   registered prefix; however, tags without a registered prefix
- SHOULD NOT be treated as invalid.";
+ SHOULD NOT be treated as invalid. For the purposes of comparison
+ non-ascii strings should use 'NFC' (RFC5198) normalization";
  }



There are other considerations beyond normalization form.
For the tip of the iceberg, see the definition of SnmpAdminString
in RFC 3411, or the "SHOULD be avoided" stuff in RFC 5198.

For things like tags where one would like to minimize accidental
visual punning, I'd suggest NFKC should probably be given some
consideration.   Excellent presentation of the issues is
available at https://unicode.org/reports/tr15/

That said, these are issues that were raised in the earliest days of 
Netmod /

Netconf, and no one should be surprised that they haven't gone away by
themselves.  So I find my self in ironic agreement with Andy that it doesn't
make sense to wait for / impose a global solution, because there's plenty
of evidence that having all sorts of ill-defined cases of questionable
interoperability in theory hasn't been sufficient to prevent adoption of
the technology.

Randy

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Andy Bierman]

On Fri, Feb 14, 2020 at 3:01 AM Christian Hopps  wrote:

> I was not approaching this discuss with this level of change in mind. How
> many years does it take to get a YANG model even one as simple as this
> completed?
>
>

I strongly agree.
Just because there are refinements to the YANG "string" data type that are
possible
does not mean the Module Tags RFC has to solve that problem, or wait until
it is solved.
Every YANG module using the "string" data type (all of them?) could have
the same problem.



> Thanks,
> Chris.
>

Andy


>
> > On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton) 
> wrote:
> >
> > Hi Alexey, Christian,
> >
> > Allowing Unicode but requiring normalization as per RFC 5198 for IANA
> managed tags makes sense to me.
> >
> > But does the server also need to normalize any configured tags?  I.e.
> should the description for the tag typedef also specify that tags SHOULD be
> normalized, and specify a normalization method that SHOULD be used?  Or is
> the onus on the client to use sensible (i.e. already normalized) values,
> and if so, does that need to be stated?
> >
> > Thanks,
> > Rob
> >
> >
> >> -Original Message-
> >> From: iesg  On Behalf Of Alexey Melnikov
> >> Sent: 13 February 2020 13:10
> >> To: Christian Hopps 
> >> Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The IESG
> >> ; netmod@ietf.org;
> draft-ietf-netmod-module-t...@ietf.org
> >> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
> >> 07: (with DISCUSS)
> >>
> >> Hi Christian,
> >>
> >> On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
> >>> The intent in the document is to place as few restrictions on tags as
> >>> possible to allow for future-proofing and organic growth of use both
> >>> within and outside of SDOs. For standard tags we trust IANA (and the
> >>> human behind the process) to make the call on whether a tag is already
> >>> present. :)
> >>
> >> And the problem with that is that because there might be multiple ways
> to
> >> encode in Unicode visually indistinguishable tags IANA would end up
> asking
> >> IESG for help.
> >>
> >> So you need to at minimum specify a Unicode normalization form to use. I
> >> suggest you normatively reference RFC 5198 here.
> >>
> >>> Having worked for a company where a lot of XML string data was
> >>> non-ascii I find limiting to ascii to be rather restrictive.
> >>
> >> Best Regards,
> >> Alexey
> >>
> >>>
> >>> Thanks,
> >>> Chris.
> >>>
>  On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
> >>  wrote:
> 
>  Alexey Melnikov has entered the following ballot position for
>  draft-ietf-netmod-module-tags-07: Discuss
> 
>  When responding, please keep the subject line intact and reply to
>  all email addresses included in the To and CC lines. (Feel free to
>  cut this introductory paragraph, however.)
> 
> 
>  Please refer to
>  https://www.ietf.org/iesg/statement/discuss-criteria.html
>  for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>  The document, along with other ballot positions, can be found here:
>  https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> 
> 
> 
>  
>  --
>  DISCUSS:
>  
>  --
> 
>  This is generally a fine document, but after checking RFC 7950
>  syntax for strings I question why you think you need non ASCII tags.
>  There are so many problems that can arise from that. For example,
>  how would IANA be able to enforce uniqueness of Unicode tags written
>  in different Unicode canonicalisation forms?
> 
> 
> 
> 
> >>>
> >>>
> >
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

[Balázs Lengyel]

Hello Chairs,
I replied to Juergen, and exchanged some additional mails with him. I updated 
the draft to draft-ietf-netmod-yang-instance-file-format-07. Please take it 
forward in the process.

https://protect2.fireeye.com/v1/url?k=ed368c2e-b1bcaefa-ed36ccb5-0cc47ad93e6a-1bf0817821133165=1=b8630aed-b037-42b0-a579-0e6e8067e0eb=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netmod-yang-instance-file-format-07
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Kent Watsen
Sent: 2020. február 9., vasárnap 20:23
To: netmod@ietf.org
Subject: Re: [netmod] WG Last Call: 
draft-ietf-netmod-yang-instance-file-format-06

This message closes the WGLC.

Authors, please respond to Juergen’s message from Jan 20, ultimately posting an 
update to the draft.

Thanks,
Kent // as shepherd



> On Jan 7, 2020, at 7:41 AM, Kent Watsen  wrote:
> 
> 
> This begins a two-week Working Group Last Call (WGLC) on 
> draft-ietf-netmod-yang-instance-file-format-06.  The WGLC ends on Jan 21.  
> Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors.  Objections, concerns, and suggestions are also welcomed at this 
> time.
> 
> Thank you,
> NETMOD 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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-07.txt
Pages   : 26
Date: 2020-02-13

Abstract:
   There is a need to document data defined in YANG models when a live
   server is not available.  Data is often needed already at design or
   implementation time or needed by groups that do not have a live
   running server available.  This document specifies a standard file
   format for YANG instance data, which follows the syntax and semantics
   of existing YANG models, and annotates it with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-07
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Schönwälder , Jürgen]

Rob,

I think there are two related issues here:

a) If we need normalized strings (to avoid comparison suprises), we
   should have a common type for them; rfc6991-bis would be a proper
   home. I am _not_ saying we should delay the tags document for this,
   but we should think about providing a solution that can be easily
   reused. Right now, we often use strings as part of keys, which can
   lead to comparison issues.

b) It seems that normalized strings only solve part of the problem. If
   an organization creates names for 'things', the organization likely
   wants to further restrict the format of these names to something
   sensible to avoid fun with different kinds of hyphens or emojis or
   ... So while creative unicode characters may technically work,
   there will likely be good reasons to avoid some of them. (There are
   reasons why we have coding styles for most programming languages.)
   These rules may, however, differ between organizations.

We should not confuse a) and b). If IANA needs additional guidelines
for tags (their coding style for tags), then we should provide these
guidelines, i.e., this is a type b) action. The type a) action is
needed to technically ensure that comparisons do not lead to
surprises. But a) won't be an answer for all type b) issues. Of
course, we could give IANA a 'coding style' that avoids any
normalization issues. This would make IANA assigned tags safe but
would not avoid comparison surprises for other sources of tags.

/js

On Fri, Feb 14, 2020 at 10:30:50AM +, Rob Wilton (rwilton) wrote:
> Hi Juergen,
> 
> This sounds potentially useful to me, although should this be for general 
> unicode strings (e.g. ones that might include spaces), or just identifiers 
> (without any spaces)?.  Is this something that could/should go into 
> rfc6991-bis, or at least be discussed in that context?
> 
> I would have thought that normalization would be required wherever a 
> configurable unicode string is used as a list key, or leaf-list.
> 
> Thanks,
> Rob
> 
> 
> > -Original Message-
> > From: iesg  On Behalf Of Schönwälder, Jürgen
> > Sent: 13 February 2020 18:39
> > To: Alexey Melnikov 
> > Cc: netmod-cha...@ietf.org; draft-ietf-netmod-module-t...@ietf.org;
> > netmod@ietf.org; Joel Jaeggli ; Christian Hopps
> > ; The IESG 
> > Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-
> > module-tags-07: (with DISCUSS)
> > 
> > And a longer term solution might be to define a YANG Net-Unicode string
> > datatype that can be used in all situations where non-normalized strings
> > may cause problems. The problem (if one agrees it is one) is likely much
> > bigger than just YANG tags, there likely are many uses of YANG strings
> > where normalization would be desirable.
> > 
> > /js
> > 
> > On Thu, Feb 13, 2020 at 01:10:02PM +, Alexey Melnikov wrote:
> > > Hi Christian,
> > >
> > > On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
> > > > The intent in the document is to place as few restrictions on tags
> > > > as possible to allow for future-proofing and organic growth of use
> > > > both within and outside of SDOs. For standard tags we trust IANA
> > > > (and the human behind the process) to make the call on whether a tag
> > > > is already present. :)
> > >
> > > And the problem with that is that because there might be multiple ways
> > to encode in Unicode visually indistinguishable tags IANA would end up
> > asking IESG for help.
> > >
> > > So you need to at minimum specify a Unicode normalization form to use.. I
> > suggest you normatively reference RFC 5198 here.
> > >
> > > > Having worked for a company where a lot of XML string data was
> > > > non-ascii I find limiting to ascii to be rather restrictive.
> > >
> > > Best Regards,
> > > Alexey
> > >
> > > >
> > > > Thanks,
> > > > Chris.
> > > >
> > > > > On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
> >  wrote:
> > > > >
> > > > > Alexey Melnikov has entered the following ballot position for
> > > > > draft-ietf-netmod-module-tags-07: Discuss
> > > > >
> > > > > When responding, please keep the subject line intact and reply to
> > > > > all email addresses included in the To and CC lines. (Feel free to
> > > > > cut this introductory paragraph, however.)
> > > > >
> > > > >
> > > > > Please refer to
> > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > >
> > > > >
> > > > > The document, along with other ballot positions, can be found here:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 
> > > > > DISCUSS:
> > > > > --
> > > > > 
> > > > >
> > > > > This is generally a fine document, but after checking RFC 7950
> > > > > syntax for strings I question why 

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Chris,

I think that would be okay, although perhaps using SHOULD rather than "should" 
might be better, given that SHOULD NOT is used elsewhere in the description.

Thanks,
Rob


> -Original Message-
> From: Christian Hopps 
> Sent: 14 February 2020 11:21
> To: Rob Wilton (rwilton) 
> Cc: Christian Hopps ; Alexey Melnikov
> ; netmod-cha...@ietf.org; Joel Jaeggli
> ; The IESG ; netmod@ietf.org; draft-ietf-
> netmod-module-t...@ietf.org
> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
> 07: (with DISCUSS)
> 
> How about I add this to the description of "typedef tag" in the module:
> 
>description
>  "A tag is a type 'string' value that does not include carriage
>   return, newline or tab characters. It SHOULD begin with a
>   registered prefix; however, tags without a registered prefix
> - SHOULD NOT be treated as invalid.";
> + SHOULD NOT be treated as invalid. For the purposes of comparison
> + non-ascii strings should use 'NFC' (RFC5198) normalization";
>  }
> 
> Thanks,
> Chris.
> 
> > On Feb 14, 2020, at 6:06 AM, Christian Hopps  wrote:
> >
> > For the record this one is 3 years and counting. For a list of tags.
> >
> >> On Feb 14, 2020, at 6:01 AM, Christian Hopps  wrote:
> >>
> >> I was not approaching this discuss with this level of change in mind.
> How many years does it take to get a YANG model even one as simple as this
> completed?
> >>
> >> Thanks,
> >> Chris.
> >>
> >>> On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton) 
> wrote:
> >>>
> >>> Hi Alexey, Christian,
> >>>
> >>> Allowing Unicode but requiring normalization as per RFC 5198 for IANA
> managed tags makes sense to me.
> >>>
> >>> But does the server also need to normalize any configured tags?  I.e.
> should the description for the tag typedef also specify that tags SHOULD
> be normalized, and specify a normalization method that SHOULD be used?  Or
> is the onus on the client to use sensible (i.e. already normalized)
> values, and if so, does that need to be stated?
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
>  -Original Message-
>  From: iesg  On Behalf Of Alexey Melnikov
>  Sent: 13 February 2020 13:10
>  To: Christian Hopps 
>  Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The
>  IESG ; netmod@ietf.org;
>  draft-ietf-netmod-module-t...@ietf.org
>  Subject: Re: Alexey Melnikov's Discuss on
>  draft-ietf-netmod-module-tags-
>  07: (with DISCUSS)
> 
>  Hi Christian,
> 
>  On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
> > The intent in the document is to place as few restrictions on tags
> > as possible to allow for future-proofing and organic growth of use
> > both within and outside of SDOs. For standard tags we trust IANA
> > (and the human behind the process) to make the call on whether a
> > tag is already present. :)
> 
>  And the problem with that is that because there might be multiple
>  ways to encode in Unicode visually indistinguishable tags IANA
>  would end up asking IESG for help.
> 
>  So you need to at minimum specify a Unicode normalization form to
>  use. I suggest you normatively reference RFC 5198 here.
> 
> > Having worked for a company where a lot of XML string data was
> > non-ascii I find limiting to ascii to be rather restrictive.
> 
>  Best Regards,
>  Alexey
> 
> >
> > Thanks,
> > Chris.
> >
> >> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
>   wrote:
> >>
> >> Alexey Melnikov has entered the following ballot position for
> >> draft-ietf-netmod-module-tags-07: Discuss
> >>
> >> When responding, please keep the subject line intact and reply to
> >> all email addresses included in the To and CC lines. (Feel free
> >> to cut this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> >>
> >>
> >>
> >> -
> >> ---
> >> --
> >> DISCUSS:
> >> -
> >> ---
> >> --
> >>
> >> This is generally a fine document, but after checking RFC 7950
> >> syntax for strings I question why you think you need non ASCII
> tags.
> >> There are so many problems that can arise from that. For example,
> >> how would IANA be able to enforce uniqueness of Unicode tags
> >> written in different Unicode canonicalisation forms?
> >>
> >>
> >>
> >>
> >
> >
> >>>
> >>
> >

Re: [netmod] Implicit case statementa

[tom petch]

_
From: netmod  on behalf of Rob Wilton (rwilton) 

Sent: 14 February 2020 10:14
To: Kent Watsen; netmod@ietf.org
My interpretation matches the one that Martin gives in 
https://github.com/mbj4668/pyang/issues/559



I was looking at 
draft-boydseda- ipfix-psamp-bulk-data-yang-model
and see nine choice statements of which six have no case, two have a single 
case and one has multiple case.  The single case have a note to the effect that 
they may be augmented, the others have no note.  The no case do have multiple 
container or leaf statements.  It does make me curious.

Tom Petch


I.e. the short hand notation …

choice test {
  container foo {
if-feature disabled-feature;
  ...
  }
}

is equivalent to:

choice test {
  case foo {
container foo {
  if-feature disabled-feature;
...
}
  }
}

Filing an issue in YANG.Next to clarify, or further discuss, this seems helpful 
to me.

Thanks,
Rob


From: netmod  On Behalf Of Kent Watsen
Sent: 13 February 2020 14:49
To: netmod@ietf.org
Subject: [netmod] Implicit case statementa


RFC 7950 says:

   As a shorthand, the "case" statement can be omitted if the branch

   contains a single "anydata", "anyxml", "choice", "container", "leaf",

   "list", or "leaf-list" statement.  In this case, the case node still

   exists in the schema tree, and its identifier is the same as the

   identifier of the child node.

This seems clear, albeit incomplete, as inconsistencies [1] exist amongst 
`pyang`and `yanglint` (I did not test with `yangson`) in how the “if-feature” 
statement is handled, though I imagine other statements (e.g., “when”) may also 
fall into this discussion as well.

Ultimately, the question is what Errata and/or YANG-next issue should be filed. 
  I’m okay either way, so long as it’s clear and can be implemented 
consistently across tooling.

In the meanwhile, I recommend module designers avoid using the shorthand 
notation, as there are no known issues with the “longhand” notation.

[1] https://github.com/mbj4668/pyang/issues/559

Kent // contributor


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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

How about I add this to the description of "typedef tag" in the module:

   description
 "A tag is a type 'string' value that does not include carriage
  return, newline or tab characters. It SHOULD begin with a
  registered prefix; however, tags without a registered prefix
- SHOULD NOT be treated as invalid.";
+ SHOULD NOT be treated as invalid. For the purposes of comparison
+ non-ascii strings should use 'NFC' (RFC5198) normalization";
 }

Thanks,
Chris.

> On Feb 14, 2020, at 6:06 AM, Christian Hopps  wrote:
> 
> For the record this one is 3 years and counting. For a list of tags.
> 
>> On Feb 14, 2020, at 6:01 AM, Christian Hopps  wrote:
>> 
>> I was not approaching this discuss with this level of change in mind. How 
>> many years does it take to get a YANG model even one as simple as this 
>> completed?
>> 
>> Thanks,
>> Chris.
>> 
>>> On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton)  wrote:
>>> 
>>> Hi Alexey, Christian, 
>>> 
>>> Allowing Unicode but requiring normalization as per RFC 5198 for IANA 
>>> managed tags makes sense to me.
>>> 
>>> But does the server also need to normalize any configured tags?  I.e. 
>>> should the description for the tag typedef also specify that tags SHOULD be 
>>> normalized, and specify a normalization method that SHOULD be used?  Or is 
>>> the onus on the client to use sensible (i.e. already normalized) values, 
>>> and if so, does that need to be stated?
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
 -Original Message-
 From: iesg  On Behalf Of Alexey Melnikov
 Sent: 13 February 2020 13:10
 To: Christian Hopps 
 Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The IESG
 ; netmod@ietf.org; draft-ietf-netmod-module-t...@ietf.org
 Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
 07: (with DISCUSS)
 
 Hi Christian,
 
 On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
> The intent in the document is to place as few restrictions on tags as
> possible to allow for future-proofing and organic growth of use both
> within and outside of SDOs. For standard tags we trust IANA (and the
> human behind the process) to make the call on whether a tag is already
> present. :)
 
 And the problem with that is that because there might be multiple ways to
 encode in Unicode visually indistinguishable tags IANA would end up asking
 IESG for help.
 
 So you need to at minimum specify a Unicode normalization form to use. I
 suggest you normatively reference RFC 5198 here.
 
> Having worked for a company where a lot of XML string data was
> non-ascii I find limiting to ascii to be rather restrictive.
 
 Best Regards,
 Alexey
 
> 
> Thanks,
> Chris.
> 
>> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
  wrote:
>> 
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-netmod-module-tags-07: Discuss
>> 
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
>> 
>> 
>> 
>> 
>> --
>> DISCUSS:
>> 
>> --
>> 
>> This is generally a fine document, but after checking RFC 7950
>> syntax for strings I question why you think you need non ASCII tags.
>> There are so many problems that can arise from that. For example,
>> how would IANA be able to enforce uniqueness of Unicode tags written
>> in different Unicode canonicalisation forms?
>> 
>> 
>> 
>> 
> 
> 
>>> 
>> 
> 

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

For the record this one is 3 years and counting. For a list of tags.

> On Feb 14, 2020, at 6:01 AM, Christian Hopps  wrote:
> 
> I was not approaching this discuss with this level of change in mind. How 
> many years does it take to get a YANG model even one as simple as this 
> completed?
> 
> Thanks,
> Chris.
> 
>> On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton)  wrote:
>> 
>> Hi Alexey, Christian, 
>> 
>> Allowing Unicode but requiring normalization as per RFC 5198 for IANA 
>> managed tags makes sense to me.
>> 
>> But does the server also need to normalize any configured tags?  I.e. should 
>> the description for the tag typedef also specify that tags SHOULD be 
>> normalized, and specify a normalization method that SHOULD be used?  Or is 
>> the onus on the client to use sensible (i.e. already normalized) values, and 
>> if so, does that need to be stated?
>> 
>> Thanks,
>> Rob
>> 
>> 
>>> -Original Message-
>>> From: iesg  On Behalf Of Alexey Melnikov
>>> Sent: 13 February 2020 13:10
>>> To: Christian Hopps 
>>> Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The IESG
>>> ; netmod@ietf.org; draft-ietf-netmod-module-t...@ietf.org
>>> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
>>> 07: (with DISCUSS)
>>> 
>>> Hi Christian,
>>> 
>>> On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
 The intent in the document is to place as few restrictions on tags as
 possible to allow for future-proofing and organic growth of use both
 within and outside of SDOs. For standard tags we trust IANA (and the
 human behind the process) to make the call on whether a tag is already
 present. :)
>>> 
>>> And the problem with that is that because there might be multiple ways to
>>> encode in Unicode visually indistinguishable tags IANA would end up asking
>>> IESG for help.
>>> 
>>> So you need to at minimum specify a Unicode normalization form to use. I
>>> suggest you normatively reference RFC 5198 here.
>>> 
 Having worked for a company where a lot of XML string data was
 non-ascii I find limiting to ascii to be rather restrictive.
>>> 
>>> Best Regards,
>>> Alexey
>>> 
 
 Thanks,
 Chris.
 
> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
>>>  wrote:
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-netmod-module-tags-07: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> 
> 
> 
> 
> --
> DISCUSS:
> 
> --
> 
> This is generally a fine document, but after checking RFC 7950
> syntax for strings I question why you think you need non ASCII tags.
> There are so many problems that can arise from that. For example,
> how would IANA be able to enforce uniqueness of Unicode tags written
> in different Unicode canonicalisation forms?
> 
> 
> 
> 
 
 
>> 
> 

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

I was not approaching this discuss with this level of change in mind. How many 
years does it take to get a YANG model even one as simple as this completed?

Thanks,
Chris.

> On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton)  wrote:
> 
> Hi Alexey, Christian, 
> 
> Allowing Unicode but requiring normalization as per RFC 5198 for IANA managed 
> tags makes sense to me.
> 
> But does the server also need to normalize any configured tags?  I.e. should 
> the description for the tag typedef also specify that tags SHOULD be 
> normalized, and specify a normalization method that SHOULD be used?  Or is 
> the onus on the client to use sensible (i.e. already normalized) values, and 
> if so, does that need to be stated?
> 
> Thanks,
> Rob
> 
> 
>> -Original Message-
>> From: iesg  On Behalf Of Alexey Melnikov
>> Sent: 13 February 2020 13:10
>> To: Christian Hopps 
>> Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The IESG
>> ; netmod@ietf.org; draft-ietf-netmod-module-t...@ietf.org
>> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
>> 07: (with DISCUSS)
>> 
>> Hi Christian,
>> 
>> On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
>>> The intent in the document is to place as few restrictions on tags as
>>> possible to allow for future-proofing and organic growth of use both
>>> within and outside of SDOs. For standard tags we trust IANA (and the
>>> human behind the process) to make the call on whether a tag is already
>>> present. :)
>> 
>> And the problem with that is that because there might be multiple ways to
>> encode in Unicode visually indistinguishable tags IANA would end up asking
>> IESG for help.
>> 
>> So you need to at minimum specify a Unicode normalization form to use. I
>> suggest you normatively reference RFC 5198 here.
>> 
>>> Having worked for a company where a lot of XML string data was
>>> non-ascii I find limiting to ascii to be rather restrictive.
>> 
>> Best Regards,
>> Alexey
>> 
>>> 
>>> Thanks,
>>> Chris.
>>> 
 On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
>>  wrote:
 
 Alexey Melnikov has entered the following ballot position for
 draft-ietf-netmod-module-tags-07: Discuss
 
 When responding, please keep the subject line intact and reply to
 all email addresses included in the To and CC lines. (Feel free to
 cut this introductory paragraph, however.)
 
 
 Please refer to
 https://www.ietf.org/iesg/statement/discuss-criteria.html
 for more information about IESG DISCUSS and COMMENT positions.
 
 
 The document, along with other ballot positions, can be found here:
 https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
 
 
 
 
 --
 DISCUSS:
 
 --
 
 This is generally a fine document, but after checking RFC 7950
 syntax for strings I question why you think you need non ASCII tags.
 There are so many problems that can arise from that. For example,
 how would IANA be able to enforce uniqueness of Unicode tags written
 in different Unicode canonicalisation forms?
 
 
 
 
>>> 
>>> 
> 

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Juergen,

This sounds potentially useful to me, although should this be for general 
unicode strings (e.g. ones that might include spaces), or just identifiers 
(without any spaces)?.  Is this something that could/should go into 
rfc6991-bis, or at least be discussed in that context?

I would have thought that normalization would be required wherever a 
configurable unicode string is used as a list key, or leaf-list.

Thanks,
Rob


> -Original Message-
> From: iesg  On Behalf Of Schönwälder, Jürgen
> Sent: 13 February 2020 18:39
> To: Alexey Melnikov 
> Cc: netmod-cha...@ietf.org; draft-ietf-netmod-module-t...@ietf.org;
> netmod@ietf.org; Joel Jaeggli ; Christian Hopps
> ; The IESG 
> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-
> module-tags-07: (with DISCUSS)
> 
> And a longer term solution might be to define a YANG Net-Unicode string
> datatype that can be used in all situations where non-normalized strings
> may cause problems. The problem (if one agrees it is one) is likely much
> bigger than just YANG tags, there likely are many uses of YANG strings
> where normalization would be desirable.
> 
> /js
> 
> On Thu, Feb 13, 2020 at 01:10:02PM +, Alexey Melnikov wrote:
> > Hi Christian,
> >
> > On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
> > > The intent in the document is to place as few restrictions on tags
> > > as possible to allow for future-proofing and organic growth of use
> > > both within and outside of SDOs. For standard tags we trust IANA
> > > (and the human behind the process) to make the call on whether a tag
> > > is already present. :)
> >
> > And the problem with that is that because there might be multiple ways
> to encode in Unicode visually indistinguishable tags IANA would end up
> asking IESG for help.
> >
> > So you need to at minimum specify a Unicode normalization form to use. I
> suggest you normatively reference RFC 5198 here.
> >
> > > Having worked for a company where a lot of XML string data was
> > > non-ascii I find limiting to ascii to be rather restrictive.
> >
> > Best Regards,
> > Alexey
> >
> > >
> > > Thanks,
> > > Chris.
> > >
> > > > On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
>  wrote:
> > > >
> > > > Alexey Melnikov has entered the following ballot position for
> > > > draft-ietf-netmod-module-tags-07: Discuss
> > > >
> > > > When responding, please keep the subject line intact and reply to
> > > > all email addresses included in the To and CC lines. (Feel free to
> > > > cut this introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to
> > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> > > >
> > > >
> > > >
> > > > --
> > > > 
> > > > DISCUSS:
> > > > --
> > > > 
> > > >
> > > > This is generally a fine document, but after checking RFC 7950
> > > > syntax for strings I question why you think you need non ASCII
> > > > tags. There are so many problems that can arise from that. For
> > > > example, how would IANA be able to enforce uniqueness of Unicode
> > > > tags written in different Unicode canonicalisation forms?
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

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

Re: [netmod] Implicit case statementa

[Rob Wilton (rwilton)]

My interpretation matches the one that Martin gives in 
https://github.com/mbj4668/pyang/issues/559

I.e. the short hand notation …

choice test {
  container foo {
if-feature disabled-feature;
  ...
  }
}

is equivalent to:

choice test {
  case foo {
container foo {
  if-feature disabled-feature;
...
}
  }
}

Filing an issue in YANG.Next to clarify, or further discuss, this seems helpful 
to me.

Thanks,
Rob


From: netmod  On Behalf Of Kent Watsen
Sent: 13 February 2020 14:49
To: netmod@ietf.org
Subject: [netmod] Implicit case statementa


RFC 7950 says:

   As a shorthand, the "case" statement can be omitted if the branch

   contains a single "anydata", "anyxml", "choice", "container", "leaf",

   "list", or "leaf-list" statement.  In this case, the case node still

   exists in the schema tree, and its identifier is the same as the

   identifier of the child node.

This seems clear, albeit incomplete, as inconsistencies [1] exist amongst 
`pyang`and `yanglint` (I did not test with `yangson`) in how the “if-feature” 
statement is handled, though I imagine other statements (e.g., “when”) may also 
fall into this discussion as well.

Ultimately, the question is what Errata and/or YANG-next issue should be filed. 
  I’m okay either way, so long as it’s clear and can be implemented 
consistently across tooling.

In the meanwhile, I recommend module designers avoid using the shorthand 
notation, as there are no known issues with the “longhand” notation.

[1] https://github.com/mbj4668/pyang/issues/559

Kent // contributor

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