Re: [Sipping-tispan] Re: TIP/TIR requirements

[Miguel Garcia <[e-mail]>]

Hi Jeroen:

See inline comments.

Bemmel, Jeroen van (Jeroen) wrote:


> REQ-TIP-1 : I think this should be stated as a requirement, without refering to any particular mechanism (SIP response)
> Proposed rewording: "When the TIP service is enabled, the identity of the terminating party MUST be presented to the caller"

No, I think your word deviates from the spirit of the requirement. The 
spirit of the requirement is that the callee ***selects*** this identity 
to be presented. Your wording does not reflect that user selection.

> 
> REQ-TIP-3: Instead of saying that it is not asserted by the network, I would propose the following wording:
> "The identity mentioned in REQ-TIP-1 MUST be supplied by the callee and MUST be forwarded transparently by the network"

If we keep REQ-TIP-1 as is, I don't need to indicate here that the 
identiy is supplied by the callee. And the forwarded transparently by 
the network it is implicitly indicated in the current text when it is 
said that "is not asserted by the network".

Honestly speaking, I don't see the point in changing the wording.

> 
> In addition, I think there are several requirements missing here:
> REQ-TIP-4: "The terminating identity MUST uniquely identify the terminating party, and MUST be usable to contact this party directly for future communications". The period of validity is subject to discussion

In my opinion this requirement will indicate that there must be a 
mechanism for the network to assess the uniqueness of this identity, 
which is not the case. This is an additional identity selected by the 
user. If the user chooses a non-unique or non-routable identity, it is 
not our problem. As far as the service is concerned, there are no 
further requirements than "give me an identity and I will transport to 
the caller".

> 
> In solution terms this rules out private IP addresses, and public IP addresses allocated dynamically (e.g. through DHCP) would need to be valid for a sufficiently long period of time (when used).
> 
> For TIR:
> REQ-TIR-1: "When the TIR service is enabled, the originating party MUST NOT receive any information that can be used to uniquely identify (and contact) the terminating party"

So are you planning to obfuscate the Contact header?

> 
> In solution terms this leads to a B2BUA-based approach, since the last Via header, the Contact header and potentially other headers all contain information about the terminating party. 

Exactly... which is not what this service requires.

/Miguel

> 
> Regards,
> 
> Jeroen van Bemmel, Lucent
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan