Re: AD Review of draft-ietf-httpbis-client-cert-field-04

Hi Francesca,

I've submitted a -05 that incorporates this and Genart review feedback:
https://lists.w3.org/Archives/Public/ietf-http-wg/2023JanMar/0185.html



On Tue, Feb 7, 2023 at 3:28 PM Brian Campbell <bcampbell@pingidentity.com>
wrote:

> Thanks Francesca,
>
> Some followup comments/questions are inline below.
>
> On Mon, Feb 6, 2023 at 9:42 AM Francesca Palombini <
> francesca.palombini@ericsson.com> wrote:
>
>> # AD Review of draft-ietf-httpbis-client-cert-field-04
>>
>> cc @fpalombini
>>
>>
>>
>> Thank you for this document.
>>
>>
>>
>> No major comments from me, only one comment around a normative MUST and
>> some nits, which you can address together with any other last call comments.
>>
>>
>>
>> I also note that the consensus of the wg is for it to be informational,
>> which is fine since I understand this document is meant to be the reference
>> specification for two IANA registrations that are "specification required",
>> but it read to me as a standard track doc. As the wg has discussed and
>> gotten consensus around informational, I don't expect any change, just
>> bringing it up one last time before LC since I expect there might be more
>> comments in LC and IESG eval.
>>
>>
>>
>> ## Comments
>>
>>
>>
>> ### MUST prevent unintended use
>>
>>
>>
>> Section 4:
>>
>> > Therefore, steps MUST be taken to prevent unintended use, both in
>> sending the header field and in relying on its value.
>>
>>
>>
>> This might simply be a formulation problem, but when I read it I am not
>> sure this is a MUST the reader will know how to implement.
>>
>
> The idea with that sentence was that the 'how' is described in the rest of
> the section. The keyword MUST probably isn't appropriate there. And a bit
> more context might be useful too. Would changing it to this sentence
> address that formulation problem? Or maybe I'm missing your point...
>
> "Therefore, steps such as those described below need to be taken to
> prevent unintended use, both in sending the header field and in relying on
> its value."
>
>
>>
>>
>> ## Nits
>>
>>
>>
>> ### Editorial nits
>>
>>
>>
>> Section 4:
>>
>> > The configuration options and request sanitization are necessarily
>> functionally of the respective servers.
>>
>>
>>
>> s/necessarily functionally/necessary functions ?
>>
>
> Either works I think :) But I'll change it.
>
>
>
>> ### Considerations considered
>>
>>
>>
>> Funny title for Appendix B :) Where are the considerations not considered?
>>
>
> It was actually intended to be somewhat humorous. :)  I was trying to
> convey something like "these are some things that were considered" to
> hopefully avoid questions about whether they'd been considered. Kind of
> like a FAQ for the general approach taken by the document. Also I didn't
> feel great about other potential titles there. But I can see how the title
> doesn't look great. I know this sounds silly but I'm not sure what the
> section title should be. Maybe "Document Considerations" "General
> Considerations" or "Design Considerations"? Or something else that I'm not
> able to think of?
>
>
>
>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._