Online Certificate Status Protocol (OCSP) Nonce Extension
draft-ietf-lamps-ocsp-nonce-update-11

Thanks for the work done in this document.

About `An OCSP client that implements this document MUST use a minimum length of 32 octets for Nonce octets in the Nonce extension.`

1) should this MUST also appears somehow in the abstract ?

2) why not using `Nonce ::= OCTET STRING(SIZE(32..128))` ? to be consistent with the above MUST

Thanks to Susan Harris for her OPSDIR review. Although most of her comments were characterized as NITs, I feel they should be addressed. Specifically, and I know that more RFC were cited to explain OIDs in ASN.1, it was still not clear (to me) the correlation between the octet string and the values in the object identifier.

Section 2.1, paragraph 3
>    An OCSP responder that implements this document MUST reject any OCSP
>    request that has a Nonce with a length of either 0 octets or more
>    than 128 octets, with the malformedRequest OCSPResponseStatus as
>    described in Section 4.2.1 of [RFC6960].  Responders, supporting the
>    Nonce extension, MUST accept Nonce lengths of at least 16 octets and
>    MAY choose to ignore the Nonce extension for requests where the
>    length of the Nonce is less than 16 octets or more than 32 octets.

I also support Paul's DISCUSS.

No reference entries found for these items, which were mentioned in the text:
[1], [2], and [0]. Note, xml2rfc interprets anything within a square bracket
to be a reference that needs to be cited in the normative/informative list.

# Internet AD comments for draft-ietf-lamps-ocsp-nonce-update-07
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S2.1

* I'm sure I must be confused, but I don't understand why this document says
  that OCSP responders supporting the Nonce extension MAY choose to ignore
  requests with lengths of the Nonce extension greater than 32 octets.

  It seems like the document is saying "clients: you can send up to 128;
  responders: drop things larger than 32 if you want".

  But I'm sure I must be misunderstanding something.

Thanks to Jim Fenton for his ARTART reviews (plural!).