A Profile for RPKI Signed Checklists (RSCs)
draft-ietf-sidrops-rpki-rsc-11

# Internet AD comments for {draft-ietf-sidrops-rpki-rsc-10}
CC @ekline

## Comments

### S7,8

* Should there be any text about implementations validating that the value
  of fileName doesn't cause the implementation to examine files outside of
  a scoped set of directories, as an operational policy matter?

## Nits

### S4.2.1

* "constisting" -> "consisting"

fileName field is clarified as:

   *  MUST contain only characters specified in the Portable Filename
      Character Set as defined in [POSIX].

   *  MUST be unique with respect to the other FileNameAndHash elements
      of checkList for which the fileName field is also present.

but earlier we had PortableFilename as:

     IA5String (FROM("a".."z" | "A".."Z" | "0".."9" | "." | "_" | "-"))

Is there a reason these two are not defined with the same constraints? (or is that
the POSIX constraint, if so why not describe it both in the same way ?)

NITS:

        The IANA has permanently allocated

remove "permanently" ?

        conatained

contained

SAFI is not expanded on first use.

Thank you to Donald Eastlake for the SECDIR review.

** Section 6.  I don’t fully understand the use case motivating the RSC, hence this question.  The significance of how certain blobs to be verified come to be named or not, and how this information is shared between creator and verifier of the checklist was not clear to me either.  Would a verifier know for what blobs to enable or disable “filename-aware” mode?  Could there be case where a checklist has a blob without a filename, but the verifier of the blob keeps it in a named file anyway and would also need to remember to strip that filename when starting step 1?

** Section 7.

If a fileName field is present, but no referenced digital object has
   a filename that matches the content of that field, ...

When should this guidance be executed?  Is that part of the validation process in Section 6?

** Typos:
-- Section 4.2 s/conatained/contained/
-- Section 4.2.1. s/constisting/consisting/
-- Section 6. s/acording /according/

# Éric Vyncke, INT AD, comments for draft-ietf-sidrops-rpki-rsc-10

CC @evyncke

Thank you for the work put into this document. I appreciated the humor at the end of section 2.

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

Special thanks to Keyur Patel for the shepherd's detailed write-up including the WG consensus but missing the justification of the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric
## COMMENTS

### Section 4.2.2

Just for my own curiosity, what is the reason to mandate an order in the AFI? While the addresses, within an address family, do not need to be sorted 

### POSIX reference

IMHO, POSIX should be normative as it is part of a MUST sentence in section 4.4.1

## 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. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

# GEN AD review of draft-ietf-sidrops-rpki-rsc-10

CC @larseggert

Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/osm7kWl75K8S6I4tvWACqYSrKuc).

## Comments

### DOWNREFs

DOWNREF from this Standards Track doc to
`[IANA.ADDRESS-FAMILY-NUMBERS]`, which is a URL.

I think this normative reference should be to the RFCs that created the
registries, i.e., [RFC2453][RFC2677][RFC2858].

## 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.

### Typos

#### Section 4.2, paragraph 7
```
-    specification conatained in [RFC3779] may enable implementors to
-                     -
```

#### Section 4.2.1, paragraph 1
```
-    ConstrainedASIdentifiers is a SEQUENCE, constisting of a single field
-                                                -
```

#### Section 6, paragraph 2
```
-    *  The RSC MUST be validated acording to the procedure described in
+    *  The RSC MUST be validated according to the procedure described in
+                                  +
```

#### Section 10.5, paragraph 3
```
-    registation to the "Media Types" registry and to reference the RFC
+    registration to the "Media Types" registry and to reference the RFC
+          +
```

### Grammar/style

#### Section 5, paragraph 4
```
ue, otherwise verification MUST fail and the error SHOULD be reported to the
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6, paragraph 6
```
ASCII, UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such o
                                     ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 8, paragraph 1
```
icitly referenced object might not be a RSC, it might never have been publish
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 8, paragraph 1
```
t might not be a RSC, it might never have been published, or was revoked befo
                               ^^^^^^^^^^^^^^^
```
The adverb "never" is usually put between "have" and "been".

#### Section 8, paragraph 2
```
without access to a given RSC. While an one-time-use EE Certificate must only
                                     ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

## 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

Thanks for tidying up the IANA Considerations.

The answer to question 11 of the shepherd writeup is not complete.

Thanks to Russ Housley for his ARTART review.

I find the "SHOULD be aware" in Section 4.2 to be curious.  How does an implementer satisfy the "aware" condition?

Regarding the "SHOULD" in Section 7, I suggest including some advice about what other action an implementer might choose to take, and why.

Thanks for this document.  Just a couple of minor/nit level comments:

Minor level comments:

(1) p 6, sec 4.4.1.  FileNameAndHash

Should this section provide any additional text to describe what the hash field is?



Nit level comments:

(2) p 3, sec 2.  RSC Profile and Distribution

   What constitutes suitable transport for RSC files is deliberately
   unspecified.  It might be a USB stick, a web interface secured with
   conventional HTTPS, PGP-signed email, a T-shirt printed with a QR
   code, or a carrier pigeon.

Perhaps:  "For example, it might be ..." or otherwise someone might incorrectly interpret this as ruling out other transport mechanisms, such as a drone based light show.

Thanks,
Rob