Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 27 Jul 2005 10:48:06 -0400

I agree whole-heartedly with Henry that reliance on the PSTN to
interconnect SIP islands is not the way to go.  However, I believe that
this is a near-term reality.  Many groups (service providers and
standards fora) throughout the world have been working on ways to
interconnect SIP networks for some time now.  It does take time to do
this right.  Tinker-toy networks can be slapped together overnight; but,
ironclad national infrastructures require more thorough examination.
That system-level architectural work is already in-progress, and there
may be more than just the two models Henry cites.
 
The IETF has in the past avoided this type of work by declaring it
unnecessary.  I'm glad to see the recognition now that it is needed.
But, here is the issue:  
ITU-T is working on this.  
ATIS is working on this.  
ETSI TISPAN is working on this.  
3GPP is working on this.  
3GPP2 is working on this.  
SIP Forum is working on this.  
MSF is working on this.
And probably more I have missed.
 
How do you slow down a project?  Add another programmer.
How do you slow down a standard?  Add another standards forum.
 
I suspect that it is the same set of folks going to yet another set of
meetings, using another set of procedures and tools.  I have noticed
that folks are attending IETF meetings to address specific protocol
needs.  I am just wondering if the reverse might also help.  If you
don't like the way the architectures are progressing, show up at the
meetings and convince the group otherwise.  From some of the names I
have seen attending, I think that is already happening.  What adding
this work to SIPPING suggests is that the collaboration agreements
between IETF and say ITU are not working to their full potential.
Perhaps the ADs who worked so hard to forge those ought to be asking why
not.
 
Mike

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avshalom Houri
	Sent: Wednesday, July 27, 2005 9:50 AM
	To: [email-masked]
	Cc: [email-masked]
	Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

	Being one of the authors of the draft it is not surprising that
I fully 
	agree with you. Thanks for your support. 
	
	I want to emphasize several points: 
	
	* The IETF can not expect that defining a protocol is the end of
the work. 
	presence and IM and other protocols that the IETF is currently
defining are in 
	a much higher level then TCP or UDP or any network protocol. The
interop 
	issues are not only technical but imply a lot of other concerns
that need to be 
	solved in order have a real interop. 
	
	* SIP interoperability is not flying. It is very hard to do when
components from 
	different companies are involved and it is very hard to do when
several 
	communities are involved. It is actually impossible to do
without negotiating 
	what will be that actual interop and what will be allowed and
what will not be 
	allowed. I may be wrong but it seems that the shift from peer to
peer or a single 
	deployment paradigm to interoperability between enterprises and
different 
	deployment have not happened yet. 
	
	We need to get these kind of items to the top priority of the
SIPPING working 
	group even in the expense of not adding new features to SIP in
order to make sure 
	that SIP will really be something that all will feel convenient
regarding its 
	interoperability. 
	
	Avshalom 

	Henry Sinnreich wrote on 27/07/2005 03:42:22 PM:
	
	> Mike,
	> 
	> >question to the group is whether that is sufficient reason 
	> >for the group to take on this *type* of work
	> 
	> Internet communications are a prime focus of the IETF,
otherwise we would
	> not have all the WGs: SIP, SIPPING, SIMPLE, IPTEL, MMUSIC,
AVT, etc. dealing
	> with this and related topics.
	> 
	> The practical results, though impressive, are however
overshadowed by the
	> fact that almost all SIP communication islands interconenct
only using the
	> PSTN. This is nothing short of scandalous and should be a real
source of
	> concern to the IETF.
	> 
	> The industry has now forwarded two proposals, that are
conceptually on the
	> opposite side of the solutions spectrum:
	> 
	> - The Internet-wide Inter-Domain Requirements for SIP/SIMPLE,
and
http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-
02.t
	> xt 
	> 
	> - The (3GPP-IMS inspired?) SBC based architecture as proposed
in the VoIP
	> Peering BOF
	>   http://darkwing.uoregon.edu/~llynch/voipeer/ 
	> 
	> Given this state of affairs, the proposed Inter-Domain
Requirements for
	> SIP/SIMPLE should be IMHO on the top of the list of the
SIPPING WG.
	> 
	> Thanks, Henry
	> 
	> 
	> 
	>  
	> 
	> -----Original Message-----
	> From: Michael Hammer (mhammer) [mailto:[email-masked]] 
	> Sent: Tuesday, July 26, 2005 11:03 AM
	> To: [email-masked]; [email-masked];
