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

From: [email-masked]
Date: Mon, 1 Aug 2005 08:45:16 +0200

Sorry, I forgot to add that inter-domain agreements are not only a
non-scalable approach, but as Aki Niemi has pointed out, large providers may
refuse to give attention to small providers.

VoIP Peering can therefore be a tool for discrimination against smaller
competitors, and may be misused for monopoly behavior IMHO. The IETF would
therefore be well advised to develop BCPs exposing these pitfalls.

Thanks, Henry

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Saturday, July 30, 2005 12:36 PM
To: [email-masked]
Cc: 'Avshalom Houri'; 'Aki Niemi'; 'Michael Hammer (mhammer)'; 'ext Dean
Willis'; 'Paul Kyzivat'; [email-masked]
Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

Henry Sinnreich writes:

 > 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.

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

_______________________________________________
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: "Orit Levin" <[email-masked]>
Date: Tue, 26 Jul 2005 13:58:19 -0700

We (i.e. the co-authors) obviously think that the document is useful. It
has served us very well as a working tool for deploying public to
enterprise IM connectivity. We are still constantly referring our
customers and competitors interested in this type of interconnection to
it.

We planned to present the draft at SIMPLE or SIPPING, but currently
there are no time slots available on either. The reason for presenting
the draft was to figure out the best way forward: an individual
informational RFC vs. a WG BCP. In other words, we wanted to raise the
exact three questions that Michael is asking below in his email.

Regarding presenting the draft at the VoIP Peering BoF - the authors
feel very hesitant about it. For the "profile" and the specific SIMPLE
requirements talked about in this draft - there is really no need to
establish a new WG. We believe that they all naturally fall under SIP
and SIMPLE. It is true that Service Providers will most probably need a
similar profile as a part of their connectivity but they are currently
looking for a much broader scope - beyond the standard SIP/SIMPLE.

I am bcc-ing SIMPLE as well, but let's keep this thread on SIPPING.

Thanks,
Orit.

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Michael Hammer (mhammer)
> 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
> 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
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Henry Sinnreich
> > Sent: Tuesday, July 26, 2005 12:59 PM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; 'Jake Salinger';
> > [email-masked]; 'Dean Willis'
> > Subject: FW: [Sipping] Inter-Domain Requirements for SIP/SIMPLE
> >
> >
> > >It should definitely become a SIPPING WG item. This document
> > is great.
> >
> > If Dean thought this request can be dismissed with a joke: We
> > will be persistent.
> >
> > Especially in view of the VoIP Peering BOF.
> >
> > Thanks, Henry
> >
> >
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Jake Salinger
> > Sent: Monday, July 25, 2005 7:30 AM
> > To: [email-masked]
> > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE
> >
> > It should definitely become a SIPPING WG item. This document is
great.
> >
> >
> >
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: "'Dean Willis'" <[email-masked]>; <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Monday, July 25, 2005 4:18 PM
> > > >Could we just poll the mailing list instead?
> > >
> > >
> > http://www.ietf.org/internet-drafts/draft-levin-simple-interdo
> > main-reqs-02.t
> > > xt
> > >
> > > What are the opinions on this list? Should it become a
> > SIPPING WG item?
> > >
> > > Thanks, Henry
> > >
> > > From: Dean Willis [mailto:[email-masked]]
> > > Sent: Sunday, July 24, 2005 6:50 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE
> > >
> > >
> > > On Jul 23, 2005, at 9:53 AM, Henry Sinnreich wrote:
> > >
> > > > The I-D Inter-Domain Requirements for SIP/SIMPLE
> > > >
> > http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain-
> > > > reqs-02.t
> > > > xt
> > > >
> > > > is not only a very good document but is also very timely
> > for other
> > > > inter-domain communications, such as between all the
> > emerging VoIP
> > > > islands (the islands are a regrettable fact at present).
> > > >
> > > > I suggest therefore having a 5 minute hum so as to make
> > it a SIPPING
> > > > WG item.
> > >
> > >
> > > Henry, I'm pretty sure that if we ask the working group to
> > hum for 5
> > > minutes that the resulting anoxia would preclude further
> > useful work
> > > for the remainder of the meeting.
> > >
> > > Could we just poll the mailing list instead?
> > >
> > > --
> > > Dean
> > >
> > >
> > > 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
> >
> >
> > Use [email-masked] for questions on current
> > sip Use [email-masked] for new developments of core SIP
> >
> >
> >
> >
> > Use [email-masked] for questions on current
> > sip Use [email-masked] for new developments of core SIP
> >
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 27 Jul 2005 12:54:15 -0400

Henry,

