Re: [stir] WGLC: draft-ietf-stir-passport-rcd-09

Hi,

I think version 17 is in pretty good shape, and I think we’ve handled the “hard” problems. I have some mostly minor comments There are a few that I probably should have noticed on previous versions. Hopefully they don’t fall too far outside of Russ’s guidance for feedback, and in any case I don’t think they are showstoppers:

Substantive:

§3, 2nd paragraph: This should probably mention “icn” in the first category, since it is separate from jCard data.

§6.1.2: “Even though this is probably not the typical case, an "rcdi" JSON pointer or integrity digest is optional if the image value is directly included via a data URI.”

Apologies, I should have caught this one in an earlier version. But wouldn’t a data: URL typically point to a body part that is not covered by the PASSporT signature? If so, it could be subject to tampering in route. Would that need integrity protection less than a HTTPS URL? I guess tampering would require an on-path attacker. But I am still skeptical of the exception unless the data: URL points to data covered by the PASSporT signature.

$9.3: Third example: Some of the examples shows a jcard photo and logo URIs, but no “icn” keys. Given the guidance to use “icn” for a default image, should “icn” keys be included?

§14.2, 2nd paragraph: “Similarly, the "jcd" or linked "jcl" jcard information and "crn" can be optionally, based on local policy for devices that support it, used to populate a Call-Info header field following the format of [I-D.ietf-sipcore-callinfo-rcd].”

Should this mention “icn”?

§18 (Apologies, these are probably things I missed in previous versions:

First paragrapoh: The normative MUST seems dubious. Can we assert normative requirements to ecosystems we don’t control?

Third paragraph: “may be a recommended way “. I suggest “may be a useful way” or “is a recommended way”.

Editorial comments:

§4, 3rd paragraph: “pass-by-value or passed-by-reference;”
Inconsistent use of “pass” vs “passed”. Either is okay, but we should pick one.

§4, table, first row, 2nd column: s/RDC/RCD

§5.1.1: “If there is no string associated with a display name, the claim value MUST then be an empty string.”
Should “claim value” be “key value”?

> On Apr 25, 2022, at 2:51 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> This might be the longest WG Last Call in history ....
> 
> A new version was just posted: https://www.ietf.org/id/draft-ietf-stir-passport-rcd-17.txt
> 
> Regarding the ongoing WG Last Call, we have two questions:
> 
> (1) Have any of the changes introduced new issues?
> 
> (2) Have all previously raised issues are resolved?
> 
> For the STIR WG Chairs,
>  Russ
> 
> 
>> On Dec 8, 2020, at 4:30 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
>> 
>> This is a WGLC for draft-ietf-stir-passport-rcd-09.
>> 
>> Please send reviews to the list by the end of day 22 Dec 2020.
>> 
>> If you plan to provide a review but need more time, please let us know early.
>> 
>> See <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/>
>> 
>> RjS
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir