Subject: [Insipid] INSIPID Req#6 - comments?

From: "James M. Polk" <[email-masked]>
Date: Thu, 26 Apr 2012 15:04:42 -0500

Figure it is about time I sent these requirements out to the list. 
Comments, questions and wordsmithing are encouraged. Let's see if we 
can leave much of the wordsmithing till the end of the discussion, 
once we have agreed on the requirement's worthiness and contents.

Let's also keep the discussion on *this* thread to just *this* 
requirement for tracking purposes. There are 9 current requirements. 
Therefore, there will be 9 different messages sent to this list.

Here is REQ#6 as currently written in
http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-reqts-00.txt

    REQ6: The identifier must not reveal to the receiver of it
    that the Call-ID, tags, or any other SIP header or body
    portion have been changed by middleboxes, with as high a
    probability as possible.

---

From: Laura Liess <[email-masked]>
Date: Fri, 27 Apr 2012 15:07:58 +0200

Hi,

The benefit of having this requirement is not clear to me. What may
happen if we do not have it?
We have REQ5, which ensure hiding of every kid of device identity, in
order to avoid B2BUAs to change the Session-ID. REQ5 is important. But
REQ6? If we can not find out what the reason for it is, I propose to
drop it, because having REQ6  may complicate the solution, I think.

Thanks
Laura

2012/4/26 James M. Polk <[email-masked]>:
> Figure it is about time I sent these requirements out to the list. Comments,
> questions and wordsmithing are encouraged. Let's see if we can leave much of
> the wordsmithing till the end of the discussion, once we have agreed on the
> requirement's worthiness and contents.
>
> Let's also keep the discussion on *this* thread to just *this* requirement
> for tracking purposes. There are 9 current requirements. Therefore, there
> will be 9 different messages sent to this list.
>
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 30 Apr 2012 09:30:25 -0400

I thought somebody replied on this one.  In any case, the intent is to 
not reveal to the world that a call has passed through an SBC. I assume 
this is to ensure topologies and peering relationships remain protected.

Paul

On 4/27/2012 9:07 AM, Laura Liess wrote:
> 2012/4/26 James M. Polk<[email-masked]>: