Skip to main content

YAML Media Type
draft-ietf-httpapi-yaml-mediatypes-10

Yes

Zaheduzzaman Sarker

No Objection

Andrew Alston
Jim Guichard
John Scudder
Paul Wouters
Robert Wilton

Note: This ballot was opened for revision 06 and is now closed.

Murray Kucherawy
Yes
Comment (2023-05-24 for -06) Sent
Nice work.

Thanks to Barry Leiba for his ARTART review, and to Darrel Miller for a good shepherd writeup.
Zaheduzzaman Sarker
Yes
Andrew Alston
No Objection
Erik Kline
No Objection
Comment (2023-05-21 for -06) Sent
# Internet AD comments for draft-ietf-httpapi-yaml-mediatypes-06
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

### S4.1

* Even though the document is Informational, S1.1 introduces the RFC 2119 and
  RFC 8174 keywords (which I find helpful for expressing intent irrespective
  of the document's intended status).

  With that in mind, I think this could be capitalised:

  "Code execution in deserializers should be disabled by default" ->
  "Code execution in deserializers SHOULD be disabled by default"
Jim Guichard
No Objection
John Scudder
No Objection
Lars Eggert
No Objection
Comment (2023-05-25 for -06) Sent
# GEN AD review of draft-ietf-httpapi-yaml-mediatypes-06

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/o9UaFCXheaEmcZM-2Vw9RWuFI8Q).

## Comments

### Boilerplate

Document has Informational status, but uses the RFC2119 keywords "SHOULD",
"MAY", and "SHOULD NOT". Given how they are used, that may not be necessary?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
   `intrinsic`, `original`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 3.4, paragraph 7
```
lues not supported in JSON in a multi- document YAML stream 3.5. Fragment ide
                                ^^^^^^^^^^^^^^^
```
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

#### Section 3.5, paragraph 4
```
o improper behaviors (such as the "billion laughs" or "Exponential Entity Exp
                                   ^^^^^^^
```
Use "a billion", or use a number before "billion".

#### "A.1.", paragraph 1
```
 has some security implications too (eg. wrt on identifying parsers or treat
                                     ^^^
```
The abbreviation "e.g." (= for example) requires two periods.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
Paul Wouters
No Objection
Robert Wilton
No Objection
Roman Danyliw
No Objection
Comment (2023-05-24 for -06) Sent
Thank you to Shawn Emery for the SECDIR review.

** Section 1.2.1
In the example resource below, the URL file.yaml#*foo references the
   first alias node *foo pointing to the node with value scalar and not
   the one in the second document; whereas the URL file.yaml#*document_2
   references the root node of the second document { one: [a,
   sequence]}.

Are “file.yaml#*foo” and “file.yaml#*document_2” valid URLs?  There is no scheme or authority.

** Consider leaving the FAQ in the final RFC.  I believe it has archival value in explain design decisions.

** For the responsible AD evaluate:  The following are crucial normative references (especially [YAML]), however they are DOWNREFs not called out in IETF Last Call.

[YAML]    Oren Ben-Kiki, Clark Evans, Ingy dot Net, Tina Müller,
             Pantelis Antoniou, Eemeli Aro, and Thomas Smith, "YAML
             Ain't Markup Language Version 1.2", 1 October 2021,
             <https://yaml.org/spec/1.2.2/>.
[OAS]     Darrel Miller, Jeremy Whitlock, Marsh Gardiner, Mike
             Ralphson, Ron Ratovsky, and Uri Sarid, "OpenAPI
             Specification 3.0.0", 26 July 2017.