[SCITT] Éric Vyncke's Discuss on draft-ietf-scitt-scrapi-10: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-scitt-scrapi-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke INT AD comments for draft-ietf-scitt-scrapi-10
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

Special thanks to Amaury Chamayou for the shepherd's 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

Note: this ballot comments follow the Markdown syntax of
https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
a tool to create github issues.

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Section 2

Is there any constrain in which language is the `human-readable` ? MUST it be
US English ? It may be implicit due to HTTP protocol though, then I will
obviously stand corrected.

### Use of SHOULD

There are several `SHOULD` in the document that could easily be a `MUST`. E.g.,
section 2 `Clients SHOULD treat`, section 2.1 `SHOULD include Accept:
application/cbor in the request`. So, either change the `SHOULD` in `MUST` or
provide guidance when the `SHOULD` can be bypassed. Currently, it is really
ambiguous.

See also
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS (non-blocking)

### Med's DISCUSS

I support Med Boucadair's DISCUSS point about the apparent conflict between
`MUST` and `MAY`.

### Abstract

s/This document describes/This document *specifies*/ as this I-D aims for PS.

### Section 1

`The following resources MUST be implemented for conformance to this
specification`, unsure whether the IETF is in the business of defining
"conformance". Also, as all the refered sections are normative, this paragraph
is fully redundant.

### Section 2

In the HTML rendering, it is unclear whether `* title:` is part of the numbered
list just above. It also needs some leading text.