Unless every endpoint is its own domain, e2e and inter-domain are not
congruent:  e-e != domain-domain interface.  Otherwise, inter-domain
involves the interaction of intermediaries.  The real question is what
is the nature of those intermediaries at the domain border.  Let's call
them domain border controllers to distinguish from the intermediaries
(aka proxies) not at the domain border.  Are DBCs any better than SBCs?
Who knows?  That is what we are trying to discover.  I think we are
still at the stage of listing functionality and evaluating whether it is
needed and if so, where.  I think it is too early to conclude that we
know long-term what is needed, whether you call it an SBC, DBC, or
anything else.

Mike

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Wednesday, July 27, 2005 12:12 PM
> To: 'Khan, Sohel Q [NTK]'; Michael Hammer (mhammer); 
> [email-masked]; [email-masked]; 
> > The VoIP peering BOF can address that
> 
> The proposed Inter-Domain Requirements for SIP/SIMPLE takes 
> the _opposite_ approach as the VoIP peering BOF, where 
> everything seems to be based on countless intermediaries in 
> carrier networks such as SBCs a la IMS (I would be happy to 
> be proven wrong).
> 
> This leaves Internet-style e2e and inter-domain out in the 
> cold; very strange.
> 
> Henry
> 
> 
>  
> 
> From: Khan, Sohel Q [NTK] [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2005 10:00 AM
> To: Michael Hammer (mhammer); [email-masked]; 
> [email-masked]; [email-masked]; 
> Cc: [email-masked]; Jake Salinger; [email-masked]; 
> Dean Willis
> Here, I agree with Mike because we do not want to slow down 
> the current works of SIPPING group by adding Inter-Domain 
> work. The VoIP peering BOF can address that.
> 
> [mailto:[email-masked]] On Behalf Of Michael Hammer 
> (mhammer)
> Sent: Tuesday, July 26, 2005 1:03 PM
> To: [email-masked]; [email-masked]; 
> [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:
> 
> 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: "Henry Sinnreich" <[email-masked]>
Date: Wed, 27 Jul 2005 13:48:37 -0500

Dean,

>Don't let them organize a working group to push ITEF
>resources into an objectionable direction without even hearing opposition.
>See if you can build consensus on a reasonable approach.

This makes sense. It would also help if there would be a document about what
we consider the reasonable approach. The Inter-Domain Requirements for
SIP/SIMPLE is the closest we have. If there are issues with this I-D, please
y'all, speak up on the list.

Thanks, Henry

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2005 12:54 PM
To: Henry Sinnreich; 'Khan, Sohel Q [NTK]'; 'Michael Hammer (mhammer)';
[email-masked]; Hisham Khartabil; [email-masked]; Gonzalo Camarillo
Cc: [email-masked]; 'Jake Salinger'; [email-masked]
Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE

On 7/27/05 11:12 AM, "Henry Sinnreich" <[email-masked]> wrote:

> The proposed Inter-Domain Requirements for SIP/SIMPLE takes the _opposite_
> approach as the VoIP peering BOF, where everything seems to be based on
> countless intermediaries in carrier networks such as SBCs a la IMS (I
would
> be happy to be proven wrong).
> 
> This leaves Internet-style e2e and inter-domain out in the cold; very
> strange.
> 
> Henry
> 

VoIP Peering is a BoF. Its direction is not cast in stone. But they ARE
trying to work on what is basically the same problem. Go explain things and
make them see the Right Way to solve this problem. At least point out the
divergence in approach. Don't let them organize a working group to push ITEF
resources into an objectionable direction without even hearing opposition.
See if you can build consensus on a reasonable approach.

That's why the scheduling conflict between SIMPLE and VOIPEER worries me so
much -- most of the people who have alternative positions and arguments are
also heavy contributors to SIMPLE, and so they won't be able to contribute
effectively at this VOIPEER meeting.

--
Dean

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 1 Aug 2005 09:42:52 -0400

The IETF would therefore be well advised to develop BCPs exposing these
pitfalls.

[RRR] Is there any BCP draft in progress?

Thanks, Henry

---

From: Arjun Roychowdhury <[email-masked]>
Date: Mon, 1 Aug 2005 15:15:22 -0400

Some comments:

1. I am curious why the document limits itself only to SIMPLE ? Surely
such a document would be very useful for SIP in general ? Should you
choose to address the larger scope, I believe the identity
relationship document would be a good mechanism to suggest a
convergence of SIMPLE and SIP for voice/video.

Section 4.2 para 3: I believe this is normal behaviour expected from
SIP/SIMPLE clients. Not sure why this needs to be mentioned again.

Section 4.2 para 4: The term 'reasonably small' does not offer much in
terms of technical help. I understand its hard to talk about a formula
and there may be none. However, I would like to see an example added
post this text that describes a particular configuration and the recc.
connections based on certain assumptions.

Section 4.3: I can understand this recc. being under Transport
Security. However,
I think this sets the theme stating that to get any sense of security,
TLS is almost a must.
I also understand this may be in line with the ietf thought process.
However, this being a document that hopefully, someday, service
providers may consider to be 'good citizens' I  believe you should
also add the repercussions of using UDP and the 'good citizen'
requirements for that. As an example, many IM systems today are using
UDP and if they are between trusted domains, it is still acceptable.

Section 5.2: It looks like this section specifies and example of what a presence
profile could be. I think this is a key requirement to inter-domain
interop and it
can't be limited to just an example - I think the language should be
made stronger
here and specifically refer to section 2.1 of RFC3863 bein supported
at the least.

Section 5.3.1:
"In the absence of any bilateral agreement
   between the administrative authorities for each community,
   subscriptions to the same URI MUST NOT occur more frequently than
   every two hours."

Actually, if there is no bilateral agreement whatsoever between the
two, I don't
believe specifying a limit of 2 hrs has any particular merit. If this
results in
congestion issues, I'd prefer it to be tackled by solutions such as
Aki's throttle
mechanisms instead of guessing the requirements of a network we have
no idea about.

5.3.2: Same comment as 5.3.1

6.1 General para 3 - again this, I believe, is a fundamental reqt. of
SIMPLE compliant clients - why does it need to be repeated in this
draft ?

All of section 6 - though valid, none of this is specific to
inter-domain and applies for any two clients inter or intra.

Section 7 para 1 - I understand the theoretical benefit. However, the practical 
truth is that if some of those headers contain 'sensitive'
informantion as decided by
the domain controller, it will be masked out, irrespective of the fact
whether it destroys e-e security. I would expect this draft to be
actually considered for implementation by  service providers (or
'communities' if that word suits the group better). Therefore, I urge
the authors to also handle these realistic scenarios, identify
measures to be taken and also discuss the ramifications instead of
ignoring them

Section 8: This I believe is  (or should be) the heart/crux of
inter-domain communication (besides a minimally agreed upon profile)

'Agreements' cover issues such as routing, identity, white lists, black lists, 
billing, SLAs. I would like to see more treatment in this section to
further describe
agreements for 'routing', 'trust', 'quality (if applicable)' and similar. 
If the authors believe that this is completely upto local policy, I'd
contend that this
section allows me enough leeway to plug in all sort of devices like
SBCs (and variants). As an example, I could simply replace the term
'edge proxy' with an SBC that acts like one and on the network side,
the only concrete requirement of TLS could still be maintained.

If the authors believe that this is something that is not in the scope
of the draft, then
I suggest that this entire section be removed, as it does not really
help me in acheivingany specific goal.

Section 9.2 - I am unsure what is being achieved by exposing
user-trust level of one
community to another. It would work only if the user-trust level is
understood universallyand in turn enforces internal architectural
requirements.

Section 10.1, para 5: In addition to specifying white-lists, SPAM
often needs black-lists,especially when you cannot beforehand limit
the domains that may contact you.

General 1: I am not sure if I read any reccomendations on presence
aggregation anywhere. If ithas not been specified, it may be a good
idea to suggest the use of aggregation to reducenetwork load.

General 2: Does it make sense to also describe the nature of the
'SIMPLE' system that is being interconnected ? For example, if we are
now talking about connecting users at mobile.att.com to users from
verizondsl.com, the very nature of the UA's in the former may have
further requirements on inter-domain requirements re: suggested
message size, use of specific media streams, or is that something we
can leave to the 'domain-controller' or end UA to reject/accept as
part of standard capability exchange ?

regds
arjun
-- 
Arjun Roychowdhury

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 10 Aug 2005 16:38:30 -0400

Ahhh.  So, the distinction is garden walls between neighbors, versus
walls facing a public street.  Hopefully, that latter wall is strong.

I was trying to disabuse myself of an apparent oxymoron (inter-domain
non-walled garden).

Mike

> [mailto:[email-masked]] On Behalf Of Juha Heinanen
> Sent: Friday, August 05, 2005 2:13 AM
> To: Mika Lehtinen
> Cc: [email-masked]
> Mika Lehtinen writes:
>  > This has to be the case, but on the other hand, isn't this 
> one of the  > reasons why internet email is spam infested and 
> mostly survives by  > some king of rule and (domain?!?) based 
> filtering?
> 
> there are heuristic rules, no all inclusive listing of 
> trusted peers, like walled gardens do.
> 
> -- juha
>