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

["DRAGE, Keith (Keith)" <[e-mail]>]

I am getting very confused here.

Is there a problem with this requirement in the requirements document?

If not, then lets move on with the requirements document.

Is there a problem with the solutions document?

If so it is a working group item - make sure it contains what the working group wants. The original authors no longer have responsibility for the technical direction, only for making sure it contains what the working group wants. Hadriel may be on the author list, but you are a member of the working group.

Regards

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Robert Sparks
> Sent: 31 July 2013 08:18
> To: [e-mail]
> Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs?
> 
> 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