The nested quoting is pretty hard to read; hopefully I am responding in the right places... On Thu, May 21, 2020 at 10:30:18AM +0100, tom petch wrote: > Jim > inline <tp> several times > > ----- Original Message ----- > From: Jim Schaad ietf@xxxxxxxxxxxxxxxxx > Sent: 21/05/2020 02:21:39 > > -----Original Message----- > From: COSE <cose-bounces@xxxxxxxx> On Behalf Of tom petch > Sent: Tuesday, May 19, 2020 2:36 AM > > I encounter a number of problems with this I-D. Much of it is about IANA > Considerations and I note the absence of a reference to RFC8126 which > provides the basis for much of my comments. > > [JLS] There is a reason why you are not seeing much of the IANA > Considerations that you believe should be present, it is because they are in > draft-ietf-cose-rfc8152bis-algs and draft-ietf-cose-rfc8152bis-struct. Most > of them are in the algorithm document. The presumption is that those two > documents are going to be processed by IANA before this document is. I will > make this explicit. > > <tp> > Yes, if there had been a Normative Reference to rfc8152bis-algs then I would have read that first and my comments would have been different! If the updates to the IANA Registry are all in -algs, then I think it confusing to have them in here as well, rather just say that a new column is defined in -algs > > I do not see any mention of 'filter only' in the two rfc8152bis, only in this I-D and that makes me see this I-D as updating RFC8152 with the consequences thereof. > > > > RFC8126 specifies a two-tier structure for IANA, of Group name an Registry > name, which makes it easier to find data, now and in future. > This I-D makes no mention of the Group name; perhaps easy enough to guess in > this instance, but better specified. > > The I-D contains references to some of TBD1 to TBD11, with no indication of > what to do with them. Looking at the current registry it is apparent that > Early Allocation took place in 2018 and 2019. The I-D makes no reference to > this. Are all these values to be made permanent? Some of them? I expect > the I-D to say. > [JLS] use the TBD placeholders is normal usage with the values being > assigned by IANA and replaced in the document. It would be possible to > refer to the early assignments, but I personally feel that this is a > decision for IANA to make. There may be reasons when the final assignment > is done that different values need to be used. (For example, incorrect > usage of existing values in the wild or collisions found during the > assignment process.) I have always made the assumption that the instruction > for the RFC Editor to replace them is implicit and does not need to be > explicit. I can make that change although I doubt it makes any difference. > > <tp> I disagree with you here. Yes, the final allocation is for IANA to make but you should ask for what you want to guide them. Early Allocation can mean implemented in ASICs and deployed in hundreds of thousands of boxes in which case the cost of change is substantial compared to say a change of one constant in one line in Linux. You know, IANA do not; tell them! I do think it's pretty common to have the document say something about "makes permanent the early allocation of value NNN for <X>". > > The I-D adds the value 'filter only' to one of the columns. The registry > was set up by RFC8152 which lists permitted values of which this is not one. > This then constitutes an update to RFC8152 which the I-D does not mention. > [JLS] I would disagree that this requires an update of RFC 8152 for two > reasons. First this is not a change in the COSE protocol in any manner and > thus would violate what I consider to be the letter of the law for updates. > Second, when this change is made RFC 8152 will have been obsoleted by a new > RFC and thus it does not really make sense to update it. This is an IANA > instruction not a protocol change. > > <tp> I agree that the protocol does not change but the rules set out by RFC8152 for the IANA Registry do change and that IMHO is an update to RFC8152, one that rfc8152bis-algs does not include, The registry is an entity in its own right, and there is a "Reference" field associated with the registry that accepts multi-value input. Updating the registry is generally orthogonal to updating the document that created the registry initially. -Ben > > The registry has five columns; this I-D adds a new one, Capabilities, > another update to RFC8152. What then happens to this column for existing > entries in the registry? The I-D is silent. > [JLS] This is done by a different document. > <tp> yes, I can see that now > > RFC8152 is Standards Track; this I-D which IMHO updates it is Informational. > [JLS] Given that it is updating the IANA sections and not the protocol I > would not consider that to be an issue. > <tp> I do :-) > > The IANA registry entry gives a reference of 'RFC8152'; this I-D, which > changes the specification of the registry, needs adding to that reference. > [JLS] This make sense and I will do it. > > RFC8126 recommends that IANA Considerations be for IANA, that IANA does not > have to search the rest of the document for the data it needs. > Here, the relevant data appears in three other sections as well (and there > is much in the I-D that is not relevant to IANA, it is not one of those I-D > that is only about IANA). > [JLS] I do not consider that pointing to a table in the document to fall > under the rubric of making IANA search for data. It is a direct pointer to > the information that is required. Having the same table appear multiple > times in a document is a recipe for making mistakes in terms of what the > data is. There is already the problem of trying to harmonize text and the > table with out adding another version of the table. > > Abstract should be plain text - > [I-D.ietf-cose-rfc8152bis-struct] > does not look like plain text. > [JLS] This is not plain text and will be repaired by the RFC editor. Using > the reference structure makes it clearer that this is something that the RFC > editor is going to be required to update. This is not something I do for > documents which are already RFCs. > <tp> An alternative that I see other Authors use is to specify RFC YYYY with an RFC Editor note to replace YYYY when the I-D referenced becomes an RFC - just a thought. > > Tom Petch > > I have great faith in the a > > --- > New Outlook Express and Windows Live Mail replacement - get it here: > https://www.oeclassic.com/ > > bility of IANA to make sense of what they are > asked to do but do think that the more straightforward that is the better. > And then there are those that come after, who want the RFC to say what > happened and why without digging into the e-mail archives (as I see > happening now and again:-) > [JLS] The other problem that you have not highlighted is the question of > when a bis document is created should the IANA instructions be propagated > forward into the new document despite the fact that IANA is not going to do > anything. That is what is going to happen with some of these registries. > It makes life even harder if duplicate or extraneous items are included. > > Jim > > > Tom Petch > > > ----- Original Message ----- > > From: "IETF-Announce on behalf of The IESG" > > <ietf-announce-bounces@ietf.orgiesg-secretary@xxxxxxxx> > > To: <IETF-Announce> > > Cc: <draft-ietf-cose-hash-algs@xxxxxxxx>; <cose-chairs@xxxxxxxx>; > > <cose@xxxxxxxx>; <ivaylo@xxxxxxx> > > Sent: Tuesday, May 12, 2020 4:26 PM > > > >> The IESG has received a request from the CBOR Object Signing and > > Encryption > >> WG (cose) to consider the following document: - 'CBOR Object Signing > > and > >> Encryption (COSE): Hash Algorithms' > >> <draft-ietf-cose-hash-algs-03.txt> as Informational RFC > >> > >> 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@xxxxxxxx mailing lists by 2020-05-26. Exceptionally, > > comments may > >> be sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning > >> of the Subject line to allow automated sorting. > >> > >> Abstract > >> > >> > >> The CBOR Object Signing and Encryption (COSE) syntax > >> [I-D.ietf-cose-rfc8152bis-struct] does not define any direct > > methods > >> for using hash algorithms. There are however circumstances where > >> hash algorithms are used: Indirect signatures where the hash of one > >> or more contents are signed. X.509 certificate or other object > >> identification by the use of a fingerprint. This document > >> defines > > a > >> set of hash algorithms that are identified by COSE Algorithm > >> Identifiers. > >> > >> > >> The file can be obtained via > >> https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ > >> > >> > >> > >> No IPR declarations have been submitted directly on this I-D. > >> > >> > >> > >> > >> > >> _______________________________________________ > >> IETF-Announce mailing list > >> IETF-Announce@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/ietf-announce > >> = > > _______________________________________________ > COSE mailing list > COSE@xxxxxxxx > https://www.ietf.org/mailman/listinfo/cose > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
