Updates to the CDDL grammar of RFC 8610
draft-ietf-cbor-update-8610-grammar-06

Thank you to Yaron Sheffer for his security area review.  Thank you also for the start of the discussion of update vs bis and I appreciate Carsten's response. I agree the plan should be to roll the updates into a bis draft sometime soon.  I don't know if there is a way to ensure this happens sometime in the near future.  Maybe a milestone on the working group charter?

# Éric Vyncke, INT AD, comments for draft-ietf-cbor-update-8610-grammar-05

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Christian Amsüss for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 2.1

In figure 1 caption, "Old ABNF for ..." is vague. Suggest replacing it by "RFC 8610 ABNF for ..." Also applicable to other figures through the I-D. See also figure 7, which did it right IMHO.

The reader, like myself, has to guess that the two updates are limited to figures 2 and 4. Suggestion: make it clear that figure 2 updates the figure blabla of RFC 8610 and the same for figure 4.

## Section 2.2

I am far away from ABNF, but is the meaning of 'production" clear in `separate productions` ? 

I read this section twice: it seems that no updates are specified to RFC 8610. If this is the case, then I wonder why having this section (either remove or move in appendix ?), else it is unclear what the updates are (please be clear).

## Section 3.1

`we extend the grammar` who is the "we" in the sentence (author, WG, IETF) ? Please be specific or use the passive voice. E.g., "The grammar, as in figure 11, is extended", which is also more assertive

## Section 4

`are not believed to create additional security considerations` while I appreciate the author's cautious phrasing, let's be more assertive.

## Appendix A

`This appendix is normative.` is highly unusual as appendixes are usually informative only. As section 2 is rather unclear about what are the updates, I suggest moving appendix A in the middle part of the I-D (even of RFC 8610 put it in appendix...) and also being clear that this section replace the appendix of RFC 8610.

Have to agree with Deb and others that a bis draft that updates RFC 8610 and RFC 9165 would be nice.

Thank you to Roni Even for the GENART review.

Thanks to Gonzalo Salgueiro for his ARTART review.

I concur with Eric's comment about Appendix A.  Another option is just to remove the "normative" remark; the rest of the document's sections normatively effect the change you want, and Appendix A is just a summary of those.

I also concur with Deb and Mahesh's remark about the "updates"/bis question.

It would be nice of the Security Considerations could give some advise on preventing issues during the imminent "confusion" phase when mixed tools are used.

Is there really no security issue if any of these grammar modifications are involved with usernames, passwords or other parsed user input ?