[netmod] Fwd: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00

[Carsten Bormann]

In the most recent rechartering of the CoRE working group, which works
on application protocols for the Internet of Things, the work on
management in constrained node networks (COMI) has been assigned to
CoRE.  We have promised to involve the relevant management working
groups in our proceedings, and this message is part of that.

COMI is a RESTCONF variant.  Instead of XML or JSON representation of
yang modeled data, the plan is to use the more compact (and easier to
implement on constrained devices) format CBOR.
draft-veillette-core-yang-cbor-mapping-00 is for CBOR what
draft-ietf-netmod-yang-json-10 is for JSON.

You are welcome to take part in CoRE and submit comments (and/or support
for or objections to adoption) there.  Of course, any discussion that
ensues here on the netmod mailing list will be considered by the CoRE WG
chairs as well.  (We just want to avoid massive cross-posting; hence
this separate message.)

Grüße, Carsten


 Original Message 
Subject: [core] 🔔 WG adoption of draft-veillette-core-yang-cbor-mapping-00
Date: Sun, 10 Apr 2016 14:22:27 +0200
From: Carsten Bormann 
To: c...@ietf.org WG 

In Buenos Aires, we discussed the adoption of
draft-veillette-core-yang-cbor-mapping-00 but not enough people had read
the document to go for an in-room consensus call.

This is a two-week call for adoption of
draft-veillette-core-yang-cbor-mapping-00 as a WG document of CoRE.
Specifically, if you (1) support or (2) have an objection to this
decision, please speak up on the mailing list by 2016-04-24.

Note that this work is explicitly covered by our charter, so discussions
of which WG should work on this are off-topic.

As always, adoption of a document as a WG document is not a vote on
whether we already have reached last-call state; the intention is to
work on the WG document after adoption for a while to get it ready for
last call.  If you want to combine your support/objection with technical
comments, this is certainly welcome so we can accelerate that process.

Grüße, Carsten

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


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

Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

[Carsten Bormann]

On Aug 23, 2017, at 23:20, Xufeng Liu  wrote:
> 
> 1.2.2. Avoid Unicode Characters
> 
> Unicode characters are allowed in XSD regular expressions, but are not 
> supported in the POSIX variant. If possible, the model designers SHOULD avoid 
> using Unicode characters, such as: \p{L} and \p{N}.

All ASCII characters are Unicode Characters.  
I think ASCII characters are useful and should be allowed.

(Is this maybe about Unicode categories and character classes?)

Grüße, Carsten

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

Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines

[Carsten Bormann]

I’m not going to say we have solved the underlying problem (too many flavors of 
regular expression) completely for CDDL, but in CDDL we are using PCRE with 
anchors then added:

https://tools.ietf.org/html/draft-ietf-cbor-cddl-00#section-3.8.3

(And here is the implementation:
  h[k] = Regexp.new("\\A#{k}\\z")
That should not be too hard to replicate in any language :-)

Grüße, Carsten

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

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

[Carsten Bormann]

On Sep 14, 2018, at 13:05, Robert Wilton  
wrote:
> 
> If all input files that we might ever want to fold and include in an RFC are 
> guaranteed to never contain tabs then I agree with the position that they can 
> just be rejected. 

Yep.

> But if there is some future file format that we want to fold that might 
> contain tabs, then I wonder whether it would not be more robust to look at 
> whether they could be handled in some way.

VT characters (colloquially tabs) should not be significant in any file format 
designed in the last couple of decades (i.e., they should be replaceable by 
spaces).  If they (or any other characters not representable in RFCs) are, or 
preserving byte wise identity is important, follow the lead of RFC 6716 and 
base64-encode.

Grüße, Carsten

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

Re: [netmod] regular expression flavours (again)

[Carsten Bormann]

On Jun 14, 2019, at 09:58, Ladislav Lhotka  wrote:
> 
> I agree with all this but, apparently, OpenConfig people don't care too much.
> And since they are much more agile than the IETF, our views may soon become
> irrelevant.

If this becomes our attitude, we already are irrelevant.

I have no idea why someone would go for Posix REs of all things, but if 
OpenConfig wants to do that, more power to them.  However, YANG has 
well-defined extension points, and arbitrarily changing the semantics of the 
pattern statement is not one of them.  So we have to make sure they know that 
this is not tolerable, and probably show them the way on a good way to make use 
of the existing extension points.

For CDDL, we essentially have the same problem (nobody likes W3C XSD, not even 
their REs, but there were good reasons to choose them, not the least that YANG 
also chose them).  CDDL also has an extension point that is useful here, and 
RFC 8610 Section 3.8.3.2 was added specifically to guide CDDL users to use the 
right extension point once the need comes up:

https://tools.ietf.org/html/rfc8610#section-3.8.3.2

I would expect the netmod community to write a similar section, in a separate 
I-D of its own if need be, and obtain IETF consensus on it.  Make the 
OpenConfig people aware of it (now, and when it’s done).  Github issues are a 
good way to do the latter.

Grüße, Carsten

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

Re: [netmod] regular expression flavours (again)

[Carsten Bormann]

On Jun 14, 2019, at 11:29, Rob Wilton (rwilton)  wrote:
> 
> I'm sure that someone can post an XKCD of why this is a bad idea 😉

Yeah, going ahead and standardizing another regex dialect that is subtly 
incompatible with everything else is exactly what we need.

We could even make sure that dialect is actually useful in a pattern statement 
(e.g., by making it self-anchoring).

But wait, somebody has already done that work for us!

W3C did, when they designed their XSD-types…
So we are done already!

Now the main deployability problem with W3C XSD regexes is that they added some 
functionality that is sorely missing in other dialects, such as character class 
subtraction, so it is more than an hour of work to write a converter from XSD 
regexes to you favorite flavor.  Maybe we should encourage some open source 
software in this space…

Grüße, Carsten



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

Re: [netmod] regular expression flavours (again)

[Carsten Bormann]

On Jun 14, 2019, at 12:08, Rob Wilton (rwilton)  wrote:
> 
> Or perhaps we could define a regex language that worked with normal 
> implementations without requiring any conversion.

Unlikely, as it is easy to write an regex that inadvertently triggers some 
“feature" in a specific flavor.  So you would need to list all the current and 
future idiosyncrasies of all flavors and outlaw them.  Worse, what you have 
outlawed may be *the* valid way to represent something in some other dialect, 
so the specifier needs to jump through hoops to work around that or simply 
cannot write down the regex needed.  Also, all those features that are subtly 
different between flavors (starting with ., \s, …) can’t be used.

The approach probably works for [A-Fa-f0-9]+, but becomes icky for anything 
more complicated quickly.  (And, actually, XSD regexes are very close to what 
you would come up with, anyway, except for “features” like character class 
subtraction or block escapes.)

Oh, and defining “normal implementations” is left as an exercise to the reader 
:-)

What we could do (and that would be quite useful, I think) is *document* the 
subset of XSD regexes that actually has the same meaning in PCRE2, Java8, 
JavaScript, .NET and a few more real-world regex languages after adding the 
necessary anchors in those languages.

Grüße, Carsten

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

[netmod] 🔔 CoRE Working Group Adoption call for draft-veillette-core-yang-library-05.txt

[Carsten Bormann]

RFC 8525 defines a YANG data model for information about the YANG modules, 
datastores, and datastore schemas used by a network management server.   This 
data model is based on string representations of YANG identifiers.

To be more useful in a constrained environment (CoRECONF/COMI), it is useful to 
have a YANG data model that can employ the efficiency of SIDs 
(draft-ietf-core-sid).  draft-veillette-core-yang-library-05.txt provides a 
straightforward translation of RFC 8525 to SID-based identification, with some 
legacy support removed and some other efficiencies added.  This specification 
complements the three other CoRECONF specifications draft-ietf-core-yang-cbor, 
draft-ietf-core-sid, and draft-ietf-core-comi, which we hope to ship soon.

This starts a one-week working group adoption call.
This is a formal call for adoption of this draft as a WG document of the CoRE 
WG.
If you have read the draft and support adopting it, please say so.
If you see a problem with adopting it as a WG document, please tell us.
For both, remember that WG adoption does not mean that we already have 
consensus on all the details(*), just that this is the right working document 
to address the issue (and that we should address the issue in the first place); 
you are encouraged to mention any issues that you already know.

This WGA call is CCed to the netconf and netmod working groups, as the 
expertise about YANG modules is focused there, as well as the yang-of-things 
non-WG mailing list.  Please respond to c...@ietf.org, or exceptionally to 
core-cha...@ietf.org (for off-list comments).

This formal WG adoption call runs until the end of July 18th.

Grüße, Carsten

(*) say, is the module-set index really limited to an 8-bit number?

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

Re: [netmod] definition of "fully expanded YANG"

[Carsten Bormann]

On Jul 17, 2019, at 15:18, Michael Rehder  wrote:
> 
> - translating to another schema language

Hi Michael,

If that is interesting to you:
We will spend the weekend on translating between data modeling languages during 
the IETF105 hackathon as part of the WISHI activity inside T2TRG (sorry for the 
abbrev overload).  YANG will be among the languages we are looking at.  This is 
all in the context of the data model convergence activities going on in IoT 
space, but of course the resulting model translation engines will be useful 
beyond that.

More info:

http://wishi.space/
https://github.com/t2trg/wishi/wiki/Preparation:-Hackathon-Planning#planned-hacking-topics
https://github.com/t2trg/wishi/wiki/IETF-105-Hackathon

Discussion is on the T2TRG mailing list,
https://www.ietf.org/mailman/listinfo/t2trg

Grüße, Carsten

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

Re: [netmod] 🔔 CoRE Working Group Adoption call for draft-veillette-core-yang-library-05.txt

[Carsten Bormann]

So this was a very thin response on a WG adoption call on the mailing list, but 
given the sense of the room on Tuesday, I think we can accept this as a WG 
draft.
We do have the WG last call as another formal opportunity to stop this if it 
turns out this can be done in a way that preserves full compatibility with RFC 
8525.

We are now waiting for a final WGLC-ready I-D version of yang-cbor (one 
internal author review is outstanding), and then will WGLC the whole cluster 
(yang-cbor, sid, comi, core-yang-library) in the CoRE WG with a CC to the CCs 
of this mail.
This WGLC will not go through without a number of high-quality reviews.

Grüße, Carsten


> On Jul 11, 2019, at 09:44, Carsten Bormann  wrote:
> 
> RFC 8525 defines a YANG data model for information about the YANG modules, 
> datastores, and datastore schemas used by a network management server.   This 
> data model is based on string representations of YANG identifiers.
> 
> To be more useful in a constrained environment (CoRECONF/COMI), it is useful 
> to have a YANG data model that can employ the efficiency of SIDs 
> (draft-ietf-core-sid).  draft-veillette-core-yang-library-05.txt provides a 
> straightforward translation of RFC 8525 to SID-based identification, with 
> some legacy support removed and some other efficiencies added.  This 
> specification complements the three other CoRECONF specifications 
> draft-ietf-core-yang-cbor, draft-ietf-core-sid, and draft-ietf-core-comi, 
> which we hope to ship soon.
> 
> This starts a one-week working group adoption call.
> This is a formal call for adoption of this draft as a WG document of the CoRE 
> WG.
> If you have read the draft and support adopting it, please say so.
> If you see a problem with adopting it as a WG document, please tell us.
> For both, remember that WG adoption does not mean that we already have 
> consensus on all the details(*), just that this is the right working document 
> to address the issue (and that we should address the issue in the first 
> place); you are encouraged to mention any issues that you already know.
> 
> This WGA call is CCed to the netconf and netmod working groups, as the 
> expertise about YANG modules is focused there, as well as the yang-of-things 
> non-WG mailing list.  Please respond to c...@ietf.org, or exceptionally to 
> core-cha...@ietf.org (for off-list comments).
> 
> This formal WG adoption call runs until the end of July 18th.
> 
> Grüße, Carsten
> 
> (*) say, is the module-set index really limited to an 8-bit number?
> 
> 
> 

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