[email-masked];
	> [email-masked]; [email-masked]
	> Cc: [email-masked]; Jake Salinger; [email-masked];
Dean Willis
	> Subject: RE: [Sipping] Inter-Domain Requirements for
SIP/SIMPLE
	> 
	> Henry,
	> 
	> I too agree that there is some good information in this
document.  But,
	> my question to the group is whether that is sufficient reason
for the
	> group to take on this *type* of work.  My impression is that
in the past
	> such work was deemed out of scope.  (Implementation-oriented,
"we don't
	> do profiles", etc.)  The questions that should be addressed
before this
	> one:
	> 
	> 1.  Will adding this to the workload delay existing WG items
further?
	> 
	> 2.  Will adding this to the workload preclude other more core
protocol
	> work from being added as WG items and addressed in a timely
fashion?
	> 
	> 3.  How will this group deal with other fora that are doing
similar
	> work?
	> 
	> Perhaps the VoIP Peering BoF will also touch on the above.
	> 
	> Mike
	> 
	> 
	> _______________________________________________
	> Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
	> This list is for NEW development of the application of SIP
	> Use [email-masked] for questions on current
sip
	> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 27 Jul 2005 14:00:42 -0500

Mike,

>3GPP2 is working on this.  

Do you mean these organizations are working to advance the Internet (and its
e2e principle)?

Thanks, Henry

  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2005 9:48 AM
To: Avshalom Houri; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

I agree whole-heartedly with Henry that reliance on the PSTN to interconnect
SIP islands is not the way to go.  However, I believe that this is a
near-term reality.  Many groups (service providers and standards fora)
throughout the world have been working on ways to interconnect SIP networks
for some time now.  It does take time to do this right.  Tinker-toy networks
can be slapped together overnight; but, ironclad national infrastructures
require more thorough examination.  That system-level architectural work is
already in-progress, and there may be more than just the two models Henry
cites.

The IETF has in the past avoided this type of work by declaring it
unnecessary.  I'm glad to see the recognition now that it is needed.  But,
here is the issue:  

ATIS is working on this.  

3GPP is working on this.  

MSF is working on this.

I suspect that it is the same set of folks going to yet another set of
meetings, using another set of procedures and tools.  I have noticed that
folks are attending IETF meetings to address specific protocol needs.  I am
just wondering if the reverse might also help.  If you don't like the way
the architectures are progressing, show up at the meetings and convince the
group otherwise.  From some of the names I have seen attending, I think that
is already happening.  What adding this work to SIPPING suggests is that the
collaboration agreements between IETF and say ITU are not working to their
full potential.  Perhaps the ADs who worked so hard to forge those ought to
be asking why not.

Mike

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Avshalom Houri
Sent: Wednesday, July 27, 2005 9:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

Being one of the authors of the draft it is not surprising that I fully 
agree with you. Thanks for your support. 

* The IETF can not expect that defining a protocol is the end of the work. 
presence and IM and other protocols that the IETF is currently defining are
in 
a much higher level then TCP or UDP or any network protocol. The interop 
issues are not only technical but imply a lot of other concerns that need to
be 
solved in order have a real interop. 

* SIP interoperability is not flying. It is very hard to do when components
from 
different companies are involved and it is very hard to do when several 
communities are involved. It is actually impossible to do without
negotiating 
what will be that actual interop and what will be allowed and what will not
be 
allowed. I may be wrong but it seems that the shift from peer to peer or a
single 
deployment paradigm to interoperability between enterprises and different 
deployment have not happened yet. 

We need to get these kind of items to the top priority of the SIPPING
working 
group even in the expense of not adding new features to SIP in order to make
sure 
that SIP will really be something that all will feel convenient regarding
its 
interoperability. 

Avshalom 

Henry Sinnreich wrote on 27/07/2005 03:42:22 PM:

> Internet communications are a prime focus of the IETF, otherwise we would
> not have all the WGs: SIP, SIPPING, SIMPLE, IPTEL, MMUSIC, AVT, etc.
dealing
> The practical results, though impressive, are however overshadowed by the
> fact that almost all SIP communication islands interconenct only using the
> PSTN. This is nothing short of scandalous and should be a real source of
> concern to the IETF.
> 
> The industry has now forwarded two proposals, that are conceptually on the
> - The Internet-wide Inter-Domain Requirements for SIP/SIMPLE, and
>  
>
http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-reqs-02.t
> xt 
> 
> - The (3GPP-IMS inspired?) SBC based architecture as proposed in the VoIP
> Peering BOF
> Given this state of affairs, the proposed Inter-Domain Requirements for
> SIP/SIMPLE should be IMHO on the top of the list of the SIPPING WG.
> 
> Thanks, Henry
> 
> 
> 
>  
> 
> To: [email-masked]; [email-masked]; [email-masked];
> Cc: [email-masked]; Jake Salinger; [email-masked]; Dean Willis
> I too agree that there is some good information in this document.  But,
> my question to the group is whether that is sufficient reason for the
> group to take on this *type* of work.  My impression is that in the past
> such work was deemed out of scope.  (Implementation-oriented, "we don't
> do profiles", etc.)  The questions that should be addressed before this
> one:
> 
> 1.  Will adding this to the workload delay existing WG items further?
> 
> 2.  Will adding this to the workload preclude other more core protocol
> work from being added as WG items and addressed in a timely fashion?
> 
> 3.  How will this group deal with other fora that are doing similar
> work?
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 27 Jul 2005 15:10:15 -0500

On Jul 27, 2005, at 2:00 PM, Henry Sinnreich wrote:

> I don’t get it:
> Do you mean these organizations are working to advance the Internet 
> (and its e2e principle)?

To use John Waclawsky's lingo, the IETF has typically behaved as a 
"component standards" organization. We specify protocols. Other people 
(like those listed above) then take these components and build systems 
out of them. That's what makes them "systems standards" organizations.

Every now and then IETF steps up and says something about systems 
issues, typically when an incomplete spec or bad implementations have 
started causing problems for the operators.

Example: HTTP is an IETF spec. We don't have specifications for how to 
build web servers, organize an HTML file store, or doing federated 
authentication using a common identity (aka "Passport").

We do, however, talk about best current practices for the routing of 
email and the prevention of SPAM. The VoIP Peering BOF appears to be 
tackling a similar problem, from the perspective of VoIP. Perhaps their 
scope should be "Peering operations for real-time Internet 
communications traffic". This MIGHT be a reasonable focus for an 
Internet working group -- to document the best current practices of 
peering, analyze the deficiencies of the protocols in addressing the 
requirements of peering, and feed requirements into the protocol design 
groups.

This level of work is outside the scope of SIPPING as it is currently 
chartered. I think that the best path forward is to either see to it 
that VOIPEER gets this clearly included in its scope and that we do the 
work there, or that we pursue establishment of another working group to 
tackle this problem. My guess is that this would actually be an 
operations area problem.

A second possibility would be to extend the charter of SIPPING to 
include this sort of work. I'm reluctant to pursue this while the jury 
is still out on VOIPEER.

--
dean

---

From: Aki Niemi <[email-masked]>
Date: Fri, 29 Jul 2005 17:36:18 +0300

Hi,

I think the draft has some good discussion of a number of relevant
problems, but there seems to be some underlying assumptions about how 
interconnecting users in the Internet is done that I simply do not share.

Do I, as administrator of akiniemi.net, really need off-line bilateral 
agreements with other domains to be able to communicate with them? Or 
need to maintain a list of "accpetable" domains for which my users can 
send IM and subscribe presence from? i think there are two specific 
problems with this sort of approach:

1) Is the provider hosting 100s of millions of users really going to 
talk to me, a provider of 5 users, "off-line" to discuss these bilateral 
agreements?

2) Does not scale beyond a very small number of providers. A bigger 
number of providers would necessitate some sort of broker entities. At 
least the draft should discuss them.

However, I don't think this is how peering should work in the general 
case. It may be an option for providers that want to build a system that 
is (at least partially) closed. If spam prevention is the goal, then I'd 
much rather see discussion of how SIP identity work could be leveraged.

Also, is the draft really suggesting (the SIP MESSAGE over TCP proposal) 
that we open the session mode discussion again? You know it would be 
something like the 16th time in the last 4 years? Please, don't.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jul 2005 13:38:42 -0400

I would like to second Aki's comments - they are spot on.

I'm especially concerned with the SHOULD strength requirement for a 
bilateral agreement around the secured transport connection specified in 
section 4.3. On the contrary, I think it would be more appropriate that 
TLS connections *without* any bilateral agreement be the norm.

I am also very concerned about the endorsement of MESSAGE sessions 
within INVITE dialogs, which is an excellent way to sabotage the uptake 
of MSRP. Since this document is so keen on bilateral agreements, if it 
wants to say anything about session mode other than MSRP, it should 
suggest that any other method be by bilateral agreement.

	Paul

Aki Niemi wrote:
>>> >ITU-T is working on this. >ATIS is working on this. >ETSI TISPAN is 
>>> working on this. >3GPP is working on this. >3GPP2 is working on this.  
>> tackling a similar problem, from the perspective of VoIP. Perhaps 
>> their scope should be "Peering operations for real-time Internet 
>> requirements of peering, and feed requirements into the protocol 
>> design groups.
>>
>> that VOIPEER gets this clearly included in its scope and that we do 
>> the work there, or that we pursue establishment of another working 
>> group to tackle this problem. My guess is that this would actually be 
>> an operations area problem.
>>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 30 Jul 2005 01:52:54 -0500

