Concise Binary Object Representation (CBOR) Tags for Object Identifiers
draft-ietf-cbor-tags-oid-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
08 | Gunter Van de Velde | Request closed, assignment withdrawn: Joel Jaeggli Last Call OPSDIR review |
2024-01-26
|
08 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2021-07-14
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-06
|
08 | (System) | RFC Editor state changed to AUTH48 |
2021-06-08
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-05-28
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-05-28
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-05-28
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-05-28
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-05-28
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-05-28
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-05-28
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-05-26
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-05-24
|
08 | (System) | RFC Editor state changed to EDIT |
2021-05-24
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-05-24
|
08 | (System) | Announcement was received by RFC Editor |
2021-05-24
|
08 | (System) | IANA Action state changed to In Progress |
2021-05-24
|
08 | Amy Vezza | Downref to RFC 6256 approved by Last Call for draft-ietf-cbor-tags-oid-08 |
2021-05-24
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-05-24
|
08 | Amy Vezza | IESG has approved the document |
2021-05-24
|
08 | Amy Vezza | Closed "Approve" ballot |
2021-05-24
|
08 | Amy Vezza | Ballot approval text was generated |
2021-05-21
|
08 | (System) | Removed all action holders (IESG state changed) |
2021-05-21
|
08 | Francesca Palombini | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2021-05-21
|
08 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-08.txt |
2021-05-21
|
08 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-05-21
|
08 | Carsten Bormann | Uploaded new revision |
2021-05-19
|
07 | Robert Wilton | [Ballot comment] Clearing discuss based on -07 version of the document. ---- I found this document to be interesting because I knew from the title … [Ballot comment] Clearing discuss based on -07 version of the document. ---- I found this document to be interesting because I knew from the title that it was going to only be 4 pages long and say that OIDs are obviously encoded as a tagged array, hence I was surprised to see that was not the solution and it uses BER encoded OIDs instead. The document explains, and I think that I understand why this has been done, but I question whether the title of the document and name of the tags is right. Is it really a CBOR representation of OIDs, or is it actually a CBOR representation of BER encoded OIDs? I.e., it is plausible that there would ever be a requirement for non BER encoded OIDs. E.g., I'm not an ASN.1 expert, but say if somewhat wanted to do a CBOR encoding of ASN.1, then it is not obvious to me that they would use a BER encoding for OIDs. Hence the suggestion is to make the title, abstract, and name of the tags clear that it is about the CBOR encoding or BER encoded OIDs. In the introduction: Since the semantics of absolute and relative object identifiers differ, this specification defines two tags, collectively called the "OID tags" here: I presume that this should be three tags? In section 4.1. Tag Factoring Example: X.500 Distinguished Name: The diagram uses a mix of single letters (e.g. c for country), and a full name "street". Is this how the X.500 attributes are defined? Otherwise it might be clearer to always use their full names. The country and street RDNs are single-valued. The second and fourth RDNs are multi-valued. Perhaps: "The country (first) and street (third) RDNs are single-valued. The second and fourth RDNs are multi-valued." h'550407': "Los Angeles", h'550408': "CA", I think that the example would be more clear by splitting the city and county onto separate lines. Finally, the document contains these two sentences that seem to somewhat conflict with each other: "While these sequences can easily be represented in CBOR arrays of unsigned integers, a more compact representation can often be achieved by adopting the widely used representation of object identifiers defined in BER; this representation may also be more amenable to processing by other software that makes use of object identifiers." compared to: "Staying close to the way object identifiers are encoded in ASN.1 BER makes back-and-forth translation easy; otherwise we would choose a more efficient encoding." Regards, Rob |
2021-05-19
|
07 | Robert Wilton | [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss |
2021-05-19
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-05-19
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-05-19
|
07 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-07.txt |
2021-05-19
|
07 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-05-19
|
07 | Carsten Bormann | Uploaded new revision |
2021-04-08
|
06 | (System) | Changed action holders to Carsten Bormann, Francesca Palombini (IESG state changed) |
2021-04-08
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-04-08
|
06 | Francesca Palombini | Ballot approval text was generated |
2021-04-08
|
06 | Robert Wilton | [Ballot discuss] Hi, Hopefully not tricky to discuss/resolve, sorry for posting it close to the telechat! I would like to please see some more clarity … [Ballot discuss] Hi, Hopefully not tricky to discuss/resolve, sorry for posting it close to the telechat! I would like to please see some more clarity or guidance about when TAG TBD112 should be used, given that there are two possible encodings of absolute OIDs below "1.3.6.1.4.1". Specifically, the questions that I have, that probably need to be clarified are: - is a CBOR encoder allowed to optimize a TBD110 tag into a TBD112 tag? - Should CBOR decoder clients always expect to be able to handle both TBD110 and TBD112 tags? - Or, it the decision over whether to use TBD110 or TBD112 down to the application and the application needs to agree which is use. |
2021-04-08
|
06 | Robert Wilton | [Ballot comment] I found this document to be interesting because I knew from the title that it was going to only be 4 pages long … [Ballot comment] I found this document to be interesting because I knew from the title that it was going to only be 4 pages long and say that OIDs are obviously encoded as a tagged array, hence I was surprised to see that was not the solution and it uses BER encoded OIDs instead. The document explains, and I think that I understand why this has been done, but I question whether the title of the document and name of the tags is right. Is it really a CBOR representation of OIDs, or is it actually a CBOR representation of BER encoded OIDs? I.e., it is plausible that there would ever be a requirement for non BER encoded OIDs. E.g., I'm not an ASN.1 expert, but say if somewhat wanted to do a CBOR encoding of ASN.1, then it is not obvious to me that they would use a BER encoding for OIDs. Hence the suggestion is to make the title, abstract, and name of the tags clear that it is about the CBOR encoding or BER encoded OIDs. In the introduction: Since the semantics of absolute and relative object identifiers differ, this specification defines two tags, collectively called the "OID tags" here: I presume that this should be three tags? In section 4.1. Tag Factoring Example: X.500 Distinguished Name: The diagram uses a mix of single letters (e.g. c for country), and a full name "street". Is this how the X.500 attributes are defined? Otherwise it might be clearer to always use their full names. The country and street RDNs are single-valued. The second and fourth RDNs are multi-valued. Perhaps: "The country (first) and street (third) RDNs are single-valued. The second and fourth RDNs are multi-valued." h'550407': "Los Angeles", h'550408': "CA", I think that the example would be more clear by splitting the city and county onto separate lines. Finally, the document contains these two sentences that seem to somewhat conflict with each other: "While these sequences can easily be represented in CBOR arrays of unsigned integers, a more compact representation can often be achieved by adopting the widely used representation of object identifiers defined in BER; this representation may also be more amenable to processing by other software that makes use of object identifiers." compared to: "Staying close to the way object identifiers are encoded in ASN.1 BER makes back-and-forth translation easy; otherwise we would choose a more efficient encoding." Regards, Rob |
2021-04-08
|
06 | Robert Wilton | [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton |
2021-04-07
|
06 | Murray Kucherawy | [Ballot comment] For Zaheduzzaman: The downref was properly identified during the Last Call. |
2021-04-07
|
06 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-04-07
|
06 | John Scudder | [Ballot comment] 1. Section 2: Since the semantics of absolute and relative object identifiers differ, this specification defines two tags, collectively called the … [Ballot comment] 1. Section 2: Since the semantics of absolute and relative object identifiers differ, this specification defines two tags, collectively called the "OID tags" here: Sure looks like three tags to me. 2. Section 5: Since this is the first place you refer to CDDL, put your reference to RFC 8610 here instead of §6? |
2021-04-07
|
06 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-04-07
|
06 | Benjamin Kaduk | [Ballot comment] I made a PR at https://github.com/cbor-wg/cbor-oid/pull/9 with an editorial suggestion (it ended up being just one -- well done!). Is there anything useful … [Ballot comment] I made a PR at https://github.com/cbor-wg/cbor-oid/pull/9 with an editorial suggestion (it ended up being just one -- well done!). Is there anything useful to say about how bstrs tagged in this way will be (mis?)interpreted by implementations that don't understand these tag values? Section 2 Tag TBD110: tags a byte string as the [X.690] encoding of a relative object identifier (also "relative OID"). Since the encoding of each number is the same as for [RFC6256] Self-Delimiting Numeric Values (SDNVs), this tag can also be used for tagging a byte string that contains a sequence of zero or more SDNVs. I did not think that CBOR was prone to reusing tag values for types that are semantically different but happen to have the same binary encoding rules. Should generic SDNVs get a dedicated tag? Section 7.1 Please note which range (and encoded length?) the allocations should come from. Alternately, mentioning specific requested values here might be wise (given that there are examples that assume specific values). Section 8 We might mention something about how when tag factoring is in use you have to be careful that the only bstrs being affected do contain OIDs, and inadvertently tagging a compound structure that sometimes contains non-OID bstrs (in the relevant places) can have unexpected effects. Section 9.1 AFAICT RFC 6256 only needs to be normative because of the way the control operators are defined, and we rely on BER for everything else. (Also, it looks like BER has more strict requirements than SDNV for the minimal-length encoding, though I did not investigate this very thoroughly.) |
2021-04-07
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-04-07
|
06 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-04-07
|
06 | Éric Vyncke | [Ballot comment] Thank you for the work put in this document. Thank you also for your reply to Ines Robles' review for the IoT directorate: … [Ballot comment] Thank you for the work put in this document. Thank you also for your reply to Ines Robles' review for the IoT directorate: https://datatracker.ietf.org/doc/review-ietf-cbor-tags-oid-06-iotdir-telechat-robles-2021-04-06/ Regards -éric |
2021-04-07
|
06 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-04-06
|
06 | Ines Robles | Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list. |
2021-04-06
|
06 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-04-06
|
06 | Zaheduzzaman Sarker | [Ballot comment] IDnits returned a downref error. |
2021-04-06
|
06 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-04-06
|
06 | Lars Eggert | [Ballot comment] All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. … [Ballot comment] All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 2, paragraph 2, nit: - i.e. a (sub)sequence of such integer values.) + i.e., a (sub)sequence of such integer values.) + + Section 2.1, paragraph 14, nit: - regexp is invalid. + regular expression is invalid. + +++++ +++++++ The following URLs in the document failed to return content: * http://www.penango.com/ |
2021-04-06
|
06 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-04-05
|
06 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-04-05
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-04-02
|
06 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Ines Robles |
2021-04-02
|
06 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Ines Robles |
2021-04-02
|
06 | Éric Vyncke | Requested Telechat review by IOTDIR |
2021-03-31
|
06 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2021-03-30
|
06 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-03-30
|
06 | Amy Vezza | Placed on agenda for telechat - 2021-04-08 |
2021-03-30
|
06 | Francesca Palombini | Ballot has been issued |
2021-03-30
|
06 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2021-03-30
|
06 | Francesca Palombini | Created "Approve" ballot |
2021-03-30
|
06 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-03-30
|
06 | Francesca Palombini | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2021-03-30
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-03-30
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2021-03-30
|
06 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-06.txt |
2021-03-30
|
06 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-03-30
|
06 | Carsten Bormann | Uploaded new revision |
2021-03-26
|
05 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK |
2021-03-26
|
05 | Francesca Palombini | Waiting for update pending Last Call comments. |
2021-03-26
|
05 | (System) | Changed action holders to Carsten Bormann, Francesca Palombini (IESG state changed) |
2021-03-26
|
05 | Francesca Palombini | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2021-03-24
|
05 | (System) | Changed action holders to Francesca Palombini (IESG state changed) |
2021-03-24
|
05 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-03-23
|
05 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2021-03-23
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-cbor-tags-oid-05. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-cbor-tags-oid-05. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the Concise Binary Object Representation (CBOR) Tags located at: https://www.iana.org/assignments/cbor-tags/ three, new CBOR tags are to be registered as follows: Tag: [ TBD-at-Registration ] Data Item: byte string or array or map Semantics: object identifier (BER encoding) Reference: [ RFC-to-be ] Tag: [ TBD-at-Registration ] Data Item: byte string or array or map Semantics: relative object identifier (BER encoding); SDNV [RFC6256] sequence Reference: [ RFC-to-be ] Tag: [ TBD-at-Registration ] Data Item: byte string or array or map Semantics: object identifier (BER encoding), relative to 1.3.6.1.4.1 Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the CDDL Control Operators registry on the Concise Data Definition Language (CDDL) registry page located at: https://www.iana.org/assignments/cddl/ three, new registrations are to be made as follows: Name: .sdnv Reference: [ RFC-to-be; Section 5 ] Name: .sdnvseq Reference: [ RFC-to-be; Section 5 ] Name: .oid Reference: [ RFC-to-be; Section 5 ] The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2021-03-20
|
05 | Gyan Mishra | Request for Last Call review by GENART Completed: Ready. Reviewer: Gyan Mishra. Sent review to list. |
2021-03-10
|
05 | Cindy Morgan | Shepherding AD changed to Francesca Palombini |
2021-03-08
|
05 | Christian Amsüss | Added to session: IETF-110: cbor Mon-1530 |
2021-03-05
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2021-03-05
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2021-03-04
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2021-03-04
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2021-03-04
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2021-03-04
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2021-03-03
|
05 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-03-03
|
05 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-03-24): From: The IESG To: IETF-Announce CC: barryleiba@gmail.com, cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, draft-ietf-cbor-tags-oid@ietf.org … The following Last Call announcement was sent out (ends 2021-03-24): From: The IESG To: IETF-Announce CC: barryleiba@gmail.com, cbor-chairs@ietf.org, cbor@ietf.org, christian@amsuess.com, draft-ietf-cbor-tags-oid@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Concise Binary Object Representation (CBOR) Tags for Object Identifiers) to Proposed Standard The IESG has received a request from the Concise Binary Object Representation Maintenance and Extensions WG (cbor) to consider the following document: - 'Concise Binary Object Representation (CBOR) Tags for Object Identifiers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document defines CBOR tags for object identifiers (OIDs). It is intended as the reference document for the IANA registration of the CBOR tags so defined. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cbor-tags-oid/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6256: Using Self-Delimiting Numeric Values in Protocols (Informational - IRTF Stream) |
2021-03-03
|
05 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-03-03
|
05 | Barry Leiba | Last call was requested |
2021-03-03
|
05 | Barry Leiba | Ballot approval text was generated |
2021-03-03
|
05 | Barry Leiba | IESG state changed to Last Call Requested from AD Evaluation |
2021-03-03
|
05 | Barry Leiba | Last call announcement was changed |
2021-03-03
|
05 | Barry Leiba | Ballot writeup was changed |
2021-03-03
|
05 | Barry Leiba | Ballot writeup was changed |
2021-03-03
|
05 | (System) | Changed action holders to Barry Leiba (IESG state changed) |
2021-03-03
|
05 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2021-03-03
|
05 | Christian Amsüss | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of RFC being requested is standard track. This document is the reference specification for the IANA registration of Object Identifiers. This document provides a stable reference for other standardization bodies. The WG went for the document being Standard track for this document, but could be informational if the AD prefers it. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The Concise Binary Object Representation (CBOR, draft-ietf-cbor- 7049bis) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document defines CBOR tags for object identifiers (OIDs). It is intended as the reference document for the IANA registration of the CBOR tags so defined. Working Group Summary There was working group consensus on publishing this document, no point was particularly contentious. Document Quality There is no existing implementations of the specifications, as far as I can tell. A number of WG participants have stated they have read and reviewed the document. No expert review was requested. Personnel Christian Amsüss is the Document Shepherd (taking over from Francesca Palombini). Barry Leiba is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has reviewed the document and finds it ready for publication. Moreover, the Document Shepherd has kept track of the several reviews of the documents and made sure all comments were addressed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No broader reviews or from a particular areas are needed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no such concerns or issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The current author (Carsten Bormann) is not aware of any relevant claims. We have failed so far to reach Sean Leonard (who was recently moved from Author to Contributor) despite independent attempts. I do not expect IPR related trouble, but that contributor's confirmation is lacking. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The working group consensus behind the document is solid, according to WG last calls, in room feeling during several meetings, and off line discussion. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threats of appeal or extreme discontent have been made public. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There is one downref (see below); other than that, all the tools report was checked and is false positive: * OIDs are misidentified as IP addresses * CBOR data is misidentified as references. Some reports are what I believe to be a discrepancy between the tools and the xmlrfc version: * The non-ASCII characters are in the author's affiliation and in cited documents. * The recognized future date is the expiry date. * Code detection triggers even though there is no executable code around. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such criteria apply. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. The reference to RFC 6256 (Using Self-Delimiting Numeric Values in Protocols) is a downref to an Informational document. This draft is the first document to normatively reference that. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No RFCs status will be changed by publication of this document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA registration of several CBOR tags and CDDL control operators is requested. The registration is appropriate. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No such new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No automated checks were done. (We might consider adding such mechanisms for CDDL, though). |
2021-03-03
|
05 | Christian Amsüss | Responsible AD changed to Barry Leiba |
2021-03-03
|
05 | Christian Amsüss | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-03-03
|
05 | Christian Amsüss | IESG state changed to Publication Requested from I-D Exists |
2021-03-03
|
05 | Christian Amsüss | IESG process started in state Publication Requested |
2021-03-03
|
05 | Christian Amsüss | Changed consensus to Yes from Unknown |
2021-03-03
|
05 | Christian Amsüss | Intended Status changed to Proposed Standard from None |
2021-03-03
|
05 | Christian Amsüss | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of RFC being requested is standard track. This document is the reference specification for the IANA registration of Object Identifiers. This document provides a stable reference for other standardization bodies. The WG went for the document being Standard track for this document, but could be informational if the AD prefers it. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The Concise Binary Object Representation (CBOR, draft-ietf-cbor- 7049bis) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document defines CBOR tags for object identifiers (OIDs). It is intended as the reference document for the IANA registration of the CBOR tags so defined. Working Group Summary There was working group consensus on publishing this document, no point was particularly contentious. Document Quality There is no existing implementations of the specifications, as far as I can tell. A number of WG participants have stated they have read and reviewed the document. No expert review was requested. Personnel Christian Amsüss is the Document Shepherd (taking over from Francesca Palombini). Barry Leiba is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has reviewed the document and finds it ready for publication. Moreover, the Document Shepherd has kept track of the several reviews of the documents and made sure all comments were addressed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No broader reviews or from a particular areas are needed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no such concerns or issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The current author (Carsten Bormann) is not aware of any relevant claims. We have failed so far to reach Sean Leonard (who was recently moved from Author to Contributor) despite independent attempts. I do not expect IPR related trouble, but that contributor's confirmation is lacking. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The working group consensus behind the document is solid, according to WG last calls, in room feeling during several meetings, and off line discussion. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No threats of appeal or extreme discontent have been made public. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There is one downref (see below); other than that, all the tools report was checked and is false positive: * OIDs are misidentified as IP addresses * CBOR data is misidentified as references. Some reports are what I believe to be a discrepancy between the tools and the xmlrfc version: * The non-ASCII characters are in the author's affiliation and in cited documents. * The recognized future date is the expiry date. * Code detection triggers even though there is no executable code around. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such criteria apply. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. The reference to RFC 6256 (Using Self-Delimiting Numeric Values in Protocols) is a downref to an Informational document. This draft is the first document to normatively reference that. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No RFCs status will be changed by publication of this document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA registration of several CBOR tags and CDDL control operators is requested. The registration is appropriate. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No such new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No automated checks were done. (We might consider adding such mechanisms for CDDL, though). |
2021-02-19
|
05 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-05.txt |
2021-02-19
|
05 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2021-02-19
|
05 | Carsten Bormann | Uploaded new revision |
2021-01-27
|
04 | Christian Amsüss | Notification list changed to christian@amsuess.com because the document shepherd was set |
2021-01-27
|
04 | Christian Amsüss | Document shepherd changed to Christian Amsüss |
2021-01-27
|
04 | Francesca Palombini | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-01-26
|
04 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-04.txt |
2021-01-26
|
04 | (System) | New version approved |
2021-01-26
|
04 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Sean Leonard |
2021-01-26
|
04 | Carsten Bormann | Uploaded new revision |
2020-11-17
|
03 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-03.txt |
2020-11-17
|
03 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-11-17
|
03 | Carsten Bormann | Uploaded new revision |
2020-11-10
|
02 | Francesca Palombini | Added to session: IETF-109: cbor Thu-1430 |
2020-10-30
|
02 | Francesca Palombini | ends on Thursday, 12th November. |
2020-10-30
|
02 | Francesca Palombini | IETF WG state changed to In WG Last Call from WG Document |
2020-10-28
|
02 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-02.txt |
2020-10-28
|
02 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-10-28
|
02 | Carsten Bormann | Uploaded new revision |
2020-09-30
|
01 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-01.txt |
2020-09-30
|
01 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-09-30
|
01 | Carsten Bormann | Uploaded new revision |
2020-07-31
|
00 | Carsten Bormann | This document now replaces draft-bormann-cbor-tags-oid instead of None |
2020-07-31
|
00 | Carsten Bormann | New version available: draft-ietf-cbor-tags-oid-00.txt |
2020-07-31
|
00 | (System) | New version accepted (logged-in submitter: Carsten Bormann) |
2020-07-31
|
00 | Carsten Bormann | Uploaded new revision |