[netmod] 🔔 WG Last Call of CORECONF drafts: draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01

[Carsten Bormann]

It took us a long time to get the four CORECONF drafts in sync, 
but now we are ready for WGLC.

This starts a working group last call for
— draft-ietf-core-yang-cbor-12
— draft-ietf-core-sid-11
— draft-ietf-core-comi-09
— draft-ietf-core-yang-library-01

ending on

24:00 UTC on Tuesday, March 31, 2020.

(This includes some extra time for the IETF week and for cross-WG
coordination.)

This WGLC is copied to the netmod WG mailing list; please do have a look 
at these drafts as they are slated to become a part of the greater
YANG/NETCONF/RESTCONF family.  We intend the discussion to be on the
CoRE mailing list, but if you find a fundamental issue with YANG or 
RESTCONF, feel free to discuss that on netmod instead.

Please start a new email thread for each major issue that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue.  (Minor issues such as typos can also
be sent to the authors.)

If you read the draft and think it looks fine, please send a one line 
email to the list or to the chairs letting us know that so we can get 
a feel of how broad the review has been.

(To reviewers and authors:)  If you are aware of any patent claims that
might apply to systems that implement these drafts, please review BCP 78
and BCP 79 and make any appropriate IPR declaration before the last-call
ends. If you are not sure whether you need to make a declaration or not, 
please talk to the chairs and we will help.

Grüße, Carsten

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

Re: [netmod] Agenda for Virtual NETMOD Meeting

[Carsten Bormann]

On 2020-03-31, at 00:43, Kent Watsen  wrote:
> 
> ALL:
>  - Please find below the agenda for this Thursday’s meeting

Hi Kent,

there are no indications of how much time is left on this agenda, so I don’t 
know how preposterous this is to ask:  Should we briefly talk about the 
CoRECONF WGLC that will have ended by the time of the meeting?

Grüße, Carsten

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

Re: [netmod] Agenda for Virtual NETMOD Meeting

[Carsten Bormann]

On 2020-03-31, at 01:17, Kent Watsen  wrote:
> 
> That said, I think that we have ~10 minutes for a CORECONF presentation…would 
> that be enough time?

Certainly — this will just be a heads-up and maybe a roadmap to what will come 
next.

Grüße, Carsten

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

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

[Carsten Bormann]

On 2020-03-31, at 01:47, Kent Watsen  wrote:
> 
> I thought someone said that `xml2rfc` was going to support a “markers” 
> attribute for the  element, but I don’t see that here yet: 
> https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/blob/master/draft-iab-rfc7991bis.xml#L8514.

https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.22

Grüße, Carsten

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

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

[Carsten Bormann]

Oh, and you can find examples for markers=“true” in the published RFCs

rfc8650.xml
rfc8652.xml
rfc8675.xml
rfc8676.xml
rfc8681.xml
rfc8682.xml
rfc8695.xml
rfc8696.xml
rfc8748.xml

So this is no longer just a proposal, as the below draft seems to suggest.

Grüße, Carsten

> On 2020-03-31, at 09:22, Carsten Bormann  wrote:
> 
> On 2020-03-31, at 01:47, Kent Watsen  wrote:
>> 
>> I thought someone said that `xml2rfc` was going to support a “markers” 
>> attribute for the  element, but I don’t see that here yet: 
>> https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/blob/master/draft-iab-rfc7991bis.xml#L8514.
> 
> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.22
> 
> Grüße, Carsten
> 

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

Re: [netmod] YANG definition of MAC address

[Carsten Bormann]

On 2020-04-01, at 12:20, Rob Wilton (rwilton) 
 wrote:
> 
> Another, possibly more pragmatic, suggestion would be the change both 
> definitions to accept either “:” or “-“.   I.e. the pattern statement would 
> become:  "[0-9a-fA-F]{2}([-:][0-9a-fA-F]{2}){5}"

This isn’t backwards-compatible either?
Or would that only be done for future modules?

I don’t see the gain, but I see a lot of pain.

Grüße, Carsten

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

Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12

[Carsten Bormann]

On 2020-04-07, at 21:47, Juergen Schoenwaelder 
 wrote:
> 
> For me, the question is whether this ID defines SIDs and the other ID
> details how they are managed or this ID imports the definition of SIDs
> from the other document, which also details how they are managed.
> Right now, it seem something in between, i.e., it is not clear what
> the dependencies between these specifications is.

Thank you for that feedback.

So I think we need to be a bit more radical/precise:

-YANG-CBOR should explain that SIDs are 63-bit unsigned integers and how the 
delta encoding in the CBOR map keys works.  I.e., define the concept, but not 
the number space management.

-sid does the latter.

The document that defines the media types (comi) gets to bind YANG-CBOR, for 
these media types, to the specific SID concept defined in -sid.

-YANG-CBOR can still refer to -sid as a preferred way to manage the number 
space.
But you can implement -YANG-CBOR without understanding -sid, so this is not a 
normative reference.
Any other document using -YANG-CBOR can refer to -sid as well (or, 
exceptionally, to something specific for that usage).

Grüße, Carsten

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

Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12

[Carsten Bormann]

On 2020-04-07, at 15:35, Ivaylo Petrov  wrote:
> 
> - If this work gets approved, will other specifications like
>   draft-ietf-netmod-yang-data-ext-05.txt be expected to cover CBOR
>   encoding in addition to XML and JSON? This is more a procedural
>   question.
> 
> [IP]: From our discussions, I could say that that is desirable, but not 
> something these drafts can enforce.  (Also, for drafts that already are 
> well-advanced, one would expect a companion draft on a later timeline instead 
> of the original text-based (JSON/XML) draft.)

Right.  Are we creating any special hardship for 
draft-ietf-netmod-yang-data-ext?

Grüße, Carsten

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

Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12

[Carsten Bormann]

Hi Jürgen,

> On 2020-04-08, at 08:57, Juergen Schoenwaelder 
>  wrote:
> 
> COMI defines:
> 
> application/yang-data+cbor
> application/yang-identifiers+cbor
> application/yang-instances+cbor
> 
> It seems that yang-data+cbor really is yang-data+cbor+sid

(We couldn’t use that syntax for the media type name, as +sid is not a 
structured syntax suffix, but I get the point.)

One way to build a content-type from a media-type name is to add a parameter:

application/yang-data+cbor; id=name
application/yang-data+cbor; id=sid

(In the CoAP content-format those content types would just be two different 
content-format numbers.)

But we could also encode that parameter in the media type name.
We would have to end the media type name with “+cbor”, because that is the 
structured syntax suffix that applies.

> and it seems
> there is no media type for yang-data+cbor+names (i.e., the CBOR
> encoding that uses names instead of SIDs as keys). The other two media
> types yang-identifiers+cbor and yang-instances+cbor seem to be COMI
> specific. Hence, me preference would be to define something like
> 
> application/yang-data+cbor+sid
> application/yang-data+cbor+name
> 
> in YANG-CBOR

That would put the normative reference to -sid back into YANG-CBOR.
Yes, we could do that.

Grüße, Carsten

PS.: The terminology for media types is a mess^W^W underdeveloped; see the 
expired 
https://tools.ietf.org/html/draft-bormann-core-media-content-type-format-01.txt 
for more info.

> and to leave the other two
> 
> application/yang-identifiers+cbor
> application/yang-instances+cbor
> 
> for COMI.

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

Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12

[Carsten Bormann]

On 2020-04-08, at 10:49, Carsten Bormann  wrote:
> 
> One way to build a content-type from a media-type name is to add a parameter:
> 
> application/yang-data+cbor; id=name
> application/yang-data+cbor; id=sid

Ha.

Let’s create a registry in yang-cbor for id= values (initially filled with 
id=name).
-sid can then register id=sid in that.

Look, ma, no normative references!

Grüße, Carsten

PS. If you wonder why I care about normative references: RFC 7252 got stuck for 
a year in 2013 for an ill-advised normative reference.  And have a look at 
https://www.rfc-editor.org/current_queue.php#draft-ietf-anima-grasp — 140+ 
weeks of waiting for a (totally unneeded) normative reference…

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

Re: [netmod] [core] js review of draft-ietf-core-yang-cbor-12

[Carsten Bormann]

>> Ha.
>> 
>> Let’s create a registry in yang-cbor for id= values (initially filled with 
>> id=name).
>> -sid can then register id=sid in that.
> 
> He? yang-cbor defines how to use sids as ids so I see no reason to not
> also register the id=sid in yang-cbor. I thought we settled on
> yang-cbor defines what sids are and the sid id details how they are
> assigned and how the number space is managed. This way, yang-cbor is
> the base document and the sid document has a normative reference to
> yang-cbor and comi has a normative reference to yang-cbor. Is there
> a reason that speaks against this?

Hi,

The media type could simply say “uses the concept of SIDs” or it could say 
“uses SIDs as allocated in -sid”.
I’m not sure the media type needs to say anything at all about this, but if it 
does, for completeness I think it would need to do the latter (so we can have 
other media types that get their SIDs elsewhere).
That would mean a normative reference from yang-cbor to -sid.
The registry trick turns that around.

Grüße, Carsten

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

Re: [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]

[Carsten Bormann]

Hi Rob,

> 1) Regarding the encoding of the bits datatype:
> [draft-ietf-core-yang-cbor-12, section 6.7]
> 
> The CBOR YANG encoding of the bits datatype is defined as a byte string 
> encoding of a bitfield.  However, my concern here is that YANG bit positions 
> are allowed to be up 2^32-1.
> 
> E.g. the following, pathologically bad, bits definition would seem to have a 
> very inefficient encoding in CBOR:
> 
>   typedef alarm-state {
> type bits {
>   bit unknown {
> position 40;

My knee jerk reaction would be “don’t do that then” [1].

[1]: http://catb.org/jargon/html/D/Don-t-do-that-then-.html

>   }
>   bit under-repair;
>   bit critical;
>   bit major;
>   bit minor;
>   bit warning;
>   bit indeterminate;
> }
>   }
> 
> 
> How much should we be concerned about this pathological case?  Would it be 
> reasonable for implementations to reject bitfields larger than a small set 
> size (e.g. perhaps 256 bits)?
> 
> Or, if it is supported by the language then is it reasonable that 
> implementation SHOULD support it?  In which case I think that we might need a 
> second encoding of bits that supports this pathological case.  Perhaps an 
> array of 'set' bit positions, or alternatively the union string encoding of 
> bits could be used.

This could reduce the attack vector by malicious YANG specification, but I 
think an arbitrary limit (such as the 256 mentioned above) should work, too.
(Except that arbitrary limits always come back to bite you, but that’s what we 
have software maintenance contracts for.)

