Subject: [Speermint] SIP Interconnect draft - requirement entity

From: "David Hancock" <[email-masked]>
Date: Fri, 4 Dec 2009 11:42:39 -0700

I would like to start addressing the comments received during
presentation of draft-hancock-sip-interconnect-guidelines-02 at the
IETF#76 SPEERMINT meeting.  This email discusses the comment received on
the first issue. 

Here is the issue:
What entity is used as the subject of normative statements in the
document?

Comments recorded in the meeting minutes:
JON PETERSON on Requirement Entity (slide 5): Make sure that the
interconnect spec describes what the SIP traffic between domains looks
like must comply with) WITHOUT RESPECT TO WHAT ELEMENT makes this happen
or how it is achieved.  IMPORTANT POINT / KEY CHANGE!! 

Proposed resolution:
Actually version 02 of the draft already proposes a resolution, so I
would like to start with that. This solution places requirements on the
SBE and DBE, but modifies the definition of these entities slightly
(within the scope of the draft) to meet the spirit of the above comment.

Here is the text from the -02 draft, inserted immediately after the
architecture diagram in section-3:

   This document places requirements on the following two entities in
   the Peering architecture:

   o  the SBE in support of the SIP/SDP interface between two peering
      networks

   o  the DBE in support of the RTP/RTCP interface between peering
      networks

   Based on the definition of the SBE in the peering architecture
   document [I-D.ietf-speermint-architecture], it's not entirely correct
   to make the SBE responsible for meeting all the SIP signaling
   requirements at the peering interface.  For example, the SBE can play
   the role of a firewall or a SIP proxy that is largely transparent to
   the SIP messages crossing the interface.  In reality, the
   responsibility for supporting this interface belongs to all the SIP
   entities in the SIP signaling chain, including the SBE plus the SIP
   proxies and UAs inside the network.  Furthermore, when this network
   is serving as a transit network, the SIP signaling chain can extend
   into another network.  To resolve this issue, this document extends
   the definition of the SBE slightly so that when it is specified as
   the target entity of a normative requirement on the SIP/SDP peering
   interface, the SBE represents all the SIP entities in the SIP
   signaling chain that can effect the SIP/SDP peering interface.

   Likewise, the DBE can act as a media relay (performing no media
   encode/decode) that is transparent to the RTP/RTCP packets exchanged
   with the peer network.  Therefore, this document extends the
   definition of the DBE so that when it is specified as the target
   entity of a normative requirement on the RTP/RTCP interface, it
   represents the media endpoint in the peering network that terminates
   the RTP/RTCP stream.

Is this approach acceptable to everyone, or would you like to see
something different?

Thanks
David

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Sat, 5 Dec 2009 13:40:15 -0600

David,

This is in line with the comments I made earlier about reflecting the
functional entity to which the requirements apply.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of David Hancock
> Sent: Friday, December 04, 2009 1:43 PM
> To: [email-masked]
> Subject: [Speermint] SIP Interconnect draft - requirement entity
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Sat, 5 Dec 2009 14:06:40 -0600

David,

Given the text you have below, could you take a look at the section
headings as well?
That may give rise to implicit assumptions about where exactly some
function might be performed.

Mike

On

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 7 Dec 2009 08:09:02 +0100

This seems a reasonable approach.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Hancock
> Sent: 04 December 2009 18:43
> To: [email-masked]