[sipcore] AD Evaluation of draft-ietf-sipcore-reason-q850-loc-04

[Ben Campbell <[e-mail]>]

Hi,

This is my AD evaluation of draft-ietf-sipcore-reason-q850-loc-04. I have some substantive and editorial comments that I would like to resolve prior to IETF last call.

Thanks!

Ben.
--------------------------

*** Substantive Comments ***

§3: “open to be used by any other network”
That would really mean “any other network that includes ISUP interworking gateways and uses Q.850 reason codes”, right?

§4:
- Figure 1: Is it possible the Q.850 location code list will ever change? if so, how will this list stay in sync? 3326 just referenced Q.850 for the reason codes; can this do the same?

- “Thus other values are not within the scope of this document.”
I’m not sure what that means. Are non-listed values forbidden? Undefined? Are they defined in _other_ documents?

- "Depending on the direction the UAC or UAS shall include the location...”
I’m not sure what that means. Does it mean “Depending on whether the message is a request or a response”?

Also, is that “shall” intended as normative?  (I suggest it not, since I assume inserting the location is optional.) Would it make sense to just say “... the UAC or UAS includes the location...”?

§6 and §7:

Unfortunately, RFC 3326 contains no privacy considerations at all, so we really can’t say that this doesn’t change them. The expectation for privacy considerations has changed since that RFC was published. I think this document does need to describe any privacy considerations that  the combination of a Q.850 reason code and location might have.

For example, can an intermediary learn anything about the end user behavior by examining them that it couldn’t learn otherwise? The answer might well be “no”, but the draft should explain the reasoning behind that.

Similarly unfortunately, the security considerations in RFC 3326 did not address ISUP interworking. Could an attacker do anything destructive or useful to the attacker by monitoring or tampering with Q.850 location information in a SIP message?

§9.1: The Header Fields Parameter sub registry also needs the “Predetermined Values” and “Reference” column filled in . I assume those values are “Yes”, and “RFCXXXX” (with XXXX replaced with the assigned RFC number), respectively.


*** Editorial Comments ***

- Header: The Updates field should just say “Updates: 3326”.

- Abstract: Please mention the update in the abstract.

§1:
- Please add a sentence of two to explain what “reason of release” means. (Should that be “reason for release”?) I know that’s in 3326--it doesn’t need detail here, but it needs enough for people to realize what you are talking about.

- 2nd sentence: The antecedent of “It” is ambiguous.

- “does specify” -> “specifies”

- The last sentence seems like a non sequitur, since this is the first mention of location. Perhaps the previous sentence could say''..., but not the Q.850 location information.

- The draft needs to elaborate on the what Q.850 represents. Otherwise, reviewers are going to assume location in the geolocation sense, and get really worried about privacy issues.

§2: Please use the new boilerplate from RFC8174, unless there is a specific reason not to.

§4:
- 2nd paragraph: s/“The mechanism employed”/“This specification “

- The second sentence has redundant Q.850 citations.

-2nd to last paragraph, "This approach is only valid in cases when the ISUP [Q.850] ocation is available.” I suspect “invalid” should be “possible” or something to that effect.

- last paragraph, “in other cases the location, if present, MUST be ignored”: I suggest “Other values MUST be ignored if present."

§5:
- First paragraph:
s/“... set up... ”/ “...sent...”
s/“... set to 1 meaning ...”/“... set to 1, meaning ..."