> 2) Regarding the encoding of unions:
> 
> I was questioning whether the special encoding of bits type within a union 
> was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7].  Am I right 
> to presume that this is to ensure that the CBOR encoding of unions is always 
> at least as specific as XML?  If so, this seems like a reasonable design 
> choice.  

The semantics of Union types in YANG is closely married to the XML 
representation of YANG; if two branches of a union have a (non-empty) 
intersection in their XML encoding, this ambiguity is pretty much considered a 
feature.
So YANG-CBOR falls back to something that looks more like XML encoding (i.e., 
is less efficient) in unions.
The one nice thing is that a YANG spec writer can avoid the pathology by not 
using unions in this way; unfortunately, the fallback cannot rely on 
recognizing that the intersection is non-empty.

It occurs to me that this fallback could also be used for the above anomalies; 
we would need to agree on a threshold when that becomes active.

> But that leads on to these general YANG questions:
> 
> Should the value encoding of a YANG union type behave the same way regardless 
> of whether the encoding is XML/JSON/CBOR?  

Of course it “should”, while retaining reasonableness for each of the 
encodings, but that ship seems to have sailed (at least for 1.0/1.1).

> Or is it reasonable for there to be differences in the case of conflicting 
> values?  Perhaps this is already answered by RFC 7951 that can behave 
> differently from the XML encoding of unions.
> 
> Longer term, should YANG be looking for a discriminated-union type?  Or 
> perhaps it would be sufficient for tooling to flag up potentially ambiguous 
> union definitions, particularly those that may be encoding dependent.

These are all good questions.
I don’t have an answer, except that the marriage of YANG to XML semantics 
probably should get a divorce at some point.

Grüße, Carsten

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

Re: [netmod] [core] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]

[Carsten Bormann]

On 2020-05-08, at 05:27, Andy Bierman  wrote:
> 
> Why is the bit position allowed to be a uint32 in YANG? Who knows, but it has 
> to be supported.

If we think that is the way to go, I like Kio’s proposal over in the CBOR list:


We probably should arm that with some text that says (in nicer words) that this 
is an emergency representation and implementations should not invoke it for 
sane YANG models (with an operable definition of sane).

Grüße, Carsten

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

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Carsten Bormann]

On 2020-07-08, at 19:32, Juergen Schoenwaelder 
 wrote:
> 
> type string;
>   pattern "[0-9]+(\.[0-9]+)?";
> 
> means unknown precision - everybody implements what seems convenient.

It also means that there is no way to convert this text string into a number 
when using YANG-CBOR.

Grüße, Carsten

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

Re: [netmod] JSON to XML lossy conversion

[Carsten Bormann]

> In my view, if it is a bug, it is in the design of the union type in YANG - 
> there is no general way to signal the actual union member type for an 
> instance.

Right.  The ambiguity is normally not a problem for a type choice (which is 
just a union of the possible values of all types given), unless what specific 
alternative was chosen is intended to carry semantics.

> I believe it is a good thing that some encodings allow for at least partial 
> signalling.
> 
> Note that similar issues may arise even more often in CBOR, see e.g. comments 
> for section 5.12 in
> 
> https://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/

In the original YANG (XML-only), everything was represented as a text string, 
so the ambiguity was the highest we see now.  YANG-JSON and YANG-CBOR provide 
progressively more disambiguating information, so the interpretation (which 
chosen alternative) may be different from the one after converting to YANG-XML.

It gets slightly worse if the non-text type has a conversion to text that is 
not fully nailed down; I don’t know if that is a problem with the current set 
of YANG types, but any new type could of course worsen the situation.

The onus is now on the author of the YANG module to make sure that the varying 
levels of ambiguity do not cause a problem.  I would be interested to know 
whether there is any tool support for this.

Grüße, Carsten

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

Re: [netmod] JSON to XML lossy conversion

[Carsten Bormann]

On 2020-07-17, at 08:57, Michal Vaško  wrote:
> 
> I have not looked into CBOR

Please do; this is in 2nd WGLC right now.

Grüße, Carsten

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

Re: [netmod] JSON to XML lossy conversion

[Carsten Bormann]

On 2020-07-17, at 12:03, Vladimir Vassilev  
wrote:
> 
> IMO this does not solve the problem that XML can not encode all values of the 
> value space in certain awkward unions (JSON and CBOR can't do that either 
> only the constraints are alternative supersets).

The reason YANG-CBOR cannot do that is that the union can evolve, and might 
gain or lose some branches in this evolution.  (Otherwise we would have done 
something crude like numbering the branches.)

The term “union” of a set of types means that all values in all these types can 
be used.
It does not mean that any actual value identifies which of the branches it is 
in.

Apparently, this is not what YANG means with “union”.  ASN.1 has “choice”, but 
leaves the onus of all the branches looking different (usually using ASN.1 
“tags”) to the specification writer.

The text in 9.12 of 7950 seems to say there is some sequential matching that 
does identify the branch.  It nicely ties this to the specifics of an XML 
encoding, and 6.10 of 7951 tells us it’s different in JSON.  

YANG-CBOR goes the extra mile here and defines special encodings that are only 
used within unions (6.6, 6.7, 6.12), which are meant to be a bit closer to the 
text-based encodings, so the outcome of all the above is closer to XML/JSON 
than it would be with the more optimized encoding we use otherwise.  This is a 
rather ugly rucksack, but we didn’t find a better way to keep compatibility 
with random YANG specs.  If you redesign unions (e.g., turning them into 
explicit choices), please do this in a way that allows YANG-CBOR to return to 
its more optimized ways.

Grüße, Carsten

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

Re: [netmod] [Tools-discuss] reflow of YANG descriptions, and general YANG format annoyances

[Carsten Bormann]

On 2020-11-06, at 22:24, Michael Richardson  wrote:
>
> In one of my drafts, I guess some minor wording tweaks in one draft leads to
> some lines exceeding 72 characters (by one). Argh. Change from C-mode to
> text-mode. reflow.

https://www.emacswiki.org/emacs/yang-mode.el
https://www.emacswiki.org/emacs/download/yang-mode.el

Grüße, Carsten



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Tools-discuss] reflow of YANG descriptions, and general YANG format annoyances

[Carsten Bormann]

On 2020-11-07, at 01:06, Michael Richardson  wrote:
> 
> M-q reflowed a paragraph, but made it too long with 76 columns wide.

Is your .emacs setting fill-column to a non-standard value?

C-x f 69 RET

or put

// -*- fill-column: 69 -*-

into the first line of your YANG file (in a comment)
or better

(add-hook 'yang-mode-hook
  '(lambda () (set-fill-column 69)))

in your .emacs.

Grüße, Carsten

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

Re: [netmod] [Tools-discuss] reflow of YANG descriptions, and general YANG format annoyances

[Carsten Bormann]

On 2020-11-11, at 19:54, Kent Watsen  wrote:
> 
> I don’t understand the "extraction code should not be needed any more” 
> comment, but know that Shepherds and, to a lesser extent, Copy Editors, rely 
> on being able to extract the YANG modules and/or instance examples from the 
> `xml2rfc` XML files.

Once you have the XML for the RFC:
See https://tools.ietf.org/html/rfc8152#page-7
for the right way to do this.

Grüße, Carsten

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

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-02-19, at 17:55, Juergen Schoenwaelder 
 wrote:
> 
> Hi,
> 
> can I safely replace
> 
>leaf foo {
>  type int8 { range "0..100"; };
>}
> 
> with
> 
>leaf foo {
>  type uint8 { range "0..100"; };
>}
> 
> or with
> 
>leaf foo {
>  type int32 { range "0..100"; };
>}
> 
> or are these a non-backwards compatible changes?

I don’t have an answer to that, but would like to point you to the table at the 
top of page 14 in draft-ietf-core-comi-11.txt [1], which would make the first 
replacement a non-backwards compatible change in the way we build URIs from 
that.

[1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14

> Note that the value
> set is always the same, however the underlying base type changes. Did
> we ever define type equivalence?

The way unions are handled in YANG gives me the impression that as long as the 
sets of XML representations generated by the two types are the same, they are 
equivalent.

Grüße, Carsten

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

Re: [netmod] type equivalence

[Carsten Bormann]

> 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.)

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

Grüße, Carsten


> 
> /js
> 
> On Fri, Feb 19, 2021 at 06:24:02PM +0100, Carsten Bormann wrote:
>> On 2021-02-19, at 17:55, Juergen Schoenwaelder 
>>  wrote:
>>> 
>>> Hi,
>>> 
>>> can I safely replace
>>> 
>>>   leaf foo {
>>> type int8 { range "0..100"; };
>>>   }
>>> 
>>> with
>>> 
>>>   leaf foo {
>>> type uint8 { range "0..100"; };
>>>   }
>>> 
>>> or with
>>> 
>>>   leaf foo {
>>> type int32 { range "0..100"; };
>>>   }
>>> 
>>> or are these a non-backwards compatible changes?
>> 
>> I don’t have an answer to that, but would like to point you to the table at 
>> the top of page 14 in draft-ietf-core-comi-11.txt [1], which would make the 
>> first replacement a non-backwards compatible change in the way we build URIs 
>> from that.
>> 
>> [1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14
>> 
>>> Note that the value
>>> set is always the same, however the underlying base type changes. Did
>>> we ever define type equivalence?
>> 
>> The way unions are handled in YANG gives me the impression that as long as 
>> the sets of XML representations generated by the two types are the same, 
>> they are equivalent.
>> 
>> 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 <https://www.jacobs-university.de/>

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

Re: [netmod] type equivalence

[Carsten Bormann]

> On 2021-02-22, at 11:13, Martin Björklund  wrote:
> 
> 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.

Oh.  People often choose uint8 etc. with an intention to set a range.
I don’t think they know that they are setting themselves up for NBC if that 
range needs to be extended later.
So I would have expected that there is a common base type these are all derived 
from.

RFC 7950 does not use "base type" as an absolute term; it only can be used 
relative to “derived type”.
I don’t know which of the built-in types are “absolute base types” in the sense 
you would need it to define the rule.

Grüße, Carsten

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

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-02-22, at 10:24, Juergen Schoenwaelder 
 wrote:
> 
> 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.

We certainly called this out as expected collateral damage when we developed 
YANG-CBOR.

So my “deductive rule of type equivalence” is not faithfully respected by 
YANG-CBOR.  We did see a need to bow to it for unions, though.

> So yes, ideally the YANG language would have clear rules
> what YANG's type equivalences are.

For a value of “ideal” that is closer to “fundamentally necessary” :-)

Grüße, Carsten

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

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-02-22, at 14:53, Juergen Schoenwaelder 
 wrote:
> 
> Yes, "base type" is the wrong term, I think we talk about what RFC
> 7950 calls "build-in types”.

OK, so rephrasing my question:

Are all built-in types incompatible in the sense that moving from one to the 
other is NBC, or are there clusters where moving within is innocuous?

Grüße, Carsten



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

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-02-22, at 15:17, Juergen Schoenwaelder 
 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

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

Re: [netmod] draft-ietf-core-comi-11 shepherd review

[Carsten Bormann]

Please note an interesting discussion over at netmod.

Archived-At: 
<https://mailarchive.ietf.org/arch/msg/netmod/Yj7KvGvXlekWxKlu4JgqwXssIBM> and 
up.

It seems we a converging to a conclusion that means that the table at the top 
of page 14 in draft-ietf-core-comi-11.txt [1] is not wrong (it would make 
certain updates of a YANG module a non-backwards compatible change in the way 
we build URIs from that).

[1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14

That said, maybe we still want to look at why uint and int coding are so 
(unnecessarily?) different in their URL encodings.

Grüße, Carsten



> On 2021-02-04, at 05:47, Carsten Bormann  wrote:
> 
> In my shepherd review of draft-ietf-core-comi-11, I have found a few points 
> that probably need some WG action before we can submit this draft to IESG.
> (I also have submitted a PR addressing some nits, 
> https://github.com/core-wg/comi/pull/1 .)
> 
> Specifically:
> 
> # Major
> 
> *** 5: This whole section is rather disappointing.  What does this
>really do except for pointing at RFC 7959?  Is there any
>recommendation in how to work around the race condition?  The
>recommendation to use indefinite length is not solving any problem
>(does not work except in very fortuitous cases).
> 
> *** 6.2.2 How does the pagination work, then?
>This SHOULD is not actionable.
> 
> *** 7: This creates confusion between 4.01 and 4.03
> 
> # Minor
> 
> *** 2.2: While it is not clear whether there will be a SID 0, the text
> seems to imply that this would be encoded in the empty string.
> Should it rather specify a single "A”?
> 
> *** Appendix A:  Updated to reference RFC 8949 (see PR).
> Do we need a new module version after this edit?
> 
> 
> Grüße, Carsten
> 
> 

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

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-03-16, at 19:44, Juergen Schoenwaelder 
 wrote:
> 
> representation

There are several representations.  Which one is meant?

Grüße, Carsten

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

Re: [netmod] The Uselessness of webmail

[Carsten Bormann]

On 2021-03-20, at 13:15, Juergen Schoenwaelder 
 wrote:
> 
> On Sat, Mar 20, 2021 at 11:49:09AM +, tom petch wrote:
>> From: Juergen Schoenwaelder 
>> Sent: 19 March 2021 17:54
>> 
>> Subject: Re: [netmod] Use of prefixes in YANG models
>> 
>> On Fri, Mar 19, 2021 at 04:38:11PM +, tom petch wrote:
>>> 
>>> 
>>> Apologies for the useless quoting that my webmail imposes on me:-(
>>> 
>> 
>> Your webmail does not allow to edit the quoted text?
>> 
>> It has no replace function so I would have to insert a > character in front 
>> of every line by hand.  And, often, the original e-mail as displayed has a 
>> series of coloured lines down the left hand side which give some indication 
>> as to what the level of quoting is.  When composing a reply, those lines 
>> have vanished so I would have to go back to the original e-mail to see what 
>> the level of quoting is for any one paragraph and then insert the 
>> appropriate number of > characters  for each line of each paragraph.  Life 
>> is too short to iron tea towels (as a famous person once said)!
>> 
> 
> I do not know what forces you to use this webclient but there is
> always a readers vs. writers or who pays the price aspect. I do
> occasionally press 'delete' on emails requiring extra time or special
> tools to identify the contribution (and given that I am of the dying
> species reading emails in plain text, I accept that the world is
> moving on and I am just stuck in the 20th century).

+1.
Further to that, let me point out that getting emails that were mishandled like 
this makes many readers think the sender suffers of a serious disregard for 
their readers.  That may not be the signal that you want to send to a large 
professional community of peers.

Grüße, Carsten

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

Re: [netmod] YANG questions

[Carsten Bormann]

On 2021-04-02, at 18:14, Tony Li  wrote:
> 
> Thanks for your reply.  At heart, I guess I’m asking a more fundamental 
> question: is YANG intended as a data modelling language or as a data 
> structure modelling language?

I can’t answer that, but I can point out that YANG is easily extended by 
representation-level attributes:

https://datatracker.ietf.org/doc/html/draft-petrov-t2trg-youpi-01

Of course, there is also CDDL (https://www.rfc-editor.org/rfc/rfc8610.html).
Over in ASDF, we are also discussing “mapping files” for SDF as a way to bind 
the abstract data model into something more concrete.

Finally, there is a non-WG mailing list for formal description techniques, 
f...@ietf.org.

Grüße, Carsten

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

Re: [netmod] Network Modeling (Concluded WG) ???

[Carsten Bormann]

On 2021-04-26, at 08:46, Balázs Lengyel 
 wrote:
> 
> This is what I found today on the https://tools.ietf.org/wg/netmod/

As you can see at…

https://datatracker.ietf.org/wg/netmod/about/

…this is a glitch.

(Glitches like this have happened before on the tools servers; unfortunately 
I’m less optimistic about this being fixed as quickly these days as it used to 
be.)

Grüße, Carsten

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

Re: [netmod] Typedefs for bandwidth

[Carsten Bormann]

On 2021-05-13, at 19:25, Juergen Schoenwaelder 
 wrote:
> 
> The description of bandwidth-ieee-float32 says:
> 
>  The units are octets per second.

The quantity you are looking for is called “bit rate” (IEC 8:13, item 
number 13-13).
Its unit is bit/s.

A single 64-bit integer should give you both the range and the precision you 
need for all practical applications outside millibit networks (“LPWANs”).

As does an IEEE 754 binary64 float (and, probably, a binary32), which will even 
cover millibit networks.

If you prefer software floating point, you can add an exponent.
A practical base could be 1000, so an exponent of 0 is bit/s, 1 is kbit/s, 2 is 
Mbit/s, 3 is Gbit/s, 4 is Tbit/s, and so on.  -1 and -2 would be mbit/s and 
µbit/s, units maybe many of you aren’t as familiar with.

Grüße, Carsten

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

Re: [netmod] GDPR and private data

[Carsten Bormann]

On 2021-05-26, at 11:49, Balázs Lengyel 
 wrote:
> 
> Hello,
> Netconf/Restconf can transfer a lot of data. Some of this data can be 
> personal/private like end-user names, personal phone records, street 
> addresses. Is there a way to marks such data as private? I am thinking about 
> something like putting a YANG extension in the data models:
>  
> extension private-data {
> description
>   "Indicates that a leaf or leaf-list contains private data.
> argument privacy-type;
>   }
>  
> Is there any standard solution for this or any proposal ? In the world of 
> GDPR we should be thinking about this.

If the objective is to prevent processing these data at all, then maybe they 
should not be sent in the first place.

If the objective is to specify what processing of these data is permitted, then 
there probably needs to be more information that can be fed into a processor so 
it can derive its authorizations.
(Obviously there is more to privacy than personal user data, but you mentioned 
GDPR…)

Indeed, this is probably not the group to invent the shape of the authorization 
data...

Grüße, Carsten

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

Re: [netmod] [OPSAWG] please see draft-lear-opsawg-ol on licensing

[Carsten Bormann]

On 28. May 2021, at 01:51, Michael Richardson  wrote:
> 
>> *  *Issue*: Should a single owner possibly have multiple license
>> types?  (Logical or, multi-licensing.)
> 
> Uhm, so the Perl ARTISTIC license, which I think is a single license,
> is a superposition of two licenses, but it can be represented as a single
> license.  So, no.

While the Perl artistic license was a goof with a particularly high visibility, 
there are lots of other situations that call for multi-licensing.
So I’m not sure that Perl is even an good example here.

Grüße, Carsten

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

Re: [netmod] [OPSAWG] please see draft-lear-opsawg-ol on licensing

[Carsten Bormann]

On 2021-06-04, at 13:21, L Jean Camp  wrote:
> 
> Given the explicit inclusion of licensing in the data structures of SBoM I 
> think that SHOULD would be too strong in the case that MUD is extended to 
> SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuanced 
> and consistent manner. 

The current discussion is about the license under which a MUD file is offered, 
not about the licenses governing the components of an SBOM.

> SHOULD would create  a conflict with the extension unless there is an 
> alternative in the SBoM extension data.

Unless you envision an SBOM for the SBOM, I think we are clear.

(But we sure can try to be consistent with license description schemes employed 
by SBOMs.  Please tell us more about those.)

Grüße, Carsten


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

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Carsten Bormann]

On 14. Jun 2021, at 03:09, Michael Richardson  wrote:
> 
> 1) how to process yang files with -DD-MM into XML.
> 2) how to generate yang tree files.
> 3) how do I get my YANG includes downloaded, and do I put them into my repo?
> 4) how to do this with MT Makefiles?

I people could tell me what they need, we could develop a feature in 
kramdown-rfc to handle this.
(This would presumably also include support for YANG-SID files.)

Grüße, Carsten

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

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Carsten Bormann]

> One possibility is that kramdown-rfc ought to look for, and include the
> latest foo--MM-DD.yang file, when told to ::include foo.yang.
> Alternatively, it could perhaps do the -MM-DD substitution itself.

How about

{::include foo--??-??.yang}

and, if there is no such file, kramdown-rfc expands the wild card in the 
directory and uses the numerically latest file?

(There might also be a use-case for actually including all these files, so I’m 
still in thinking mode, but I think this is close.)

> for when not working with kramdown.

What? :-)

Grüße, Carsten

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

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Carsten Bormann]

I can’t help you with your dark desires to use XML, but I would propose the 
following fix for that:

— use xi:include or src= for the XML source (I forget which one works), with a 
static name
— simply generate a symlink from the most recent .yang to the static name in 
the Makefile
— use --expand for generating the submission XML.

Grüße, Carsten

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

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Carsten Bormann]

On 2021-06-14, at 18:26, Michael Richardson  wrote:
> 
>cb> How about
> 
>cb> {::include foo--??-??.yang}
> 
>cb> and, if there is no such file, kramdown-rfc expands the wild card in
>cb> the directory and uses the numerically latest file?
> 
> You'd use shell globs?

Yes.  Any need to go beyond that?

> I think it might be better to use PCRE.

Much more typing and backslash-mangling, and I don’t see the use case.

> It might be better to have this as "winclude"

So ‘loseclude’ would be including all matches?

(What does the “w” stand for?)

>cb> (There might also be a use-case for actually including all these
>cb> files, so I’m still in thinking mode, but I think this is close.)

Grüße, Carsten

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

Re: [netmod] Unknown idnits error

[Carsten Bormann]

On 2021-09-09, at 19:12, Balázs Lengyel 
 wrote:
> 
> Couldn't figure out when the document was first submitted -- there may
>  comments or warnings related to the use of a disclaimer for pre-RFC5378
>  work that could not be issued because of this.

My experience is that this message is caused by hiccups of the idnits tool in 
retrieving metadata.

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ 
certainly has no problems figuring that out.

(The question is whether you are copying from/evolving from material that was 
submitted before RFC 5378 went into force, in which case you might need a 
different ipr= attribute.  Most likely your text is not that old!  So this is a 
red herring.)

Grüße, Carsten

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

Re: [netmod] Unknown idnits error

[Carsten Bormann]

On 2021-09-09, at 23:40, Balázs Lengyel  wrote:
> 
> AFAIK I did not copy any old material. Balazs

Indeed, so you can ignore this message.

> Sadly to...@ietf.org returns with “Unknown To address”

I think tools-disc...@ietf.org was meant here.

But I don’t think new light will be generated there, except for the observation 
that the idnits backend is up for some re-integration work, so hiccups like 
this are currently not unlikely.

Grüße, Carsten


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

Re: [netmod] NULL value for uint16

[Carsten Bormann]

> On 2021-09-10, at 22:09, Jürgen Schönwälder 
>  wrote:
> 
> We are talking about RFC 9046?

Well…

SECDIR Last Call Review (of -11): Has Issues 
RTGDIR Last Call Review (of -11): Ready 
GENART Last Call Review (of -11): Ready 
RTGDIR Early Review (of -03): Has Issues 
OPSDIR Last Call Review - due: 2020-10-27

(Don’t want to point at specific people, because I’m much worse when it comes 
to finishing my reviews.)

> RFC 9046 repeats this sentence several
> times but I find it difficult to infer the intended meaning. If 0 is a
> legal value, you can't have it represent "NULL" at the same time.

Note that the document provides an information model, which yet has to be 
translated into YANG or some other data modeling language.

(Which once again points to the danger of making up information modeling 
schemes as you go.  Section 1.2 does not define NULL, but clearly, it defines 
optional properties, and one can infer that NULL is their way to talk about an 
absent optional property.)

Grüße, Carsten

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

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

[Carsten Bormann]

On 14. Sep 2021, at 19:17, Jürgen Schönwälder 
 wrote:
> 
> 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.

Any data model based on FORTRAN certainly will do.
Most other data modeling languages by now should have nullable/optional/Maybe 
types.

Going from the actual data type, uint16, to int32, just to accommodate the “not 
present” case, strikes me as a mistake.
(Which doesn’t mean that you may not want to do this in an implementation, 
after having validated the input data.)

Grüße, Carsten

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

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

[Carsten Bormann]

On 14. Sep 2021, at 21:16, Jürgen Schönwälder 
 wrote:
> 
> Carsten,
> 
> whatever you do, you will at the end need an extra bit.

Sure.  There are 65537 values, so you need at least 16.22 bits :-)

> If BBF already
> defined to use -1, so be it.

That works for me and is consistent with the information model in 9046.

What I find not so great is the side effect of going from uint16 to int32.

I don’t see a big difference between
Optional-uint16 = uint16 / -1
and
Optional-uint16 = uint16 / empty

I do not like

Optional-uint16 = int32

> The alternative is to not instantiate the leaf if there is no value
> and to accept that a client can't tell the difference between 'there
> is no value' and 'the value has been suppressed by authorization'.

Interesting.  I wasn’t aware that this cannot be distinguished in YANG.

But an “empty” would be present if it is chosen, no?

Grüße, Carsten

> 
> /js
> 
> PS: You can define a maybe-uint16 type as a union in YANG but yes
>there is no syntactic sugar to generalize this.
> 
> On Tue, Sep 14, 2021 at 08:36:12PM +0200, Carsten Bormann wrote:
>> On 14. Sep 2021, at 19:17, Jürgen Schönwälder 
>>  wrote:
>>> 
>>> 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.
>> 
>> Any data model based on FORTRAN certainly will do.
>> Most other data modeling languages by now should have 
>> nullable/optional/Maybe types.
>> 
>> Going from the actual data type, uint16, to int32, just to accommodate the 
>> “not present” case, strikes me as a mistake.
>> (Which doesn’t mean that you may not want to do this in an implementation, 
>> after having validated the input data.)
>> 
>> 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 <https://www.jacobs-university.de/>
> 
> ___
> babel mailing list
> ba...@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

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

Re: [netmod] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[Carsten Bormann]

On 2021-10-04, at 13:34, mohamed.boucad...@orange.com wrote:
> 
> bytes per second (bps),

Whoa.

I know that the IETF doesn’t usually care about precision in these things, but 
“bps” is kitchen slang for “bit/s”, so this is very confusing.

(Given that we have done the work in RFC 8428 and 8798, I’d rather see that we 
use it, instead of creating more confusion at each further step.
We do have ms and B/s in RFC 8798, because people using SenML asked for that.)

Grüße, Carsten

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

Re: [netmod] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[Carsten Bormann]

Hi Med,

> I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.

Ah.

> I'm actually for more explicit units similar to what we are using in another 
> active spec: 

As long as there is this confusion in YANG units, that is the only way that 
makes sense.
One little tweak I’d have for that spec:

> ==
>  enum bit-ps {
>value 2;
>description
>  "Bits per Second (bit/s).";
>  }
>  enum byte-ps {
>value 3;
>description
>  "Bytes per second (Byte/s).";

Maybe use the actual ISO/IEC 8 notation here: B/s.
(For those that don’t know how ISO/IEC 8 allocates “B” for byte, the legend 
“Bytes per second” is unambiguous.)

>  }
> ==
> 
> However, we are in a territory where we are trying to map as much to the 
> above service model and hence use the same labels for the units.
> 
> FWIW, RFC8466 used to have the following:
> 
> =
>  leaf pbs {
>type uint64;
>units "bps";
>description
>  "Peak Burst Size.  It is measured in bytes per
>   second.";
>  }
> =
> 
> ...which is weird.

This is really errata land, as “bps” is used as the kitchen slang for “bit/s” 
in all other cases (along with “mbps” for Mbit/s, shudder).

> This is why we don't blindly inherit that draft-ietf-opsawg-l2nm and went for 
> the following: 
> 
>  leaf pbs {
>type uint64;
>units "bytes per second";
>description
>      "Peak Burst Size.";
>  }

I think this would also benefit from “Bytes per Second (B/s)”.

Grüße, Carsten

> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Carsten Bormann 
>> Envoyé : lundi 4 octobre 2021 17:50
>> À : BOUCADAIR Mohamed INNOV/NET 
>> Cc : Francesca Palombini ; The IESG
>> ; draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-
>> cha...@ietf.org; ops...@ietf.org; netmod@ietf.org
>> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
>> l3sm-l3nm-16: (with DISCUSS and COMMENT)
>> 
>> On 2021-10-04, at 13:34, mohamed.boucad...@orange.com wrote:
>>> 
>>> bytes per second (bps),
>> 
>> Whoa.
>> 
>> I know that the IETF doesn’t usually care about precision in these things,
>> but “bps” is kitchen slang for “bit/s”, so this is very confusing.
>> 
>> (Given that we have done the work in RFC 8428 and 8798, I’d rather see
>> that we use it, instead of creating more confusion at each further step.
>> We do have ms and B/s in RFC 8798, because people using SenML asked for
>> that.)
>> 
>> Grüße, Carsten
> 
> 
> _
> 
> 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] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

[Carsten Bormann]

On 7. Oct 2021, at 06:54, Benjamin Kaduk via Datatracker  
wrote:
> 
> instance-data-set-name ['@' ( revision-date / timestamp ) ]
> ( '.xml' / '.json' )
> 
> This looks (almost?  Not sure about '@' vs. "@".) like valid ABNF.  Do
> we want to say that and reference RFC 5234 for the interpretation of the
> symbols?

JFYI, single quotes are not used in ABNF.

'.xml' / '.json’

…would need to be:

%s”.xml” / %s”.json”

…as per RFC 7405 to avoid accidentally allowing .XMl and .jsOn.

(Please excuse the smartquotes.)

Grüße, Carsten

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

Re: [netmod] Yang string with patterns cannot be assigned default values

[Carsten Bormann]

On 2021-11-03, at 18:11, Mahesh Jethanandani  wrote:
> 
> I believe if you remove the anchor characters ^ and & from the pattern 
> statement, the default value will work.

Indeed.  And the reason is that YANG patterns are not PCRE/Javascript type 
regular expressions (which always require anchors unless used for searching), 
but W3C XSD type regular expressions, which are implicitly anchored.

https://www.rfc-editor.org/rfc/rfc7950.html#section-9.4.5

Most people learn about PCRE/Javascript type regular expressions first, which 
is a source of a common misunderstanding of YANG (and, CDDL, for that matter) 
regular expressions.

Grüße, Carsten

> 
>> On Nov 3, 2021, at 12:06 PM, Olumide <50...@web.de> wrote:
>> 
[…]
>>leaf wibble {
>>type string {
>>pattern "^x$";
>>}
>>default "x";  ### NOT OKAY
>>}
[…]
>> err : Value "x" does not satisfy the constraint "^x$" (range, length, or
>> pattern). (/tmp:wibble)
>> err : Module "tmp" parsing failed.
>> 
>> 
>> Regards,
>> 
>> - Olumide
>> 
>> ___
>> 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] [Errata Verified] RFC8792 (6739)

[Carsten Bormann]

On 2021-11-20, at 03:51, Qin Wu  wrote:
> 
> inconsistency issues on source xml file introduced not by author of this RFC,

I think the underlying issue here is that verified Errata are generally 
perceived as quality feedback for the authors (visible to everyone), but in 
this case it wasn’t the authors that made the mistake.  

This is of course not solvable, as blame assignment is not one of the functions 
of the errata reporting system, but we can’t prevent that it will be perceived 
as such.

Grüße, Carsten

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

Re: [netmod] IANA registries

[Carsten Bormann]

On 2021-11-24, at 09:13, Ladislav Lhotka  wrote:
> 
> Please let me know what you think about this.

I think it is amazing.

So for each registry, you have

— manually extracted an information model and kept that in your head,
— written code that translates the information you could extract from the XML 
form of the registry into a YANG data model (note that this data model is not 
defining the registry, but it is the translated content of the registry)

This is certainly highly useful.
It also requires to essentially start from scratch for each new registry.
Shouldn’t registries come with a machine readable information model?
Shouldn’t it then be “easy” to build a generic tool that creates a YANG model 
out of the data in the registry?

Grüße, Carsten

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

Re: [netmod] IANA registries

[Carsten Bormann]

Hi Lada,



> On 2021-11-26, at 09:48, Ladislav Lhotka  wrote:
> 
> Carsten Bormann  writes:
> 
>> On 2021-11-24, at 09:13, Ladislav Lhotka  wrote:
>>> 
>>> Please let me know what you think about this.
>> 
>> I think it is amazing.
>> 
>> So for each registry, you have
>> 
>> — manually extracted an information model and kept that in your head,
> 
> Well, my old head doesn't serve me that well anymore, I was just looking into 
> the registry web page and XML. 

Indeed, so you had to apply human intelligence to produce information that is 
not available for the registry.

>> — written code that translates the information you could extract from the 
>> XML form of the registry into a YANG data model (note that this data model 
>> is not defining the registry, but it is the translated content of the 
>> registry)
> 
> Right, and IANA needn't be involved at all.

In the long run, we will need to make sure we actually capture the information 
model for registries (at the time the registries are created and updated, when 
the experts are in the house).

>> This is certainly highly useful.
>> It also requires to essentially start from scratch for each new registry.
> 
> Registry schemas are quite diverse, so a universal translation procedure 
> isn't possible.

(That’s why I said we need to capture the information model.
There is not a single one that applies to every registry.)

> Also, some decisions may be necessary on the YANG side - for example, whether 
> the registry records are to be represented as enums or identities.

Right, that is essentially the the IM ➔ DM mapping, and that needs to be done 
for each kind of DM (unless the IM already contains enough hints to carry this 
out by default).

> In most cases, writing a registry-specific translation isn't difficult and 
> amounts to copying Makefile and XSLT stylesheet templates, editing parameters 
> in the Makefile and writing a few XSLT lines.

I’m not questioning this, I just note that this is a mostly manual process that 
will be hard to maintain in the long run.

>> Shouldn’t registries come with a machine readable information model?
> 
> Actually, RELAX NG schemas are available, for example
> 
> https://www.iana.org/assignments/dns-parameters/dns-parameters.rng

These are data models for the registry page, not the underlying information 
models.

> They are useful for clarifying what to expect in the registry but don't help 
> much with automating the translation. 

(Because the IM info is missing.)

>> Shouldn’t it then be “easy” to build a generic tool that creates a YANG 
>> model out of the data in the registry?
> 
> Ideally, YANG might be able to directly "import" registries, but this is 
> quite difficult to achieve because registries are not very uniform.

… and you’d need the IM info (and any DM mapping hints).

.oOo.

I don’t want to hold up this effort by trying to do this properly, but I note 
that YANG is not the only target DM that registries would need to translate 
info.
(And you’ll note that I’m thinking like an SDF author here…)

Grüße, Carsten

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

Re: [netmod] too long lines from IANA module inclusion

[Carsten Bormann]

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?
(ducks)

Grüße, Carsten

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

Re: [netmod] too long lines from IANA module inclusion

[Carsten Bormann]

On 12. Dec 2021, at 23:11, Michael Richardson  wrote:
> 
> So if RFC8792 is the solution, then I think that I probably prefer to have
> ::include do it.

Try {::include-fold …} in 1.5.22.
The fold flag will do nothing if not needed, and RFC-8792-fold1 otherwise.
(I have only implemented ‘\’-folding.  If you really need more than 
60-something blank spaces in a line, I can add ‘\\’-folding later…)

Grüße, Carsten

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

Re: [netmod] too long lines from IANA module inclusion

[Carsten Bormann]

Now you made me curious.
No RFCs use RFC 8792 encoding yet (except for RFC 8792 itself), as you said.

I-Ds:

  "Grant Negotiation and Authorization Protocol", Justin Richer, Aaron
  Parecki, Fabien Imbault, 2021-10-25, 

(Using this for JSON text.)

  "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, Sanjay Dalal,
  2021-10-13, 

(Using this for JSON text containing a json-schema.org description.)

  "HTTP Message Signatures", Annabelle Backman, Justin Richer, Manu Sporny,
  2021-08-13, 

(Using this for examples of Signature-Input, Signature.)

  draft-ietf-netconf-crypto-types-21.txt, 
draft-ietf-netconf-http-client-server-08.txt, 
draft-ietf-netconf-https-notif-09.txt, draft-ietf-netconf-keystore-23.txt, 
draft-ietf-netconf-netconf-client-server-24.txt, 
draft-ietf-netconf-notification-capabilities-21.txt, 
draft-ietf-netconf-restconf-client-server-24.txt, 
draft-ietf-netconf-ssh-client-server-26.txt, 
draft-ietf-netconf-tls-client-server-26.txt, 
draft-ietf-netconf-trust-anchors-16.txt, 
draft-ietf-netmod-yang-instance-file-format-21.txt)

(Tons of netconf drafts, apparently using this mainly for XML examples — I 
didn’t check all of those.)

  "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch
  Provisioning (SZTP) Bootstrapping Request", Kent Watsen, Russ Housley, Sean
  Turner, 2021-12-03, 

(As mentioned, for a YANG tree, HTTP requests, JSON text.)

  "A Layer 2 VPN Network YANG Model", samier barguil, Oscar de Dios, Mohamed
  Boucadair, Luis Munoz, 2021-11-22, 

(YANG JSON instances, again.)

  "A Layer 3 VPN Network YANG Model", samier barguil, Oscar de Dios, Mohamed
  Boucadair, Luis Munoz, Alejandro Aguado, 2021-10-08,
  

(Overly long HTTP requests.)

  "Structured Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, Neil
  Cook, Mohamed Boucadair, 2021-10-13,
  

(JSON.)

  "List Pagination for YANG-driven Protocols", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  

  "NETCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  

  "RESTCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  

(HTTP requests, some XML.)

And, crucially for an implementer, no ‘\\’ wrapping, except (unnecessarily!) in 
draft-ietf-netconf-ssh-client-server-21.txt (apparently fixed in later 
versions.)

The form

   === NOTE: '\' line wrapping per RFC 8792 

(15 equals signs left, 16 equals signs right) seems to be the favorite lead-in; 
however, draft-wing-dnsop-structured-dns-error-page-01.txt had a version 
indented by 2 characters that has 14+15 accordingly.  About 5 % 10+11, 
apparently before RFC 8792 was published so there was less space.)

Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn’t have any “===“ 
decoration, though.  (Why the heck was this left open as a choice for the 
author?  I like “%%%” decoration instead, should I use that as a personal 
fashion statement?)

Grüße, Carsten

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

Re: [netmod] too long lines from IANA module inclusion

[Carsten Bormann]

On 2021-12-17, at 17:31, Kent Watsen  wrote:
> 
>> Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn’t have any 
>> “===“ decoration, though.  (Why the heck was this left open as a choice for 
>> the author?  I like “%%%” decoration instead, should I use that as a 
>> personal fashion statement?)
> 
> Because sometimes it is desirable for the bracketing to match the native file 
> commenting syntax (e.g., “#“ for shell/Python, “//“ for C++, “;” for ABNF, 
> etc.)

But those tools never see that header.
(Or are there examples where you can safely feed a folded block to a tool?)

Grüße, Carsten

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

Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

[Carsten Bormann]

On 2021-12-18, at 09:20, Eliot Lear  wrote:
> 
> Still it seems like the right thing to do, in order to fall into line with 
> the target language spec.

But that’s not what YANG was designed for.
YANG is a data modeling language, which incidentally has a couple of 
representation formats (YANG-XML, YANG-JSON, YANG-CBOR).
There is no intention for the YANG generic data model (the set of all data 
models YANG can express) to cover the generic data model of the representation 
format.

While RFC 8791 (and before it RFC 8040) extended YANG to be able to describe 
data in flight, there is no intention that YANG can be used to describe the 
entire expressibility of the representation format.  We have Relax-NG, CDDL, 
and a few other modeling approaches if we need that.

Grüße, Carsten

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

Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

[Carsten Bormann]

On 2021-12-18, at 14:35, Christian Hopps  wrote:
> 
> This isn't about the YANG specification in general, or making YANG conform to 
> any particular language. It's just about the a choice in the specification 
> for the encoding of YANG in a particular format (JSON).

I understand the objective to have a good representation for YANG data.

For instance, in YANG-CBOR, a YANG empty is represented as a CBOR null (0xf6, 
in case you need to visualize the bits); there is no expectation that this will 
be difficult to handle by CBOR implementations.

However, there is nothing wrong with representing empty with the array »[null]« 
in YANG-JSON.  It is just more complex, and apparently unnecessarily so.
Whether removing this complexity to save two characters is worth doing an 
incompatible upgrade to the YANG-JSON representation format can be debated.
I’d say: emphatically no.

The other motivation that came up in this thread is that it is natural to have 
null as a value in JSON and YANG cannot describe such formats via YANG-JSON.  
This was what I was reacting to, but, as you say, that wasn’t your question.

Grüße, Carsten

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

Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

[Carsten Bormann]

On 18. Dec 2021, at 19:04, Ladislav Lhotka  wrote:
> 
>'foo: null'?  Doesn't that make testing for empty values a major
>pain?  'if (foo)' would not work.

Same with »false«, which 7951 is not escaping into an array.
This argument simply doesn’t hold water.
As was mentioned, you would check »”foo” in o«, which works for null, false, 
and all other values that may happen to be falsy(*) in the platform.

>JSON evolved from Javascript, so it must keep the javascript
>meanings for these keywords.

That is a common misconception that must be stamped out, but we have 
j...@ietf.org for that discussion.

> It is indeed true that tests in JavaScript cannot really distinguish between 
> a non-existent member and member with the value of 'null'. I remember I 
> wasn't happy about this change but I thought it wasn't a big deal.

As mentioned, they can.
And, yes, this little unnecessary complexity is not a big deal even if it is 
based on mistaken beliefs; every non-trivial protocol has some unburied zombies 
in the basement.

Grüße, Carsten

(*) falsy: converted to false when implicitly coerced to a Boolean (Ant.: 
truthy)

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

Re: [netmod] YANG 'when' with absolute path

[Carsten Bormann]

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

?

Grüße, Carsten

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

Re: [netmod] YANG 'when' with absolute path

[Carsten Bormann]

On 2021-12-31, at 17:32, Ladislav Lhotka  wrote:
> 
> It means slightly more work for an XPath processor but is IMO considerably 
> more readable and less error-prone.

The original phrasing with ../../../../../ etc. is in conflict with the 
powerful maxim “let the computer do the counting” (remember 12HHello World in 
FORTRAN?).

We had the same “relative-path” disease with the original use of (non-standard) 
relative JSON pointers in SDF.  Going to (the standard) absolute ones helped a 
lot, but actually finding the right node would be even better — can’t be done 
in RFC 6901 JSON Pointers though.

So my brain was just activated to this anti-pattern, and since XPath is 
infinitely more powerful than JSON Pointer, I just wanted to know how to avoid 
it.  Thank you!

Grüße, Carsten

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

[netmod] RFC 6991 and ২০২২-০১-০৩T২১:৪০:০০

[Carsten Bormann]

Does my little example of the approximate current time (২০২২-০১-০৩T২১:৪০:০০) 
match RFC 6991 date-and-time?

I think it does, but I’m also pretty sure that wasn’t intended.
There are a few more cases of \d in RFC 6991, where the equivalent definitely 
wouldn’t work.

Happy new year ২০২২ (*), anyway :-)

Grüße, Carsten

(*) (I know we are in ১৪২৮ in at least some of the calendars that would use 
this writing system…)

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

Re: [netmod] RFC 6991 and ২০২২-০১-০৩T২১:৪০:০০

[Carsten Bormann]

Hi Jürgen,

On 2022-01-03, at 22:25, Jürgen Schönwälder 
 wrote:
> 
> On Mon, Jan 03, 2022 at 10:05:15PM +0100, Carsten Bormann wrote:
>> Does my little example of the approximate current time (২০২২-০১-০৩T২১:৪০:০০) 
>> match RFC 6991 date-and-time?
>> 
>> I think it does, but I’m also pretty sure that wasn’t intended.
>> There are a few more cases of \d in RFC 6991, where the equivalent 
>> definitely wouldn’t work.
>> 
> 
> The example may pass the pattern but it likely does not statisfy the
> additional requirements spelled out in the description statement.

I understand that, but there are two observations:

(1) as noted, the pattern is too permissive (unnecessarily so, as \d can simply 
be replaced with [0-9] to match Section 5.6 of RFC 3339).
(2) but you cannot ignore the pattern, as it also is more restrictive than the 
description indicates (it requires capital T and, if present, capital Z — see 
the note in Section 5.6 on how such a restriction of the case-insensitive RFC 
3339 format is allowed, but then the assertion "The profile is defined by the 
date-time production in Section 5.6 of RFC 3339.” in the YANG description 
statement is, err, not the whole story).

(Background: We are wrangling with regexps in JSONPATH and date/time formats in 
SEDATE, and I’d like to make sure what we do there fits with what we can learn 
from YANG.)

Grüße, Carsten

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

Re: [netmod] RFC 6991 and ২০২২-০১-০৩T২১:৪০:০০

[Carsten Bormann]

> That said, perhaps it is a good idea to replace the remaining uses of
> \d in ietf-yang-types where we really mean [0-9] to clearly exclude
> any other characters representing digits.

Probably.

I keep a little unscientific list of regexp uses in RFCs, and the YANG RFCs are 
unusual in actually using \d (and clearly not expecting the actual semantics of 
\d to be used), so this is how I noticed the issue.

> If we would have allowed t and z for YANG's date-and-time, then we may
> have created another incompatibility with the XSD dateTime definition,
> which I think only allows T and Z. Given that we are in 2022, it may
> be reasonably safe to assume that systems can create or process the
> two capital letters T and Z. ;-)

I’m not criticizing the decision to go for upper-case here (case-insensitivity 
is a remnant from the 1960s/1970s that really needs to be expunged).

I was just commenting how first referencing the unmodified RFC 3339 rules 
(which pointlessly by default is case-insensitive here) in the description 
statement and then silently changing the allowable characters via the pattern 
statement is probably not the best way the pattern and description statements 
can interact.

I need to read 6991-bis...

Grüße, Carsten

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

Re: [netmod] Camel Case versus hyphenation

[Carsten Bormann]

On 2022-01-04, at 12:26, Jürgen Schönwälder 
 wrote:
> 
> tells a human operator over the phone

Indeed, a consistent convention wins.

The question was whether the consistency should be on the YANG side or on the 
side of each specific application modeled in YANG, and I think operationally we 
have a strong argument for the former (the poor applications people need to 
learn YANG anyway and they can learn that convention along the way).

By the way, hyphenation is something different (dividing a word to obtain a 
line break and inserting a hyphen); the word you are looking for is kebab-case 
[1].

Grüße, Carsten

[1]: https://en.wiktionary.org/wiki/kebab_case
(To maximize confusion, this link actually uses snake_case [2], duuh…)
[2]: https://en.wiktionary.org/wiki/snake_case

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

Re: [netmod] Camel Case versus hyphenation

[Carsten Bormann]

On 2022-01-04, at 18:10, tom petch  wrote:
> 
> 
> The OED defined hyphenation as meaning 'contains a hyphen' so I shall stay 
> with that pro tem.

Which is a nice example for how general purpose dictionaries don’t always 
capture the full meaning of technical terms very well.
(Wikipedia is better here: https://en.wikipedia.org/wiki/Hyphenation redirects 
to https://en.wikipedia.org/wiki/Syllabification which explains:
“This article is about the division of words to break lines”.)

For many of us, a hyphenated “hyphenation" is “hy-phe-na-tion”, which is not 
what is meant here.  

(And, to add injury to insult, there actually is no hyphen in a kebab-case 
term, as the words are connected by a Unicode hyphen-minus U+002D, not a 
Unicode hyphen U+2010.  So you’d need to say hyphen-minus-ated...)

> I prefer the absence of hyphens so I do not have to spell out their presence 
> over the phone to the operator who is trying to restore their crashed 
> payments system.  

Soyoupreferforwordstoruninlikethis?
No, you need those word breaks, and “hyphen” is easy to say on the phone, or 
actually given that ASCII does not really have hyphens anyway, you can say 
“dash”, which is one syllable shorter.

> Case insensitivity helps in that regard as well.

Absence of frivolous case variation helps even more.

But all this is irrelevant; the YANG ecosystem’s preference for kebab-case is 
well-established; I just was pointing out the common term to use for 
identifying that convention.

Grüße, Carsten

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

Re: [netmod] References Re: RFC 6991

[Carsten Bormann]

On 2022-01-10, at 21:49, Jürgen Schönwälder 
 wrote:
> 
> RFC 7991:

7991 The "xml2rfc" Version 3 Vocabulary. P. Hoffman. December 2016.
 (Format: TXT, HTML) (Obsoletes RFC7749) (Status: INFORMATIONAL)
 (DOI: 10.17487/RFC7991) 

I knew this is all connected, but I think you meant RFC 7950.

Anyway, a YANG module that makes use of the new (1.1) freedom to name something 
xmlfoo strikes me as somewhat malicious.  But of course the knowledge that you 
weren’t supposed to do that may wane over time…  Dropping the second pattern 
makes it easy for referencing modules to import that change, consciously or 
accidentally.  How bad will the accidents be?  There needs to be a YANG module 
that uses the identifier in the first place.

Grüße, Carsten

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

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

[Carsten Bormann]

On 3. Feb 2022, at 18:43, Mahesh Jethanandani  wrote:
> 
>> [mj] That is correct. We have been beaten up enough number of times for not 
>> using the prefix defined by the YANG module. Is the suggestion to state that 
>> in the draft?


RFC 7950, Section 7.1.4:

   When used inside the "import" statement, the "prefix" statement
   defines the prefix to be used when accessing definitions inside the
   imported module.  When a reference to an identifier from the imported
   module is used, the prefix string for the imported module followed by
   a colon (":") and the identifier is used, e.g., "if:ifIndex".  To
   improve readability of YANG modules, the prefix defined by a module
   SHOULD be used when the module is imported, unless there is a
   conflict.  If there is a conflict, i.e., two different modules that
   both have defined the same prefix are imported, at least one of them
   MUST be imported with a different prefix.

Is there a reason to violate the SHOULD?

Grüße, Carsten

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

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

[Carsten Bormann]

On 2022-02-10, at 13:22, tom petch  wrote:
> 
> If the comments in question had been made at the time of RFC7950 they would 
> have been most insightful; now they are not IMHO.

The comment is insightful, it is just not about this document.
I think we need to be able to sort comments into the right bins.
(And we need to formalize “Hold for document update” bins for non-errata.)

(I’m also still not sure I’ve got an answer to my question about using 
inconsistent prefixes between YANG and the XML example.  What is being 
demonstrated here?)

Grüße, Carsten

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

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

[Carsten Bormann]

>> (I’m also still not sure I’ve got an answer to my question about using 
>> inconsistent prefixes between YANG and the XML example.  What is being 
>> demonstrated here?)
>> 
> 
> If you are referring to
> " Is there a reason to violate the SHOULD?"

I’m referring to the question I was trying to ask when I said this :-)

> I did not see that as related to the thread but thought it was answered 
> anyway by Juergen.  As he said, the SHOULD gets violated when prefix clash 
> which, in the absence of a registry, a namespace, for prefix is possible.

Yes, and thanks to him for answering my question as a general question.

I was answering to a throwaway note that the authors got flak when their XML 
did not use the defined prefix.  My question was: why do that, then?  Maybe 
that was not understood because “ianaift” actually *is* the prefix preferred in 
the YANG module, so my question doesn’t make sense.  (I’m not sure what the 
throwaway referred to.)

Grüße, Carsten

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

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

[Carsten Bormann]

Let me try to restate in more general terms the technical side of what Tom said:

On 2022-02-12, at 13:54, tom petch  wrote:
> 
> MUST be the same as the namespace prefix (i.e., 'nsfmi' in
>   the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
>   monitoring. 

This is confusing language.  I don’t know what “the namespace prefix for X” is.
(Of course, I know what xmlns attributes are; are these meant here?  Or the 
prefix declaration in the YANG that imports the module with this name?  Or the 
prefix declaration in the YANG of the module with this name?)

More importantly, this is a specific instance of an antipattern that needs to 
be stamped out:
Rephrasing requirements of a base normative reference (here: RFC 7950) in a 
derived specification.
This incurs a strong danger (which is NOT theoretical):

— the rephrasing may be inaccurate and thus create a fork of the actually 
intended general requirement of the base standard.
— the rephrasing may be misunderstood as a requirement specific to the derived 
standard, so implementers feel compelled to do something special for the 
derived standard, again creating a fork on the implementation side.

I would like to ask that we never ever do that, except possibly with a strong 
indication that the restatement is just a reminder rephrasing the normative 
requirements of the base document.  Such a restatement needs to be clearly 
labeled as an informational note and needs to reference the specific normative 
statement in the base document that it is an instance of.

More specifically, an RFC 2119 keyword is misplaced here — this is not a new 
normative requirement, just a factual statement about what that base standard 
already requires.

Grüße, Carsten

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

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

[Carsten Bormann]

On 21. Feb 2022, at 11:44, Jan Kundrát  wrote:
> 
> Sorted

➔ ordered

Interesting discussion!

Grüße, Carsten

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

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

[Carsten Bormann]

> On 21. Feb 2022, at 11:44, Jan Kundrát  wrote:
> 
>   "p": {["0.003", "0.001", "0.001", "0.24", "0.37”]}

I read 7951 as saying that the value part of the anydata pair is a JSON object 
(map) with YANG names as keys.

"p": {“ietf-blub:blub”: ["0.003", "0.001", "0.001", "0.24", "0.37"]}

I have no idea how the YANG model hints at what keys you should be using there.

Grüße, Carsten

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

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

[Carsten Bormann]

(Removing RFC-editor from the list:)

On 2022-03-01, at 16:42, SADOVNIKOV, ALEXEI  wrote:
> 
> I continue to doubt if this optimization continues to have value in presence 
> of JSON processing, where such optimization is not possible.   I am expecting 
> an implementation these days to implement both XML and JSON, and then it 
> either implements something which can deal with unordered for both, or have 
> two different implementations one of which is optimized.

This is very interesting also for YANG-CBOR.  We modeled our representation 
after that used in YANG-JSON, but of course CBOR can be much more efficient (in 
particular in conjunction with YANG-SIDs).
If there is a performance problem with the YANG-JSON approach that we could 
work around on the CBOR side, I would certainly like to hear about it!

Grüße, Carsten

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

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

[Carsten Bormann]

On 22. Mar 2022, at 21:04, Jürgen Schönwälder 
 wrote:
> 
> updates are done in a way to maintain backwards compatibility

(Forward compatibility?
Backward compatibility = old data, new system.
Forward compatibility = new data, old system.
Just saying…)

Grüße, Carsten

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

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[Carsten Bormann]

On 2022-05-25, at 10:51, William Lupton  wrote:
> 
>   "Coalesced revision history entries for 2018-06-28.”;

Wonderful example.  I’m wondering whether the next version of CDDL should 
simply accept typographic quotes in place of the typewriter quote…  (and, as 
the example demonstrates, any weird mix of them.)

Grüße, Carsten

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

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[Carsten Bormann]

On 2022-05-25, at 11:05, William Lupton  wrote:
> 
> I think this partly depends on the general attitude to non-ASCII characters, 
> e.g., are accented words tolerated, encouraged, frowned upon or forbidden?

Long discussion, including CVEs like:

https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html

> Are programming languages in general tolerant of smart quotes for defining 
> strings (I don't know but I suspect not)?

Certainly not.  This would be a major innovation, trading convenience for 
correctness.  It also wouldn’t be backwards compatible:

  description "like “foo”, this doesn’t create a “bar”.";

(I had to be careful typing this, I hope I didn’t mess up.)

> If not then I don't think that YANG should be either. But the tools could 
> generate better error messages if they are inadvertently used!

Yes. This is probably a bit harder than one might think, in the presence of 
examples like the above.

Grüße, Carsten

> On Wed, 25 May 2022 at 10:01, Carsten Bormann  wrote:
> On 2022-05-25, at 10:51, William Lupton  wrote:
> > 
> >   "Coalesced revision history entries for 2018-06-28.”;
> 
> Wonderful example.  I’m wondering whether the next version of CDDL should 
> simply accept typographic quotes in place of the typewriter quote…  (and, as 
> the example demonstrates, any weird mix of them.)
> 
> Grüße, Carsten
> 

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

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

[Carsten Bormann]

On 2022-06-27, at 16:08, Jürgen Schönwälder 
 wrote:
> 
> Petterns are nice to have to detect wrong values "early" but once
> patterns become very complex, the likelihood increases that they are
> wrong.

We (draft-ietf-core-problem-details) had a grammar mirroring RFC 5646 first but 
then came up with (CDDL):

tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"

based on input that the XML documents have been doing the same for a couple of 
decades already.

JFYI.

Grüße, Carsten

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

Re: [netmod] CBOR tags for Common YANG Data Types (RFC6991/bis)

[Carsten Bormann]

On 31. Jul 2022, at 02:12, Andy Bierman  wrote:
> 
> leaf foo {
> type inet:ipv6-address;
> ext:cbor-type cbor:bin-ipv6-address;
> }

This looks like the right thing to do.
But it touches many moving parts, and I’m wondering whether we cannot do 
something with a more localized footprint.

This is all about the representation; the data model doesn’t actually change 
(*).
We don’t need to change the model to go from XML to JSON, why should we need to 
do that here?

Maybe this could be done via a concept that looks more like a SID file.
It would need to be visible in a yang-library-like model.

Grüße, Carsten


(*) Well, maybe it does: E.g., when using Tag 1 for a date/time, there is no 
way to represent a numerical offset.
That is generally not needed, so the conversion would work in the majority of 
cases.
If a numerical offset needs to be expressed, the text-based form could be used.

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

Re: [netmod] https? - Regex

[Carsten Bormann]

On 7. Sep 2022, at 12:28, tom petch  wrote:
> 
> I do note that in 
> [3]   piece   ::=   atom quantifier?
> the meaning of the question mark is different else it would allow
> [3]   piece   ::=   atom quantifie
> Sigh.

Indeed.  XSD regexes are not defined via regexes, but via an EBNF that W3C 
chose for this [1].

Grüße, Carsten

[1]: https://www.w3.org/TR/xml/#sec-notation

Note that this form of EBNF includes a regexp-like form of character class 
notation, but does not mirror the dense syntax of regexps overall.

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

Re: [netmod] [Anima] mcr's YANG question raised during the ANIMA WG session

[Carsten Bormann]

On 2022-11-24, at 17:02, Jan Lindblad (jlindbla) 
 wrote:
> 
> If any of this causes problems with SID generation, I'm afraid that's not my 
> territory. :-)

I think it would be good if there were sx:structure support in PYANG that we 
can use.
(Which still may not be your territory…)

Grüße, Carsten

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

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

[Carsten Bormann]

On 2023-01-12, at 13:38, Italo Busi  
wrote:
> 
> Moreover, I am not sure whether restricting the strings would solve the out 
> of memory: what happens if a huge YANG list is configured?

SGML had an elaborate system for placing arbitrary restrictions on some 
“capacity” parameters.  People who write the SGML documents never found a good 
way to nail down these numbers.  The limits either got in the way, way too 
early, or they didn’t actually help.

A significant innovation in the definition of XML was to get rid of all these 
“capacity” arbitrary restrictions.

Please don’t commit a major regression here.

Grüße, Carsten


BTW, random example: There was an arbitrary restriction on some security data 
type recently that limited that to 64 bytes (*).  Turns out an example in the 
draft already used 66 bytes.  People discussed upgrading the limit so this 
could be accommodated, until somebody mentioned they’d need 4000 or something.  
All the arbitrary limits you come up with during standardization are 
essentially instances of “proof by lack of imagination”…

(*) I could look up which, but this would delay sending this message.

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

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

[Carsten Bormann]

On 2023-01-12, at 13:47, Carsten Bormann  wrote:
> 
> (*) I could look up which, but this would delay sending this message.

https://www.rfc-editor.org/errata/eid7251

Epic discussion thread starts at
Archived-At: 
<https://mailarchive.ietf.org/arch/msg/cfrg/xEo-qO__Qe2jc6JCCy0eAZC6oM0>

And a +1 to what Jürgen said.

Grüße, Carsten

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

[netmod] Strictness of Base64classic in RFC 7950/7951

[Carsten Bormann]

Quick question (can’t find in the archives whether that was discussed):

I this YANG-JSON valid for a `binary`?

"base64encodedvalue==“

Section 6.6 of RFC 7951 points to Section 9.8 of RFC 7950, which points to 
Section 4 of RFC 4648.  That says:

   When fewer than 24 input
   bits are available in an input group, bits with value zero are added
   (on the right) to form an integral number of 6-bit groups.

I read that as saying the `binary` should be encoded as:

"base64encodedvaluQ==“

(Q = 01, e = 00, only the first two bits are used after “u” has 
supplied six of eight for the last byte, so the rest must be zero.)

Grüße, Carsten

...

For those who don’t breathe base64, here’s the problem:

a = Base64.decode64("base64encodedvalue==").hexs
=> "6d ab 1e eb 87 a7 72 87 5e 76 f6 a5 b9”

But some bits were *not* zero in the discarded part, so we get:

Base64.encode64(a.xeh) => "base64encodedvaluQ==\n”

Of course, a strict base64classic decoder is not going to accept 
"base64encodedvalue==“ in the first place, because the sentence cited above is 
violated.

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

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Carsten Bormann]

On 2023-02-27, at 12:57, Ladislav Lhotka  wrote:
> 
>> I this YANG-JSON valid for a `binary`?
>> 
>> "base64encodedvalue==“
> 
> Strictly speaking it isn't because it's out of range of the base64 encoding 
> function.

Right.

> I think though it is OK to be liberal in what we accept here because 
> "base64encodedvaluQ==" is clearly the canonical value in this case, so there 
> is no ambiguity e.g. regarding string equality.

Well, this is the essence of my question (not sure about the part about string 
equality, though).

draft-iab-protocol-maintenance [0] takes the position that the Postel 
principle, while historically a good way to implement protocols and get 
interoperability going, is not to be misunderstood as a mandate for the 
evolution of protocol ecosystems — protocols are free to be strict, lest they 
turn into soup (“Protocol Decay” [1]: “...a chain reaction that can create 
interoperability problems over time”).

I’d like to know whether, on issues like this, YANG is more on the strict side 
or on the soup side — what do YANG implementations actually do, and what do we 
want YANG implementations to do?  Is there an implicit “MAY send invalid last 
character”, which is no different from a “MUST accept invalid last character”?

Background: I’m proposing to add a few control operators to CDDL, including for 
handling base64classic [2], and in my PoC implementation was of course 
implementing a strict interpretation, only to be struck by the first example in 
an RFC I was pointed to.

Grüße, Carsten

[0]: 
https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
[1]: 
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-12.html#name-harmful-consequences-of-tol

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

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Carsten Bormann]

On 2023-02-27, at 15:04, Ladislav Lhotka  wrote:
> 
> Unlike non-alphabet characters, RFC 4648 doesn't say that such a character in 
> encoded data is invalid.

Not explicitly, but it also gives you an algorithm for arriving at the encoded 
value that never can result in the characters that I consider invalid [1]:

   When fewer than 24 input
   bits are available in an input group, bits with value zero are added
   (on the right) to form an integral number of 6-bit groups.  

Note the explicit “with value zero”.

> FWIW, my implementation (Yangson) uses Python standard library base64 that 
> accepts it without complaints even with validation turned on:
> 
> >>> import base64
> >>> base64.b64decode("ue==", validate=True)
> b'\xb9'
> 
> So I assume the authors consider this input valid, and I saw no reason to be 
> concerned about it.

Thank you — that was the kind of input I was looking for.

Now what do other implementations do?

Grüße, Carsten

[1]: https://www.rfc-editor.org/rfc/rfc4648#page-6

And the missing [2] from my previous message:
[2]: 
https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Carsten Bormann]

On 2023-02-27, at 20:59, Kent Watsen  wrote:
> 
> This was discussed in late 2021.   I switched from:
> 
>   base64encodedvalue==
> 
> to:
> 
>   BASE64VALUE=
> 
> in all my drafts then.  Which document are you looking at?

RFC 8366 (from 2018).

Do you have a pointer to the discussion?

Was there, at the same time, any conclusion with respect to my question (strict 
or soup)?

Grüße, Carsten

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

Re: [netmod] Strictness of Base64classic in RFC 7950/7951

[Carsten Bormann]

On 2023-03-05, at 18:37, Robert Varga  wrote:
> 
>> 
>> Now what do other implementations do?
> 
> OpenDaylight uses plain Java, which in turn boils down to:
> 
>> |  Welcome to JShell -- Version 17.0.6
>> |  For an introduction type: /help intro
>> jshell> java.util.Base64.getDecoder().decode("ue==")
>> $1 ==> byte[1] { -71 }

Thank you!

It seems we should be planning for accepting invalid codes when that is desired.

Grüße, Carsten

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

Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15

[Carsten Bormann]

On 24. Mar 2023, at 22:29, Jürgen Schönwälder 
 wrote:
> 
> using '"(%.+)"' in the IP address types may be the most liberal answer

Pedantically speaking, no.

/./ does not include all of ASCII, which is not liberal enough if you want to 
preserve the newlines in your interface names that are putatively allowed by 
RFC 4007 (I can’t find that in there).
It does include all of Unicode that is not ASCII, which is too liberal.
IIRC, it also includes NUL (misspelled as null in RFC 4007).
Then, there is the opaque "However, the strings must not conflict with the 
delimiter
character.” in RFC 4007 which I’m not going to try to understand.

(Just asking that when the important decision has been made, some more energy 
is used to properly represent it in YANG.)

Grüße, Carsten

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

Re: [netmod] ICS file for the weekly versioning meeting

[Carsten Bormann]

On 2023-03-31, at 10:33, Joe Clarke (jclarke) 
 wrote:
> 
> Grrr, this is at 9:00 am EDT on Tuesdays.

(And the .ics is correct, just the below interpretation isn’t.)

Grüße, Carsten

> From: netmod  on behalf of Joe Clarke (jclarke) 
> 
> Date: Thursday, March 30, 2023 at 21:27
> To: netmod@ietf.org 
> Subject: [netmod] ICS file for the weekly versioning meeting
> 
> Carsten opined it might be nice to have an ICS file for our weekly versioning 
> call.  Attached is the ICS that I have been using.  Our next meeting is 
> Tuesday April 4 at 10:00 am EDT.
> 

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

Re: [netmod] ietf-yang-types:date-and-time canonical value

[Carsten Bormann]

On 2023-04-24, at 14:20, Michal Vasko  wrote:
> 
> canonical

Hi Michal,

I don’t know what exactly “canonical” means here.

As a general rule, timestamps used by machines should not use timezones, so you 
should use

2023-02-22T22:00:00Z

If there is a use for indicating the timezone offset a particular system was in 
when the timestamp actually occurred, then you might indicate that with a 
timezone offset:

2023-02-23T11:00:00+13:00

The point in time at which you formatted this datetime is never relevant.

I’m having a hard time imagining when you want to supply this hint at an 
individual timestamp level — I would believe these all should be without 
timezone offsets, i.e., Z.  
Your system information might usefully have timezone information (see also 
below), if timezone is at all relevant to your system.


Note that if you have additional information (“hints”) that you want to send 
with the actual timestamp, you probably want to know about SEDATE’s IXDTF:

https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html

I don’t know when YANG will pick this up; I don’t know how important these 
hints are in management information (and that my uncertainty applies to using 
the timezone offset defined by RFC 3339 in YANG as well).

Grüße, Carsten

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