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 [email protected] > Sent: 21/05/2020 02:21:39 > > -----Original Message----- > From: COSE <[email protected]> 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" > > <[email protected][email protected]> > > To: <IETF-Announce> > > Cc: <[email protected]>; <[email protected]>; > > <[email protected]>; <[email protected]> > > 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 > >> [email protected] mailing lists by 2020-05-26. Exceptionally, > > comments may > >> be sent to [email protected] 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/ietf-announce > >> = > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > -- > last-call mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/last-call _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
