Re: [Insipid] Will the identifier pass unchanged through B2BUAs?

[Robert Sparks <[e-mail]>]

On 7/31/13 10:40 AM, Hadriel Kaplan wrote:
> No, there's nothing wrong with the requirements document.  My email wasn't about the requirements document, nor addressed to INSIPID - it was an email in the STIR mailing list related to using an INSIPID Session-ID for caller-id verification purposes.  That's all.
>
> The INSIPID requirements doc is fine.
Your mail, whether it was to INSIPID or not, says that INSIPIDs current 
trajectory will fail to meet the requirement in this document
(and will, in fact, fail to achieve the goal in its charter or even its 
name).

I take this response to say you believe that failure is in the proposed 
solution document, not the requirements document.

What do we need to change, then, in the proposed solution to not fail to 
meet the chartered goal (specifically the requirement called out below).

RjS
>
> -hadriel
>
>
> On Jul 31, 2013, at 3:18 AM, Robert Sparks <[e-mail]> wrote:
>
>> On 7/30/13 9:38 PM, Hadriel Kaplan wrote:
>>> Uhhh... just to be clear, I was making an individual comment in that email, not a corporate position statement or any some such.
>>>
>>> My point was that since the use-cases people are planning to do for INSIPID's Session-ID have now gone far beyond troubleshooting, the odds are we can't rely on it always being passed through end-to-end from originating Enterprises through various service providers to the far-end, without being modified in-transit.  I can't *prove* it won't be, but that's just my hunch, since we've seen this movie play out before.
>>>
>>> The good news is we don't need the Session-ID to be used in STIR for caller-id verification, so there's nothing to worry about.
>> Hadriel -
>>
>> This wasn't a question about STIR, it was a question about the publication of this INSIPID document.
>>
>> Look again at the requirement called out from the document below.
>>
>> Is your assertion that the proposed solution is not going to satisfy that requirement, or are you saying there's a problem with this requirement document being inconsistent (by requiring things that won't pass unchanged through intermediaries). If the latter, please re-engage the working group and fix the document (you are on the author list).
>>
>> RjS
>>> :)
>>>
>>> -hadriel
>>>
>>>
>>> On Jul 30, 2013, at 7:24 AM, Gonzalo Camarillo <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I just got a publication request for the requirements document:
>>>>
>>>> http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08
>>>>
>>>> The following is one of the requirements in the draft, which was one of
>>>> the main reasons for creating this WG:
>>>>
>>>>>    REQ3: The solution must require that the identifier, if present, pass
>>>>>    unchanged through SIP B2BUAs or other intermediaries.
>>>> Hadriel, who works for an important SBC vendor and is one of the authors
>>>> of the requirements document, sent the comments below to the STIR list a
>>>> couple of weeks ago (see email below).
>>>>
>>>> How should I interpret those comments in the context of my AD review of
>>>> this document and, even more importantly, as the responsible AD for this
>>>> WG (as you know, we have had many scope-related discussions in the past)?
>>>>
>>>> Thanks,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: 	Re: [stir] Rollout timeframe (was: RE: Draft STIR Charter)
>>>> Date: 	Tue, 16 Jul 2013 10:21:13 -0400
>>>> From: 	Hadriel Kaplan <[e-mail]>
>>>> To: 	Richard Shockey <[e-mail]>
>>>> CC: 	IETF STIR Mail List <[e-mail]>
>>>>
>>>>
>>>> On Jul 16, 2013, at 9:35 AM, "Richard Shockey" <[e-mail]> wrote:
>>>>
>>>>> I actually believe INSIPID is equally important to the overall task
>>>> since it
>>>>> is the track and trace elements of this that can ultimately enable some
>>>>> enforcement. I wish there was some more discussion on how the mechanisms
>>>>> would work at the edge SIP/SS7 network gateways since that clearly has
>>>> been
>>>>> the center of most of the reported problems.  I still think something
>>>> needs
>>>>> to be done to police that traffic but that is still ultimately a
>>>> regulatory
>>>>> effort.
>>>> I agree we need a tracking/tracing mechanism, but in my opinion we
>>>> cannot and should not rely on INSIPID Session-ID at all for that.  They
>>>> have gone beyond benign troubleshooting-type purposes now, which means
>>>> there is absolutely no guarantee the Session-ID will make it intact
>>>> across service providers in all cases.  In fact, my hunch is it won't.
>>>>
>>>> Regardless, the Session-ID isn't what we really need for tracing a bad
>>>> caller-id call.  Even without Session-ID, the service provider's CDRs or
>>>> logs can be used to trace it back to the peering connection and peer
>>>> upstream provider the call came in from.  What we also need is a list of
>>>> SPIDs the call request has crossed through, so we can trace it back
>>>> further upstream.  Kinda like a Via header, but with very different
>>>> properties and purpose.  We've talked about doing that before, back when
>>>> there was talk about creating a registry of SPIDs.  What ever happened
>>>> to having a registry of SPIDs?
>>>>
>>>> -hadriel
>>>>
>>>> _______________________________________________
>>>> stir mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/stir
>>>>
>>>> _______________________________________________
>>>> insipid mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/insipid
>>> _______________________________________________
>>> insipid mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/insipid
>> _______________________________________________
>> insipid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid