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

[Chris Wendt <[e-mail]>]

Hi Christer,

Thanks for your detailed editorial review.

Comments inline:

> On May 27, 2022, at 6:57 AM, Christer Holmberg <christer.holmberg=[e-mail]> wrote:
> 
> Hi,
> 
> I took a look at the draft.
> 
> My first comment is that I really think it could need a proper editorial review.
> 
> I will comment on some of the things I found, mostly focusing on the generic parts of the document.
> 
> GENERAL:
> -------------
> 
> Q1: Please use consistent terminology. As a simple example, please use either "this document" or "this specification". The same goes for "specifies" and "documents". 
> 

I did clean this up and make it more consistent, i used “document" to refer to the document itself, but kept specifications when referring to other specifications.

> 
> Q2: The document tries to be protocol agnostic. Still, in most cases the procedures are SIP specific, referring to SIP header fields, parameters etc. In some cases there is text like "or something similar in other protocols", but in some cases there is not. Similar to the comment I gave on the messaging draft, is there a reason why this draft cannot be scoped to SIP?
> 

We absolutely do not want to limit this specification to SIP, i did review the document and make sure that there isn’t any implication other than some of the SIP examples and SIP specific issues that this is the case.

> 
> ABSTRACT:
> ---------------
> 
> Q3: I think the Abstract is too long. The first half would be enough, in my opinion. The rest is too detailed and should go elsewhere.
> 
Agree, and i did simplify and remove unnecessary detail.

> 
> Q4:
> 
> The text says:
> 
>   "The JSON element defined for this purpose, Rich Call Data (RCD), is an extensible object
>   defined to either be used as part of STIR or with SIP Call-Info..."
> 
> How is this used with SIP Call-Info? When reading draft-ietf-sipcore-callinfo-rcd, the only thing I can find is a string
> value that saying things like "For your ears only". I assume the JSON object will be stringified and added as a Call-Info call-reason value, so
> it would be nice to have some examples of that.

I agree that wasn’t clear, but to the point of your comment in Q3, i just deleted it.

> 
> 
> SECTION 1:
> ---------------
> 
> Q5:
> 
> The text says:
> 
> "The STIR problem statement [RFC7340] declared securing the display name
> of callers outside of STIR's initial scope, so baseline STIR provides
> no features for caller name."
> 
> I assume this applies to most/all extensions, so I am not sure it needs to be stated. At least the second part after the comma could be removed, in my opinion.

Agree, removed after comma.

> 
> 
> Q6:
> 
> The text says:
> 
>   "As such, the baseline use-case for this document extends PASSporT to
>   provide cryptographic protection for the "display-name" field of SIP
>   requests as well as further "rich call data" (RCD) about the caller,
>   which includes the contents of the Call-Info header field or other
>   data structures that can be added to the PASSporT."
> 
> What does "the use-case for this document extends" mean? I think what you want to say is that "based on some use-case, this document extends".

Agree, replaced text.

> 
> 
> Q7:
> 
> The text says:
> 
>   "This document furthermore specifies a third-party profile..."
> 
> What is this "third-party profile"? I assume this has something to do with Section 12, but it is not very clear.
> 

Yes, i reworded as follows: "This document furthermore documents third-party use-cases that would allow external third-party authorities to convey rich information associated with a calling number via a "rcd" PASSporT that asserts the third-party as the source of the Rich Call Data information."

> 
> Q8:
> 
> The text says:
> 
> "This specification documents an optional mechanism for PASSporT and the associated STIR procedures
>  which extend PASSporT objects to protect additional elements conveying richer information:"
> 
> This sentence is difficult to read. I think it is enough to say that the document defines a PASSporT extension, and the
> associated STIR procedures, to protect...

Agree, replaced.

> 
> 
> Q9:
> 
> The text says:
> 
> "information that is intended to be rendered to assist a called party in determining whether to accept or
>  trust incoming communications."
> 
> I think core PASSporT already contains information (e.g., the phone number) that is intended to be rendered, so perhaps talking about "additional information".

Agree, replaced with the following: "additional information that is intended to be rendered to assist a called party in determining whether to accept or trust incoming communications”

> 
> Also, not all information will be rendered as such. For example, I assume URLs will normally not be rendered, but rather the information (pictures etc) that can be
> fetched using the URLs.

Correct, URLs point to content that will be retrieved.  But ultimately if the URL content is retrieved the intension i assume would be to render (or display) it to the end-user on the end-user device.

> 
> 
> SECTION 3:
> ---------------
> 
> Q10:
> 
> The text says:
> 
>   "The main intended use of the signing of Rich Call Data (RCD) using
>   STIR within SIP [RFC8224] or more generally as a PASSporT extension
>   [RFC8225] is for the entity that originates a call, either directly
>   the caller themselves, if they are authoritative, or a service
>   provider or third-party service that may be authoritative over the
>   rich call data on behalf of the caller."
> 
> I can't parse this 6 line sentence. The main intended use seems to be many things...

Agree, i replaced this entire paragraph with the following: "This document defines Rich Call Data (RCD) which is a PASSporT extension {{RFC8225}} that defines an extensible claim for asserting information about the call beyond the telephone number. This includes information such as more detailed information about the calling party or calling number being presented or the purpose of the call. There are many use-cases that will be described in this document around the entities responsible for the signing and integrity of this information whether it is the entity that originates a call or a service provider acting on behalf of a caller or use-cases where third-party services may be authoritative over the rich call data on behalf of the caller."

> 
> 
> Q11:
> 
> The text says:
> 
>   "Additionally, in relation to the description of the specific
>   communications event itself (versus the identity description in
>   previous paragraph), [I-D.ietf-sipcore-callinfo-rcd] also describes a
>   "call-reason" parameter intended for description of the intent or
>   reason for a particular call.  A new PASSporT claim "crn", or call
>   reason, can contain the string or object that describes the intent of
>   the call."
> 
> What is means by "object"? When I read [I-D.ietf-sipcore-callinfo-rcd] I can only see human readable string values in the call-reason examples.
> 

Agree, Jack also had same comment and i did fix it to just be a string.

> 
> SECTION 9:
> ---------------
> 
> Q12:
> 
> The text says:
> 
>   "Either or both the "rcd" or "crn" claims may appear in any PASSporT claims object as optional elements."
> 
> Is it within the scope of this document to define what other PASSporT claims can contain?

This is essentially stating a property of JSON, JWTs and PASSporTs more generally, you can include any JSON key value pairs, it’s up to the recipient to know how to use that key value pair.

I think the relevant bit is paired with the next sentence that if you want the PASSporT to be a “rcd” PASSporT, it MUST include either/both “rcd” and “crn” claims.  But the first sentence just says that the use of claims defined in this document don’t mandate that the PASSporT is “rcd”.


> 
> 
> SECTION 10.1:
> -------------------
> 
> Q13:
> 
>   "For re-construction of the "nam" claim the string for the display-name in the From header field."
> 
> What if there is no From header field?
> 
> This is an example of my general comment about whether the document should be scoped to SIP.

I did try to address this corresponding to my response in Q1


> 
> ---
> 
> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir