RE: [Speermint] [wg-business]WGLCfordraft-ietf-speermint-terminology-12

["Uzelac, Adam" <[e-mail]>]

Note: I might be contradicting myself here a bit, but be that as it
may....I don't think that we should get into the game of how a SP
becomes a SSP. It's a slippery slope there. (Think DPI as an example)
The basic premise or proposition which underlies being an SSP is that it
is "SIP-aware", not how the SP becomes "SIP-aware".

The nature of the SSP(t) is to enable connectivity between SSP(O) and
SSP(T). It's unrealistic to think we can have a complete mesh between
all SSP(O)s and all SSP(T)s.  Let me go on record as a fan of
http://tools.ietf.org/id/draft-lendl-domain-policy-ddds-02.txt to help
with this.

Please note also that I think that any middlemen - read as SSP(t)s -
that add no value will be disintermediated, sooner or later.
(attribution to Mike Hammer from a thread long ago)

Look back to threads from long ago about 'Basic Peering
Requirements'...It's simply impractical, at this time, to have local
route awareness of all SSP(T)s in the world.  Therefore the value of the
SSP(t) here can be to provide route aggregation.  SSP(O)s will most
likely have multiple upstream SSP(t)s.  Until reachability between all
'O and T' SSPs is realized, the SSP(t) or indirect SIP PATH (do not read
as media path) will be a reality.

-AU



> -----Original Message-----
> From: Dan Warren [mailto:[e-mail]] 
> Sent: Tuesday, October 02, 2007 10:43 AM
> To: Uzelac, Adam; Elwell, John; Daryl Malas
> Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; 
> [e-mail]; Livingood, Jason
> Subject: RE: [Speermint] 
> [wg-business]WGLCfordraft-ietf-speermint-terminology-12
> 
>  
> > 
> > > I'll shut up now.  Thanks for the help.
> > > 
> > > Dan
> > 
> > Oh no - you don't get to run away so quickly!  ;)
> 
> Well in that case...
> 
> > I think
> > there's some "wrongness" going on here.  The transit SSP 
> scenario can 
> > and does (in
> > the real world) contain both UACs and UASs.   The bare 
> > minimum would be
> > UASs I believe.  The transit most certainly is a SSP, as is the 
> > originating and terminating domain.  There may be more than one 
> > transit.
> > Any and all of the SSPs can have UACs and/or UASs.  It's more about 
> > the function that the domain performs or pertains to.
> > 
> > If a residential UA is registered to a UAS or not really shouldn't 
> > matter.  A residential UA alone with some static SIP-routing would 
> > define the originating domain.  If there's reachability 
> with other UAs 
> > without crossing into another SSP, like sessions in the 
> same building, 
> > neighborhood, business group, etc - these are all within the same 
> > domain and no peering occurs.  Should the look-up function 
> result in 
> > the terminating UA being in the terminating domain (think called 
> > party) - then it's a peer relationship between 2 parties:
> > 
> > SSP(O) <---> SSP(T)
> > 
> > If there's no direct path between the originating domain 
> [SSP(O)] and 
> > the terminating domain [SSP(T)], then employment of an 
> intermediary or 
> > transit domain [SSP(t)] may, and oftentimes does, get used:
> > 
> > SSP(O) <---> SSP(t) <---> SSP(T)
> > 
> > I don't know if that clears things up or not, but it's how 
> I organize 
> > the world.  ;)
> > 
> > -AU
> 
> I think we are all arguing the same way now.  There is a 
> question of semantics and a question of reality.  So 
> semantics (and the definition in the terminology draft) says 
> that the SSP does not have to include UAS's and/or UAC's but 
> the reality is that the concept of a SSP with UAS's or UAC's 
> is pretty hard to comprehend.
> 
> In your example above SSP(t) is ONLY an SSP, whilst SSP(O) 
> and SSP(T) are both Peer Networks (which in my mind at least 
> is a special case of
> SSP) since they are *ahem* well, peering.  UA(O) and UA(T) 
> may attach to
> SSP(O) and SSP(T) respectively across SP's (single S 
> intentional) such as a DSL provider that is providing pure 
> connectivity at L3.
> 
> So what is the nature of SSP(t)?  Does it have to have UAS 
> and UACs to be L5 aware?  Or could it just be contain SIP 
> Proxies, making it an SSP with UAS and UACs as John proposed? 
>  If it doesn't have any SIP awareness, then it is clearly 
> just an SP since again, it is just L3 connectivity based.
> 
> 
> > 
> > 
> > > -----Original Message-----
> > > From: Dan Warren [mailto:[e-mail]]
> > > Sent: Tuesday, October 02, 2007 8:31 AM
> > > To: Elwell, John; Daryl Malas
> > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net; 
> [e-mail]; 
> > > Livingood, Jason
> > > Subject: RE: [Speermint]
> > > [wg-business]WGLCfordraft-ietf-speermint-terminology-12
> > > 
> > > John
> > > 
> > > You just successfully (maybe inadvertently?) answered my other 
> > > question from my first mail - how to classify the transit 
> network, 
> > > particularly the transit where there is SIP awareness.  If that 
> > > transit network is also an SSP then that makes life a
> > little easier to
> > > understand.
> > > 
> > > The only question that then remains is whether SSPs for
> > tranist with
> > > no UAs should be categorised separately from SSPs that do
> > have UAs but
> > > don't peer.  But then an SSP with UAs that doesn't peer is not in 
> > > scope of the work...
> > > 
> > > I'll shut up now.  Thanks for the help.
> > > 
> > > Dan
> > > 
> > > > -----Original Message-----
> > > > From: Elwell, John [mailto:[e-mail]]
> > > > Sent: 02 October 2007 13:24
> > > > To: Dan Warren; Daryl Malas
> > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;
> > [e-mail];
> > > > Livingood, Jason
> > > > Subject: RE: [Speermint] [wg-business]
> > > > WGLCfordraft-ietf-speermint-terminology-12
> > > > 
> > > > Dan,
> > > > 
> > > > It is probably a moot point whether a residential UA is
> > > within the SSP
> > > > or not. Perhaps if the UA is in possession of credentials
> > for that
> > > > SSP, allowing it to register and submit other requests such
> > > as INVITE
> > > > and MESSAGE, then you might regard it as logically part of
> > > that SSP. 
> > > > But I guess the main point I was trying to make is
> > whether it is a
> > > > necessary condition that an SSP include UAs. Consider a
> > transit SSP
> > > > used in indirect peering. It can be a transit SSP without
> > > possessing a
> > > > single UA (gateway, phone, media server or whatever).
> > > > 
> > > > John
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Dan Warren [mailto:[e-mail]]
> > > > > Sent: 02 October 2007 11:58
> > > > > To: Elwell, John; Daryl Malas
> > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;
> > > [e-mail];
> > > > > Livingood, Jason
> > > > > Subject: RE: [Speermint] [wg-business]
> > > > > WGLCfordraft-ietf-speermint-terminology-12
> > > > > 
> > > > > John
> > > > > 
> > > > > You said...
> > > > > 
> > > > > 'Is it a necessary condition that an SSP include UAs
> > (other than
> > > > > B2BUAs, perhaps)? I guess it depends what we perceive as
> > > > the scope of
> > > > > an SSP.
> > > > > UAs such as PSTN gateways, media servers, etc. might be
> > > considered
> > > > > part of the SSP. But a UA in a user's home that uses the
> > > > services of
> > > > > an SSP?
> > > > > That to me is not really part of the SSP.'
> > > > > 
> > > > > I agree that under the current terminology and associated
> > > > definitions
> > > > > it isn't, but lets consider what the practicalities of
> > > > implementation
> > > > > are.
> > > > > Suppose I have a UA on my laptop.  Unless the ISP I 
> am using is 
> > > > > handling the SIP signalling from that UA in a special way
> > > compared
> > > > > with other non-SIP traffic, then the ISP is operating
> > as a SP (as
> > > > > defined in 3.8).
> > > > > The UA has to be associated with some sort of network 
> where my 
> > > > > sessions are handled, applications are applied and 
> methods are 
> > > > > forwarded.  This has to be in an SSP/ITSP, and if that SSP
> > > > is attached
> > > > > to other SSPs then it is also a Peer Network.  I guess the
> > > > point is,
> > > > > do we conceive of UA's that are in homes that do not need
> > > > to have an
> > > > > association with an SSP, even if it is only short term?
> > > > > 
> > > > > I have to admit that on reading your mail I figured I
> > had made a
> > > > > mistake, but then on analysing the text and thinking about
> > > > it, I think
> > > > > it is an interesting question.  Maybe the way to 
> consider it is 
> > > > > conversely - what do you classify a 'set of SIP user
> > agent servers
> > > > > (UASs) [2] and SIP user agent clients (UACs) [2]
> > > > (customers) that are
> > > > > controlled by a single administrative domain' but do not
> > > > peer?  So a
> > > > > completely self contained and non-peering network...  If an
> > > > SSP does
> > > > > not imply UACs and UASs, what is the level of SIP awareness
> > > > within the
> > > > > SSP space?
> > > > > 
> > > > > I am not trying to be intentionally provocative, I am just
> > > > aware that
> > > > > there seems to be some gaps in the definitions like could
> > > > be usefully
> > > > > closed before they cause problems when we need a term for
> > > a network
> > > > > classification that is not defined... I again make note
> > > > though that I
> > > > > am coming to this with fresh eyes and it might be that
> > I am just
> > > > > misunderstanding what is written.
> > > > > 
> > > > > Cheers
> > > > > 
> > > > > Dan
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Elwell, John [mailto:[e-mail]]
> > > > > > Sent: 02 October 2007 10:24
> > > > > > To: Dan Warren; Daryl Malas
> > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;
> > > > [e-mail];
> > > > > > Livingood, Jason
> > > > > > Subject: RE: [Speermint] [wg-business]
> > > > > > WGLCfordraft-ietf-speermint-terminology-12
> > > > > > 
> > > > > > Dan,
> > > > > > 
> > > > > > I agree with most of what you say. One point, 
> however, is your
> > > > > > proposal:
> > > > > > 'An SSP is an SP that also includes UASs and UACs...' 
> > > > (which I guess
> > > > > > comes from text in the existing definition of Peer
> > > > Network, which I
> > > > > > failed to comment on).
> > > > > > 
> > > > > > Is it a necessary condition that an SSP include UAs
> > (other than
> > > > > > B2BUAs, perhaps)? I guess it depends what we perceive as
> > > > the scope
> > > > > > of an SSP.
> > > > > > UAs such as PSTN gateways, media servers, etc. might be
> > > > considered
> > > > > > part of the SSP. But a UA in a user's home that uses the
> > > > services of
> > > > > > an SSP?
> > > > > > That to me is not really part of the SSP.
> > > > > > 
> > > > > > John
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Dan Warren [mailto:[e-mail]]
> > > > > > > Sent: 02 October 2007 09:45
> > > > > > > To: Elwell, John; Daryl Malas
> > > > > > > Cc: Malas, Daryl; "Peterson, , dmm"@1-4-5.net;
> > > > > [e-mail];
> > > > > > > Livingood, Jason
> > > > > > > Subject: RE: [Speermint] [wg-business]
> > > > > > > WGLCfordraft-ietf-speermint-terminology-12
> > > > > > > 
> > > > > > > All
> > > > > > > 
> > > > > > > Some of the points made by John (in his comments 
> 14, 15 and
> > > > > > > 16) I agree
> > > > > > > with but I think it goes further than that.  So 
> rather than
> > > > > > making a
> > > > > > > proper comment, can I check my understanding of the terms
> > > > > > as someone
> > > > > > > that has picked the spec up recently and tried to
> > > understand it?
> > > > > > > 
> > > > > > > There are four terms relating to network types - peer
> > > > > > network, service
> > > > > > > provider, SIP Service Provider and Internet
> > Telephony Service
> > > > > > > Provider.
> > > > > > > The document states that SSP and ITSP are synonymous,
> > > > > > although I might
> > > > > > > argue that an ITSP is a subset of an SSP, purely because
> > > > > > the 'T' part
> > > > > > > suggests a specific service attributable to the UA's
> > > > within that
> > > > > > > network and hence also implies something about 
> the way that
> > > > > > service is
> > > > > > > delivered (or at least ought to).  SSP is more general and
> > > > > > hence could
> > > > > > > include applications that do not have the same 
> requirements
> > > > > > on QoS and
> > > > > > > hence do not require the same DSCP marking, but if you are
> > > > > > all happy
> > > > > > > for these to be equivalent, I am not going to fuss about
> > > > > > the semantics
> > > > > > > of what is implied by 'telephony'.
> > > > > > > 
> > > > > > > Now I get slightly confused.  A Peer Network sounds
> > > > like it is a
> > > > > > > special case of an SSP - in effect a peered SSP.  Is that
> > > > > > correct?  If
> > > > > > > so I'd suggest for readability of the document, SSP is
> > > > > > defined before
> > > > > > > Peer Network, and Peer Network is defined as I
> > describe above.
> > > > > > > 
> > > > > > > Similarly, an SSP seems to be a specialised SP, 
> in that not
> > > > > > only does
> > > > > > > it provide L3 transport of SIP signalling and media
> > > > > > packets, but also
> > > > > > > includes SIP end points.  Similar to my last point, it
> > > > > > would help the
> > > > > > > document to define SP before SSP, so that the 
> definition of
> > > > > > SSP can be
> > > > > > > 'An SSP is an SP that also includes UASs and UACs...' and
> > > > > > then a Peer
> > > > > > > Network can be defined as '...an SSP that has connections
> > > > > > to peer SSPs
> > > > > > > via...'.  A nice hierarchical definition (start with the
> > > > > > broadest term
> > > > > > > and get narrower' generally saves a lot of
> > > > redefinition, which in
> > > > > > > itself can create ambiguity.
> > > > > > > 
> > > > > > > And that leads me quite neatly on to a question -
> > how are you
> > > > > > > classifying the transit or carrier network that would sit
> > > > > > between the
> > > > > > > SSPs to provide interconnectivity?  It is clearly an SP
> > > > > > since it will
> > > > > > > provide L3 transport of SIP and media, but if my comments
> > > > > above are
> > > > > > > right, SP is intended to be an umberella term
> > > covering all the
> > > > > > > sub-variants of SP.  It will also need to have some
> > > > > characteristics
> > > > > > > dependent upon whether it is expected to provide any
> > > additional
> > > > > > > functionality - it clearly needs to be DiffServ aware,
> > > > > but it could
> > > > > > > also be required to provide a bunch of functions around
> > > > > transcoding
> > > > > > > and reframing in the media plane, and maybe SIP variant
> > > > > > interworking,
> > > > > > > which could imply B2BUAs.  It seems though that this
> > > > > network, be it
> > > > > > > the internet or something provided by a carrier
> > > > operator is only
> > > > > > > alluded to in the definition of Federations.  Is there not
> > > > > > a need to
> > > > > > > identify it explicitly, even if it is far simpler
> > than I have
> > > > > > > conceived it to be?  I note that in the Architecture
> > > > document, in
> > > > > > > Figure 3 a 'Transit IP Provider' is identified
> > > > (although the text
> > > > > > > never refers to Figure 3 nor Transit IP 
> Provider), but then
> > > > > > in Figure
> > > > > > > 1 of the same document a whole bunch of terms not
> > > > defined in this
> > > > > > > document are used...
> > > > > > > 
> > > > > > > I'd appreciate at least comments on whether what I have
> > > > > laid out as
> > > > > > > the herarchy of these terms is right or not, but I'm not
> > > > > > going to get
> > > > > > > fussy about whether the proposed shuffle of the ordering
> > > > > > takes place.
> > > > > > > 
> > > > > > > Cheers
> > > > > > > 
> > > > > > > Dan
> > > > > > > 
> > > > > > > 
> > > > > > > > > > 14) "3.8. Service Provider
> > > > > > > > > > 
> > > > > > > > > >    A Service Provider (or SP) is defined to
> > be an entity
> > > > > > > > > that provides
> > > > > > > > > >    layer 3 (IP) transport of SIP signaling and media
> > > > > > > packets.  An
> > > > > > > > > >    example of this may be an Internet Service
> > > > > Provider (ISP)."
> > > > > > > > > > This at first glance is reasonable, but 
> then the next
> > > > > > > > > section goes on to
> > > > > > > > > > define a SIP Service Provider as something
> > that is not a
> > > > > > > > > special case of
> > > > > > > > > > a Service Provider, since it operates at
> > layer 5, not at
> > > > > > > > layer 3. We
> > > > > > > > > > should perhaps find a different term for "Service
> > > > Provider"
> > > > > > > > > when we mean
> > > > > > > > > > layer 3, e.g., "Network Service Provider".
> > > > > > > > > That's fine with me....although terms like this are
> > > > > > ambiguous.  I
> > > > > > > > > think we had specified Internet Service 
> Provider before,
> > > > > > > but there
> > > > > > > > > were arguments against being that "specific".  So, we
> > > > > > > > generalized the
> > > > > > > > > term and just provided it as an example.
> > > > > > > > [JRE] I think we have to do something. The term SP is
> > > > > OK if it is
> > > > > > > > intended to embrace all types of SP that we are
> > > dealing with,
> > > > > > > > including SSP. But if we need a term for an SP that
> > > > > > operates only at
> > > > > > > > layer 3, we need a different term.
> > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 15) "A SIP Service Provider (or SSP) is an entity
> > > > > > that provides
> > > > > > > > > >    application level transport of SIP 
> signaling to its
> > > > > > > > customers." 
> > > > > > > > > > Elsewhere the document talks about level 5
> > peering, but
> > > > > > > > now it talks
> > > > > > > > > > about application level. Also, isn't it 
> more than just
> > > > > > > > transport. I
> > > > > > > > > > don't have a particular proposal, but I don't
> > > really like
> > > > > > > > > the present
> > > > > > > > > > definition.
> > > > > > > > > 
> > > > > > > > > Hmmm...I'll see if I can think of something to make
> > > > > > this clearer.
> > > > > > > > > Anyone else have an opinion (heh...that's a stupid
> > > > > > > > question.  Everyone
> > > > > > > > > has an opinion, right?!)? :-)
> > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 16) "3.10. Internet Telephony Service Provider
> > > > > > > > > > 
> > > > > > > > > >    An Internet Telephony Service Provider, or
> > ITSP, is a
> > > > > > > > > synonym for
> > > > > > > > > >    SSP. While the terms ITSP and SSP are
> > > frequently used
> > > > > > > > > >    interchangeably, the SPEERMINT working
> > group uses the
> > > > > > > > term SSP."
> > > > > > > > > > So why define the term if we are not going to
> > use it? We
> > > > > > > > > could mention
> > > > > > > > > > it in a note below the definition of SSP, if
> > > > really needed.
> > > > > > > > > > 
> > > > > > > > > ....don't care either way...we can do that 
> to.  Does it
> > > > > > > > significantly
> > > > > > > > > make things simpler by doing as you suggest?
> > > > > > > > [JRE] The point is, by having an explicit definition of
> > > > > ITSP, it
> > > > > > > > tends to encourage other SPEERMINT documents to use it,
> > > > > > even though
> > > > > > > > there is an explicit statement that SPEERMINT will use
> > > > > > only SSP. I
> > > > > > > > thought just making it a note below the 
> definition of SSP
> > > > > > would help
> > > > > > > > to de-emphasise ITSP further.
> > > > > > > 
> > > > > > > Forthcoming GSMA Events:
> > > > > > >  
> > > > > > > GSMA Mobile Asia Congress
> > > > > > > Macau
> > > > > > > 12 - 15 November 2007
> > > > > > > www.mobileasiacongress.com
> > > > > > >  
> > > > > > > GSMA Mobile World Congress
> > > > > > > Barcelona
> > > > > > > 11 - 14 February 2008
> > > > > > > www.mobileworldcongress.com
> > > > > > > 
> > > > > > > 
> > > > > > > This email and its attachments are intended for the above
> > > > > > named only
> > > > > > > and may be confidential. If they have come to you in
> > > > > error you must
> > > > > > > take no action based on them, nor must you copy or
> > > show them to
> > > > > > > anyone; please reply to this email or call +44 207
> > > 759 2300 and
> > > > > > > highlight the error
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > Forthcoming GSMA Events:
> > > > >  
> > > > > GSMA Mobile Asia Congress
> > > > > Macau
> > > > > 12 - 15 November 2007
> > > > > www.mobileasiacongress.com
> > > > >  
> > > > > GSMA Mobile World Congress
> > > > > Barcelona
> > > > > 11 - 14 February 2008
> > > > > www.mobileworldcongress.com
> > > > > 
> > > > > 
> > > > > This email and its attachments are intended for the above
> > > > named only
> > > > > and may be confidential. If they have come to you in
> > > error you must
> > > > > take no action based on them, nor must you copy or 
> show them to 
> > > > > anyone; please reply to this email or call +44 207 
> 759 2300 and 
> > > > > highlight the error
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > Forthcoming GSMA Events:
> > >  
> > > GSMA Mobile Asia Congress
> > > Macau
> > > 12 - 15 November 2007
> > > www.mobileasiacongress.com
> > >  
> > > GSMA Mobile World Congress
> > > Barcelona
> > > 11 - 14 February 2008
> > > www.mobileworldcongress.com
> > > 
> > > 
> > > This email and its attachments are intended for the above
> > named only
> > > and may be confidential. If they have come to you in 
> error you must 
> > > take no action based on them, nor must you copy or show them to 
> > > anyone; please reply to this email or call [phone] and 
> > > highlight the error
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Speermint mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > > 
> > 
> > 
> 
> Forthcoming GSMA Events:
>  
> GSMA Mobile Asia Congress
> Macau
> 12 - 15 November 2007
> www.mobileasiacongress.com
>  
> GSMA Mobile World Congress
> Barcelona
> 11 - 14 February 2008
> www.mobileworldcongress.com
> 
> 
> This email and its attachments are intended for the above 
> named only and may be confidential. If they have come to you 
> in error you must take no action based on them, nor must you 
> copy or show them to anyone; please reply to this email or 
> call [phone] and highlight the error
> 
> 
> 

_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint