Re: [Last-Call] [EXTERNAL] Artart last call review of draft-ietf-lamps-ocsp-nonce-update-04

[Himanshu Sharma <[e-mail]>]

Thanks Jim for your time to review the Draft.
 I will work on the suggestions and update the draft accordingly.



On Mon, Apr 1, 2024 at 11:04 AM Jim Fenton via Datatracker <[e-mail]>
wrote:

> Reviewer: Jim Fenton
> Review result: Almost Ready
>
> I am the designated ART ART reviewer for
> draft-ietf-lamps-ocsp-nonce-update-04.
>
> Status: Almost ready
>
> Comments:
>
> Section 1, suggest replacing "[RFC8954] enforce the maximum" to "[RFC8954]
> limits the maximum"
>
> Section 2, suggest replacing "enforce" with "limit".
>
> Section 2.1 paragraph 1 can be deleted since this is replacing RFC8954 in
> its
> entirety.
>
> Section 2.1 paragraph 3: "An OCSP client that implements this document
> SHOULD
> use a minimum length of 32 octets..." while RFC 8954 says, "Newer OCSP
> clients
> that support this document MUST use a length of 32 octets..." It seems like
> this requirement has been weakened; is there a reason for that? Also in
> that
> paragraph, rather than "in excess of what is permitted by RFC 8954" suggest
> saying "in excess of the limit of 32 octets that was specified in RFC
> 8954."
>
> Section 2.1 paragraph 4: replace "...MUST accept Nonce octets length of at
> least 16 octets..." with "...MUST accept Nonce lengths of at least 16
> octets..."
>
> Section 2.1 paragraph 5: replace "Nonce octet length" with "Nonce length"
>
> In the example, the object identifier, in addition to Offset and Length,
> is in
> decimal.
>
> I don't have the expertise in ASN.1 to fully review Appendix A; hopefully
> another reviewer can check that.
>
> IDNITS points out that you have a normative reference to RFC 5912, which is
> informational. I'm not sure the reference is really normative, though.
>
>
>