On Tue, Apr 07, 2020 at 10:55:28PM +0200, Carsten Bormann wrote: > On 2020-04-07, at 21:47, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> 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). >
This makes sense, but I prefer to have the media types defined in YANG-CBOR. If I use CBOR with RESTCONF, I love to depend on YANG-CBOR only and not in addition on COMI just for the media type definition. The serialization format is defined in YANG-CBOR, hence it makes sense to me to define the corresponding media-type(s) there as well. Note, I did not manage to review COMI due to a lack of time. So I am digging into the type definitions now. RESTCONF (RFC 8040) defines: application/yang-data+json application/yang-data+xml 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 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 and to leave the other two application/yang-identifiers+cbor application/yang-instances+cbor for COMI. There is a certain interest to stream binary encoded YANG data and having a self-contained YANG-CBOR document would be desirable to minimize dependencies and maintenance headache down the road. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
