Re: [netmod] Strictness of Base64classic in RFC 7950/7951
Kent Watsen writes: >>> 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). > > That document was published before the issue was discovered. File an Errata > for it? > > >> Do you have a pointer to the discussion? > > Not at hand. Was it this thread? https://mailarchive.ietf.org/arch/msg/netconf/ra_KfLp2HPUZajLIYQ_MBLf-sfw/ Lada > > >> Was there, at the same time, any conclusion with respect to my question >> (strict or soup)? > > No, only that it was wrong and should be fixed. ;) > > > K. > >> Grüße, Carsten > > -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8519 (7312)
Greetings Rob, We are unable to verify this erratum that the submitter marked as editorial. Please note that we have changed the “Type” of the following errata report to “Technical”. As Stream Approver, please review and set the Status and Type accordingly (see the definitions at https://www.rfc-editor.org/errata-definitions/). You may review the report at: https://www.rfc-editor.org/errata/eid7312 Please see https://www.rfc-editor.org/how-to-verify/ for further information on how to verify errata reports. Further information on errata can be found at: https://www.rfc-editor.org/errata.php. Thank you. RFC Editor/cs > On Jan 18, 2023, at 6:29 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC8519, > "YANG Data Model for Network Access Control Lists (ACLs)". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7312 > > -- > Type: Editorial > Reported by: Mohamed Boucadair > > Section: A.1 > > Original Text > - > The "example-newco-acl" module is an example of a company's > proprietary model that augments the "ietf-acl" module. It shows how > to use 'augment' with an XML Path Language (XPath) expression to add > additional match criteria, actions, and default actions for when no > ACE matches are found. All these are company proprietary extensions > or system feature extensions. "example-newco-acl" is just an > example, and it is expected that vendors will create their own > proprietary models. > > Corrected Text > -- > The "example-newco-acl" module is an example of a company's > proprietary model that augments the "ietf-access-control-list" module. It > shows how > to use 'augment' with an XML Path Language (XPath) expression to add > additional match criteria, actions, and default actions for when no > ACE matches are found. All these are company proprietary extensions > or system feature extensions. "example-newco-acl" is just an > example, and it is expected that vendors will create their own > proprietary models. > > Notes > - > There is no "ietf-acl" module in the document. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8519 (draft-ietf-netmod-acl-model-21) > -- > Title : YANG Data Model for Network Access Control Lists (ACLs) > Publication Date: March 2019 > Author(s) : M. Jethanandani, S. Agarwal, L. Huang, D. Blair > Category: PROPOSED STANDARD > Source : Network Modeling > Area: Operations and Management > Stream : IETF > Verifying Party : IESG > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [Editorial Errata Reported] RFC8519 (7313)
Greetings Rob,
We are unable to verify this erratum that the submitter marked as editorial.
Please note that we have changed the “Type” of the following errata
report to “Technical”. As Stream Approver, please review and set the
Status and Type accordingly (see the definitions at
https://www.rfc-editor.org/errata-definitions/).
You may review the report at:
https://www.rfc-editor.org/errata/eid7313
Please see https://www.rfc-editor.org/how-to-verify/ for further
information on how to verify errata reports.
Further information on errata can be found at:
https://www.rfc-editor.org/errata.php.
Thank you.
RFC Editor/cs
> On Jan 18, 2023, at 7:02 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7313
>
> --
> Type: Editorial
> Reported by: Mohamed Boucadair
>
> Section: A.1
>
> Original Text
> -
> The following figure is the tree diagram of example-newco-acl. In
> this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
> ietf-acl:matches are augmented with two new choices: protocol-
> payload-choice and metadata. The protocol-payload-choice uses a
> grouping with an enumeration of all supported protocol values.
> Metadata matches apply to fields associated with the packet, that are
> not in the packet header, such as overall packet length. In another
> example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/
> ietf-acl:actions are augmented with a new choice of actions.
>
> Corrected Text
> --
> The following figure is the tree diagram of example-newco-acl. In
> this example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches
> are augmented with two new choices: protocol-payload-choice and
> metadata. The protocol-payload-choice uses a
> grouping with an enumeration of all supported protocol values.
> Metadata matches apply to fields associated with the packet, that are
> not in the packet header, such as overall packet length. In another
> example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions
> are augmented with a new choice of actions.
>
> Notes
> -
> The prefix is "acl" not "ietf-acl"
>
> ==
> module ietf-access-control-list {
> yang-version 1.1;
> namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
> prefix acl;
> ...
> ==
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --
> Title : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date: March 2019
> Author(s) : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category: PROPOSED STANDARD
> Source : Network Modeling
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
>> 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). That document was published before the issue was discovered. File an Errata for it? > Do you have a pointer to the discussion? Not at hand. > Was there, at the same time, any conclusion with respect to my question > (strict or soup)? No, only that it was wrong and should be fixed. ;) K. > 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
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
This was discussed in late 2021. I switched from:
base64encodedvalue==
to:
BASE64VALUE=
in all my drafts then. Which document are you looking at?
Kent
> On Feb 27, 2023, at 9:24 AM, Carsten Bormann wrote:
>
> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
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
Dne 27. 02. 23 v 14:31 Carsten Bormann napsal(a):
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”).
Section 9.1 in RFC 7950: "values in the data tree are conceptually
stored in the canonical representation", and also "XPath expression
evaluations are done using the canonical form". If implementations obey
these rules, and since the canonical form for the binary type is
unambiguous, I don't see much potential for interoperability problems.
In essence, it's like representing number 17 as +17.
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”?
Unlike non-alphabet characters, RFC 4648 doesn't say that such a
character in encoded data is invalid.
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.
Lada
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
--
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
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 writes:
> Quick question (can’t find in the archives whether that was discussed):
>
> 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. 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.
Lada
>
> 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
--
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
