- From: Roberto Polli <robipolli@gmail.com>
- Date: Wed, 9 Nov 2022 11:04:22 +0100
- To: "Murray S. Kucherawy" <superuser@gmail.com>
- Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, ietf-http-wg@w3.org, francesca.palombini@ericsson.com, "Manger, James" <James.H.Manger@team.telstra.com>
Hi Murray, thanks for the review! +Manger, James who is the current DE for dig-alg On Tue, 8 Nov 2022 at 11:53, Murray S. Kucherawy <superuser@gmail.com> wrote: > On Tue, Nov 8, 2022 at 10:39 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: >>> Section 2 [and 3]: >>> >>> * I suggest including a forward reference to the appendices, where examples of replies including multiple hashes can be found. >> [..] In each of these sections, [..we..] immediately give an example of a field containing sha-256 and sha-512. > I think my suggestion is just that as I read these two sections, I found myself immediately wondering what multiple hashes would look like, and in particular that it would be a good thing to demonstrate. I found out later that those examples do exist down in an appendix. Not a major point in any case. I did not create a gh-issue for this, then. If you think this should be addressed, please let us know! >>> Section 5 and Section 7.2: >>> * I encountered this section and followed the link to find that this section is talking about a registry that doesn't actually exist. That this section is actually specifying a new registry was not clear until Section 7.2. Can we clarify this somehow? In "document-structure" we say that we are bootstrapping a new registry. I'm ok to express that in the "abstract" if this can help. >>> For that matter, why not merge this section down into what's in 7.2? iirc we did something similar to https://www.rfc-editor.org/rfc/rfc9110#section-18.1 in order to avoid normative statements in IANA. To avoid inserting normative statements in IANA considerations, I think we could move the table only in 7.2 leaving 5. in the current place. Does it make sense to you? >>> * A "Specification Required" registry obligates the assignment of one or more Designated Experts. >>> Section 4.6 of RFC 8126 says the defining document should contain guidance to the DEs about what criteria are to be applied when doing reviews. >>> None seem to be present here. Is there anything that needs to be said? > I also think that text in 3230 is confusing to me. The first sentence is pretty much exactly the definition of "Specification Required". > I don't understand how it can simultaneously be that and "First Come First Served", which is its own (far less rigorous) registration model. I think it's ok not to mention FCFS since it causes confusion. For the specific policy I'd hear from Mark/Francesca and the other folks. >> IANAIANAE (I am not an IANA expert) - during the spec development we kind of punted the matter of the registries until this phase of the document cycle. >> now would be a good time to discuss between authors, chairs, ADs and the current designated expert of the old registry >> What we were trying to do was create something that followed a similar process to how the current registry has been operated Please, can you take a look at https://github.com/httpwg/http-extensions/issues/1801 wrt how to manage the old registry (which is currently used by Digest implementers)? >> I'm not comfortable mandating DE criteria without involving the current DE in the discussion. @Manger, James have your say :) Thank you all, R.
Received on Wednesday, 9 November 2022 10:04:47 UTC