> it would be more appropriate that TLS connections *without* any 
> bilateral agreement be the norm.

Yes, you hit it the nail on the head. Running IP services on biletaral
agreements is not scalalble and should not not be legitimized in the IETF in
any shape or form.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Friday, July 29, 2005 12:39 PM
To: Aki Niemi
Cc: [email-masked]; 'Avshalom Houri'; 'Michael Hammer (mhammer)'; ext Dean
Willis
Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 30 Jul 2005 13:36:08 +0300

> agreements is not scalalble and should not not be legitimized in the IETF in

i fully support that position.  ietf should not get involved with
developing mechanisms for walled gardens.  the focus should be how on to
make sip/simple work securely between any internet nodes without any
non-scalable bilateral or clearing house agreements.  there is nothing
special in sip or simple as compared, for example, to email.

-- juha

---

From: "Cullen Jennings" <[email-masked]>
Date: Sat, 30 Jul 2005 10:41:15 -0400

I thought that would be Henry's opinion and I think I will be mostly
following Henry's guidance here (with the occasional transgression :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Sinnreich
Sent: Saturday, July 30, 2005 2:53 AM
To: 'Paul Kyzivat'; 'Aki Niemi'
Cc: 'Avshalom Houri'; [email-masked]; 'Michael Hammer (mhammer)'; 'ext
Dean Willis'
Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

Henry

-----Original Message-----

I'm especially concerned with the SHOULD strength requirement for a
bilateral agreement around the secured transport connection specified in
section 4.3. On the contrary, I think it would be more appropriate that TLS
connections *without* any bilateral agreement be the norm.

I am also very concerned about the endorsement of MESSAGE sessions within
INVITE dialogs, which is an excellent way to sabotage the uptake of MSRP.
Since this document is so keen on bilateral agreements, if it wants to say
anything about session mode other than MSRP, it should suggest that any
other method be by bilateral agreement.

	Paul

Aki Niemi wrote:
> talk to me, a provider of 5 users, "off-line" to discuss these
> bilateral agreements?
>
> case. It may be an option for providers that want to build a system
> that is (at least partially) closed. If spam prevention is the goal,
> then I'd much rather see discussion of how SIP identity work could be
leveraged.
>
> Also, is the draft really suggesting (the SIP MESSAGE over TCP
> proposal) that we open the session mode discussion again? You know it
> would be something like the 16th time in the last 4 years? Please, don't.
>
> Cheers,
> Aki
>
> ext Dean Willis wrote:
>
>>
>> "component standards" organization. We specify protocols. Other
>> people (like those listed above) then take these components and build
>> systems out of them. That's what makes them "systems standards"
organizations.
>> Example: HTTP is an IETF spec. We don't have specifications for how
>> to build web servers, organize an HTML file store, or doing federated
>> include this sort of work. I'm reluctant to pursue this while the
>> jury is still out on VOIPEER.
>>
>> --
>> dean
>>
>>
>> This list is for NEW development of the application of SIP Use
>> [email-masked] for questions on current sip Use
>> [email-masked] for new developments of core SIP
>>
>
> This list is for NEW development of the application of SIP Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments of core SIP
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP