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

[Ben Campbell <[e-mail]>]

Oops, I forgot two more minor editorial comments. This does not change the last call status.

- Abstract: The abstract should not contain citations. It’s okay to mention an RFC number, but don’t put it in brackets like a citation would be in the body.

- It needs a normative reverence to RFC 8174.

Thanks!

Ben.

> On Jan 30, 2019, at 5:02 PM, Ben Campbell <[e-mail]> wrote:
> 
> Hi Roland,
> 
> I think this version is ready for IETF Last Call. I will request that shortly.
> 
> I still have some minor editorial comments below. These can be addressed along with any IETF LC feedback.
> 
> Thanks!
> 
> Ben.
> 
>> On Jan 14, 2019, at 5:29 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Signed PGP part
>> Apologies for the late response. I somehow missed seeing your response until now. Comments inline. I removed sections that seem resolved.
>> 
>> Please submit a new revision as soon as you are ready.
>> 
>> Thanks!
>> 
>> Ben.
>> 
>>> On Nov 30, 2018, at 4:38 AM, [e-mail] wrote:
>>> 
>>>> 
>> 
>> [...]
>> 
>>>> *** 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?
>>>> 
>>> [RJ] Yes
> 
> I think it would be worth mentioning that in the draft.
> 
> […]
> 
>> 
>>>> 
>>>> §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.
>>> 
>>> [RJ] I would propose to delete then the first sentence.
>>> Thus the considerations would state:
>>> While the addition of the location parameter
>>>  does provide an indicator of the entity that added the location in
>>>  the signaling path this provides little more exposure than the
>>>  [Q.850] cause itself.
>>> 
>>> I could add:
>>> When applying privacy according to RFC 3323 the location value will not give any hint to the identity originating or terminating party of the call. It shows only the location of the release of the call which maybe the end device itself (location user) or any other network part.
>>> The location is even not showing from which city or town the call is coming from.
>>> 
>>> Would this be enough?
>> 
>> If the call was released by the end device, does that not let people infer information about the original callee, if that device can be associated with the callee?
> 
> I think we’ve resolved that part, but looking at the new language:
> 
> "When applying privacy according to [RFC3323] the location value will not give any hint to the identity originating or terminating party of the call. It shows only the location of the release of the call which maybe the end device itself (location user) or any other network part. The location is even not showing from which city or town the call is coming from."
> 
> I think readers will still get confused by the use of “location” to describe something that’s not a “physical” location. I think it would help in this sentence to clarify that we are talking about “ISUP location”. Also, the is the use of RFC 3323 really relevant? That is, I don’t think the ISUP location reveals the identity one way or another, right? It’s not up to this draft to worry about whether some other part of the SIP message does.
> 
> Finally, there are some minor grammar issues. I propose the following simplification:
> 
> “The ISUP location value itself will not reveal the identity of the originating or terminating party of the call.  It shows only the ISUP network location of the device that released the call. The ISUP location does not show show the physical location of the caller or callee.”
> 
> (Nit) §7, new text: I propose the following edit:
> 
> OLD:
> "[RFC3398] does an extensive security consideration due to
>   interworking between ISUP and SIP.”
> NEW:
> "[RFC3398] describes detailed security consideration due to
>   interworking between ISUP and SIP."