PASSporT Extension for Rich Call Data
draft-ietf-stir-passport-rcd-26

Thank you for the work on this document.

Many thanks to Harald Alvestrand for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/rylz9YIkzKVh0MS7zVQJnWTD5Tc/, and to the authors for addressing his comments.

Thanks for this document, it seems thorough and well-written, as far as this non-expert can tell. I have just a few nit-level things to mention.

1. In Section 4, "This mechanism is inspired by and based on the W3C Subresource Integrity specification (http://www.w3.org/TR/SRI/)." Instead of listing the URL inline, that seems like it really should be a reference. 

2. Section 4, first paragraph, "what data is allowed to be used". Shouldn't that be "data are"? (I said these were nits...)

3. Section 4, last para, "The third and fourth mode cover cases", should be "modes".

That's it. Yours for agreement in number.

# Sec AD review of  draft-ietf-stir-passport-rcd-23

CC @paulwouters

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

This review uses the format specified in https://github.com/mnot/ietf-comments/
which allows automated tools to process items (eg to produce github issues)

Please see Roman's raised issues. Additionally, I have a few very minor comments.

## Comments

### Section 8.3 example

the example there has a jCard with:

       ["org",{},"text","MI6;Q Branch Spy Gadgets"],

and a corresponding PASSporT claims object with:

     "nam": "Q Branch Spy Gadgets",

I wasn't sure if the org text and nam of the issuer needed to match here, so I just wanted to raise it in case this is a copy&paste error.

## odd modifier to 2119 language

I am not sure how to read:
```
        is likely NOT RECOMMENDED best practice.
```

It seems it should either not use RFC 2119 phrasing, or it should remove the
modifier "likely".

### NITS

[3GPP TS 24.229 v16.7.0] is not rendered into a proper reference

There is a few ways -> There are a few ways

Section 16 references "the IANA", instead of just "IANA".

Thank you to Vincent Roca for the SECDIR review

Thank you for addressing my DISCUSS and COMMENT feedback.

# Éric Vyncke, INT AD, comments for draft-ietf-stir-passport-rcd-23
CC @evyncke

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), and some nits.

Special thanks to Russ Housley for the shepherd's detailed write-up including the WG consensus *but* the justification of the intended status is missing. 

Other thanks to Florian Obser for the DNS directorate Last Call review: https://mailarchive.ietf.org/arch/msg/dnsdir/Fv-pKTtPyHLVXYDD2phBfvab9nc/ Thank you, Chris, for your reply on the mailing list.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### MAY NOT

As indicated by idnits:
```
     The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used. 
```

### Section 1

`In this document, we utilize` suggest not to use the first person when writing a specification.

### Section 5.1.1 and 3GPP Releases

Rather than "3GPP TS 24.229 v16.7.0", should 3GPP release v17 be used ?

### Section 5.1.3

Suggest to use "https://wwww.example.com/alice/photo.jpg" rather than "http://wwww.example.com/alice/photo.jpg", i.e., use HTTPS as in other examples.

### Section 6

Suggest to provide a reference either to the NIST specification or to the different SHA variations.

Should there be a registry for all those algorithms in order to facilitate interoperation  ? (to be honest, I hesitated to ballot a DISCUSS on this point)

### Section 6.1.3

I love your James Bond's example ;-)

### Section Shocking !

Alas, there is no April 1st DISCUSS else I would have balloted a DISCUSS on "Her Majesty" as it is now "His Majesty" ;-) ;-)

## NITS

### Section 1

Even if "JWT" is in the list of accepted abbreviations by the RFC editor, it may be worth to expand it at first use. Same for "STIR" (or use "STIR WG") ;-)

Also in this section there is at least one sentence that is 7 lines long... this does not help the readability of the document. It also occurs in multiple places in the I-D.

### E.g.

AFAIK, "e.g." is always followed by a comma. Same for "i.e.".

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