Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-spam - Christer's comments

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Feb 2018 17:40:22 +0000

Hi,

Below is my WGLC review.

SUMMARY:

In general everything looks good. I do have some comments, but they are mostly editorial.

GENERAL:

Q1: The draft uses both "called party" and "receiving party" terminology. Please use consistent terminology. Similar with "calling party", "caller", "call initiator".

Q2: The draft uses lower case key words (e.g., "may"). Unless they are meant to be upper case, I suggest to use non-key words (e.g., "might" or "can"). Just to save you from the same comments once the document is reviewed by Ben :)

ABSTRACT:

Q3: s/Call-Info parameters/Call-Info header field parameters

Q4: s/feature tag/feature-capability indicator

INTRODUCTION:

Q5: s/we describe/the document describes

Q6: 
The text says:

   "Providers may also find the SIP Priority header ([RFC3261],
   Section 20.26) field useful in helping called parties decide how to
   respond to an incoming call."

But, the Priority header field is not mentioned anywhere else in the document. If you want to keep the text you should say something like:

"However, the usage of the Priority header field is outside the scope of this document."

Q7:
The text says:

   "The SIP provider serving the called party MUST remove any parameters
   enumerated in this specification that it does not trust."

Can "enumerated" be "described", in order to have consistent terminology?

Q8:
The text says:

   "The Call-Info header field MAY be signed using a future "ppt" extension to
   [I-D.ietf-stir-rfc4474bis]."

I don't you can use upper case MAY and then talk about the future. Also, "ppt" is defined in draft-ietf-stir-passport.

I suggest something like:

  "[draft-ietf-stir-passport] defines a mechanism for signing SIP information elements. A future specification might 
   define a "ppt" extension for signing the Call-Info header field."

SECTION 3:

Q9: s/feature capability indicator/feature-capability indicator

Q10: When you talk about what UAs, proxies and B2BUAs MUST do/support, you should say UAs/B2BUAs/proxies supporting the feature/mechanism defined in this document.

SECTION 6.2:

Q11: There is no description of the INVITE example, and what it shows.

Regards,

Christer