Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
On Wed, Jun 29, 2022 at 4:12 PM Carsten Bormann wrote: > > > > Yes. E.g, the constrained-voucher spec could define a new media type, > ZANG-data+CBOR, which is defined to be almost identical to YANG-data+CBOR, > except that in a few places (small matter of defining this properly, e.g., > based on SIDs) the encoding deviates. > > > > > > There will be more optimizations that will be added over time. > > Would it be possible to use a media-type parameter to identify each of > the almost-identical variants? > > There could be a version number (zang-data+cbor; v=3), with increasing > sets of optimizations being factored in at each version. > > > I new media type for each variant seems like too much cut-and-paste. > > A bit field (enumerating the powerset) would be another way, but would > also be an interop testing nightmare. > > A version or variant also requires both peers to agree on the supported subset (if any). Maybe better to forget any parameter. > Grüße, Carsten > > > Andy ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
> > Yes. E.g, the constrained-voucher spec could define a new media type, > ZANG-data+CBOR, which is defined to be almost identical to YANG-data+CBOR, > except that in a few places (small matter of defining this properly, e.g., > based on SIDs) the encoding deviates. > > > There will be more optimizations that will be added over time. > Would it be possible to use a media-type parameter to identify each of the > almost-identical variants? There could be a version number (zang-data+cbor; v=3), with increasing sets of optimizations being factored in at each version. > I new media type for each variant seems like too much cut-and-paste. A bit field (enumerating the powerset) would be another way, but would also be an interop testing nightmare. Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
On Wed, Jun 29, 2022 at 12:17 PM Carsten Bormann wrote: > On 29. Jun 2022, at 19:10, Andy Bierman wrote: > > > > The sender and receiver need to agree on the encoding of each schema > item. > > There can be no guessing. But maybe this is a protocol issue and can be > addressed there. > > Yes. E.g, the constrained-voucher spec could define a new media type, > ZANG-data+CBOR, which is defined to be almost identical to YANG-data+CBOR, > except that in a few places (small matter of defining this properly, e.g., > based on SIDs) the encoding deviates. > > There will be more optimizations that will be added over time. Would it be possible to use a media-type parameter to identify each of the almost-identical variants? I new media type for each variant seems like too much cut-and-paste. > Grüße, Carsten > Andy ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
On 29. Jun 2022, at 19:10, Andy Bierman wrote: > > The sender and receiver need to agree on the encoding of each schema item. > There can be no guessing. But maybe this is a protocol issue and can be > addressed there. Yes. E.g, the constrained-voucher spec could define a new media type, ZANG-data+CBOR, which is defined to be almost identical to YANG-data+CBOR, except that in a few places (small matter of defining this properly, e.g., based on SIDs) the encoding deviates. Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
On Wed, Jun 29, 2022 at 8:09 AM Carsten Bormann wrote: > > > So your proposal is for the sender to check every single string it sends > to the receiver to > > see if some complex 20 byte string can be changed to an 8 byte integer > instead? > > In an actual implementation, these 20 byte strings never exist. > > How a sender finds out that the 4-byte integer is enough is not specified. > The answer is probably: because the data were in platform time format, and > we just don’t do a strftime but a memmove(..htonl(..)). > > The sender and receiver need to agree on the encoding of each schema item. There can be no guessing. But maybe this is a protocol issue and can be addressed there. Since this is a property of the CBOR encoding and not the YANG model itself, adding more YANG statements seems like the wrong approach. Extensions are possible but completely optional-to-implement. Republication of all the modules that use date-and-time to add the extension is not practical. IMO the typedef replacement equivalency discussed in 7950, sec. 11 is not important. It is no burden at all to just use the correct 'date-and-time' data type. There are no real examples of the plain string approach Juergen mentioned. It is not a valid use-case. Andy > This seems rather CPU-intensive and not very useful for YANG Push. > > The way you describe it definitely is. > But the specification would not stop you from doing do this, just your > implementation common sense. > > > I doubt constrained devices have enough CPU for this, or that they need > to send > > lots of date-and-time data nodes to justify it. > > So far we have: > > — date-time and friends (as POSIX time integer): CBOR tag 1 > — IP addresses and friends (as binary): CBOR tag 52 and 54 > > Fortunately, “type binary” is an actual base type, so here we already have > actual schema support and therefore support in YANG-CBOR as is. > > > The date-and-time typedef for a string is not special in YANG in any way. > > Just another derived type defined in a YANG module. > > Indeed, this is the reason why it is hard to do this properly (i.e., > deterministically in a way that it is guaranteed that every generator gets > the choice right) without additional language support. > > Grüße, Carsten > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
> So your proposal is for the sender to check every single string it sends to > the receiver to > see if some complex 20 byte string can be changed to an 8 byte integer > instead? In an actual implementation, these 20 byte strings never exist. How a sender finds out that the 4-byte integer is enough is not specified. The answer is probably: because the data were in platform time format, and we just don’t do a strftime but a memmove(..htonl(..)). > This seems rather CPU-intensive and not very useful for YANG Push. The way you describe it definitely is. But the specification would not stop you from doing do this, just your implementation common sense. > I doubt constrained devices have enough CPU for this, or that they need to > send > lots of date-and-time data nodes to justify it. So far we have: — date-time and friends (as POSIX time integer): CBOR tag 1 — IP addresses and friends (as binary): CBOR tag 52 and 54 Fortunately, “type binary” is an actual base type, so here we already have actual schema support and therefore support in YANG-CBOR as is. > The date-and-time typedef for a string is not special in YANG in any way. > Just another derived type defined in a YANG module. Indeed, this is the reason why it is hard to do this properly (i.e., deterministically in a way that it is guaranteed that every generator gets the choice right) without additional language support. Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
On Tue, Jun 28, 2022 at 11:42 PM Carsten Bormann wrote: > > > > On 29. Jun 2022, at 03:54, Jürgen Schönwälder < > j.schoenwael...@jacobs-university.de> wrote: > > > > On Tue, Jun 28, 2022 at 11:40:55PM +0200, Carsten Bormann wrote: > >> On 2022-06-28, at 22:50, Carsten Bormann wrote: > >>> > >>> The alternative would be to trigger on the data, so any string that > looks like 2022-06-28T20:48:15Z would turn into 1(1656449295). That has > some interesting security considerations, though. > >> > >> Hmm, that is starting to become more attractive to me. > >> > >> As long as we can make sure that the same string comes back out again, > this can be safe even if we don’t get the typenames right. > >> > >> Of course an efficient implementation might still be triggered by > typenames, but it wouldn’t create a problem if that guesses wrong. > >> > > > > This sounds super scary. So how in CBOR would you make sure that the > > timezone suffix Z remains Z and the suffix +00:00 remains +00:00? > > Clearly, the idea only makes sense if the packing/unpacking function is a > bijection. > So 1(1656449295) can only stand for 2022-06-28T20:48:15Z and not, at the > same time, for 2022-06-28T20:48:15+00:00. > The application can then decide that it really wants to use > 2022-06-28T20:48:15Z because that packs better, and not > 2022-06-28T20:48:15+00:00. > All that works best if we have something like a canonical representation > for some application data. > (Without that, it becomes less transparent for an application what the > cost of a specific data item is going to be.) > > So far I’m aware of date-time and IP addresses as obvious candidates for > this. Anything else that would benefit significantly? > > So your proposal is for the sender to check every single string it sends to the receiver to see if some complex 20 byte string can be changed to an 8 byte integer instead? This seems rather CPU-intensive and not very useful for YANG Push. I doubt constrained devices have enough CPU for this, or that they need to send lots of date-and-time data nodes to justify it. The date-and-time typedef for a string is not special in YANG in any way. Just another derived type defined in a YANG module. Grüße, Carsten > > Andy ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
Andy Bierman wrote: > On Tue, Jun 28, 2022 at 11:30 AM Carsten Bormann wrote: >> > Andy Bierman wrote: >> I am not in favor of the >> YANG-CBOR draft defining special encodings for >> 1 derived type (like >> date-and-time). Implementations may not store the >> named YANG >> typedefs defined in various YANG modules. >> The current draft >> (properly) addresses only the base types, not derived >> types. >> > >> > So, do you think that auxiliary drafts could/should be written to >> deal with special > encoding of derived times? >> >> Well, first of all we need an architecture that explains how to do >> this. (Who needs to know what to make this happen.) >> >> > The key design goal is the YANG modules do not need to be modified to > provide efficient encoding options for CBOR. Instead, tags are used to > indicate an alternate encoding is sent on the wire. > Each protocol needs a "server capabilities" discovery mechanism. For > example, NETCONF has a URI, but the current practice is to > design a protocol-independent YANG module for the client to read. I hate this. 1) it fails for data at rest, or which have to go through multiple steps. 2) if I'm trying to reduce code (and bugs) as well as network traffic, then having a thing that translates to/from the ascii date representation as an *OPTION* is just a non-starter. I'm okay with some extension to SID to inform the encoder/decoder. I started a thread in cbor@, and I think that we should do the work in cbor@ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] BRSKI-PRM first review comments / remaining review comments
Hi everyone, In the past weeks I’ve continued my review and now created more Github issues (#22 - #60, see https://github.com/anima-wg/anima-brski-prm/issues?q=is%3Aissue+author%3AEskoDijk) for items that may require discussion. Thanks to Steffen and Thomas for starting to resolve these already before I manage to announce my own review :) Overall, the PRM approach looks good & useful although a sort of “reality check” would be good to do for using the protocol over low-data links like BLE / NFC. For that I’ve created issue #33 (https://github.com/anima-wg/anima-brski-prm/issues/33). Will the waiting times for the operator of the hand-held registrar-agent be still roughly acceptable, given the data sizes of the multiple messages that need to be exchanged? When the issues are resolved I can also contribute a Pull Request with some readability improvements and nit fixes. Best regards Esko IoTconsultancy.nl | Email/Teams: esko.d...@iotconsultancy.nl From: Anima On Behalf Of Fries, Steffen Sent: Thursday, June 9, 2022 08:58 To: Anima@ietf.org Subject: [Anima] BRSKI-PRM first review comments Hi all, We’ve got the first comments from the BRSKI-PRM peer review from Esko. Thanks for doing the review. I’ve included them as issue #16-21 on the anima github (https://github.com/anima-wg/anima-brski-prm/issues). Some of them relate to clarifications of the BRSKI-PRM functionality (e.g., usage of nonceless voucher to support offline MASA) and the architectural clarifications (e.g., Join Proxy not necessary) They will be addressed in the next version of the draft. We will continue using githab to collect the comments and also the resolution discussion and provide the information via the mailing list. Best regards Steffen -- Steffen Fries Siemens AG ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [core] date-and-time and "created-on" field in constrained-voucher
> On 29. Jun 2022, at 03:54, Jürgen Schönwälder > wrote: > > On Tue, Jun 28, 2022 at 11:40:55PM +0200, Carsten Bormann wrote: >> On 2022-06-28, at 22:50, Carsten Bormann wrote: >>> >>> The alternative would be to trigger on the data, so any string that looks >>> like 2022-06-28T20:48:15Z would turn into 1(1656449295). That has some >>> interesting security considerations, though. >> >> Hmm, that is starting to become more attractive to me. >> >> As long as we can make sure that the same string comes back out again, this >> can be safe even if we don’t get the typenames right. >> >> Of course an efficient implementation might still be triggered by typenames, >> but it wouldn’t create a problem if that guesses wrong. >> > > This sounds super scary. So how in CBOR would you make sure that the > timezone suffix Z remains Z and the suffix +00:00 remains +00:00? Clearly, the idea only makes sense if the packing/unpacking function is a bijection. So 1(1656449295) can only stand for 2022-06-28T20:48:15Z and not, at the same time, for 2022-06-28T20:48:15+00:00. The application can then decide that it really wants to use 2022-06-28T20:48:15Z because that packs better, and not 2022-06-28T20:48:15+00:00. All that works best if we have something like a canonical representation for some application data. (Without that, it becomes less transparent for an application what the cost of a specific data item is going to be.) So far I’m aware of date-time and IP addresses as obvious candidates for this. Anything else that would benefit significantly? Grüße, Carsten ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
