Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Otmar Lendl
> >
> > PROPOSED CHARTER FOR PEPPERMINT
> >
> > The IETF has been working on various aspects of SIP-enabled Multimedia
> > administrative domains among SIP Service Providers (SSPs. SSP's are
> entities
> > that provide session services utilizing SIP signaling to their
> customers. In
> > addition, the IETF has done significant work on data exchanges among
> various
> > network elements.
>
> As these term are central to this charter, can you clarify:
> Are "administrative domains" meant as equivalents to "autonomous
> systems" in the BGP context?
> Is an "administrative domain" usually the same as a SSP?

My interpretation of an "administrative domain" is just a set of SIP resources under control of a single administrator entity.  So for example, a set of proxies in an Enterprise acme.com may be one administrative domain; or it may be that ny.acme.com is a distinct administrative domain from dc.acme.com or wien.acme.com.  In other words, yes I think an SSP is an administrative domain, and is a similar concept as BGP AS's (but obviously orthogonal to actual BGP AS's).  It is likely we will have to define how to identify an administrative domain for the purposes of a protocol, but we can do that in the docs if we need to.


> > These administrative domains may be of any practical size and could be
> any
> > type of SSP, such as recognized telephony carriers, enterprises, end-
> user
> > groups, or Federations.
>
> I think we have a problem here. IMHO we should not mix single SSPs
> (carriers, enterprises) with groups of SSPs (federations). This will
> bite us when doing the protocol design.

I don't think that sentence restricts it, since it says "could be" and we can later decide to restrict it further, but yeah it's weird to think of a Federation as being an SSP.


> > Data exchanges among these administrative domains
> > may be bi-lateral or multi-lateral in nature, and could include bulk
> updates
> > and/or more granular real-time updates.
> >
> > Typical data includes the mapping of phone numbers to URIs, policies
> > surrounding admission to various points of network interconnection, and
> > various other types of interconnect data.  In addition, there is a
> specific
> > need for the exchange of such data between the Registry and various
> types of
> > PSTN network databases.
>
> Whoa, hold your horses.
> "the Registry?"

That should be "a registry".

> Nothing up to here requires a Registry. From the preceding paragraph:
> we're dealing with "bi-lateral or multi-lateral data exchanges". If
> two SSPs have a bi-lateral data exchange, they don't need a Registry.
> "multi-lateral" exchanges could also be facilitated by a simple data
> replicator, similar to the role of "route reflectors" in BGP.

I had the same worry as you, but I think we'd just say "a registry" is simply consumed inside one or both of the SSP's.  I've always assumed a registry is simply a data store for LUF data - there could be many such data stores, and their data is either internal or external to an SSP or both.  For a bilateral peering model, SSP1 needs to learn the LUF data from SSP2's internal registry, and SSP2 needs to learn the LUF data from SSP1's internal registry.


> > PROPOSED GOALS AND MILESTONES
>
> What about writing a
> High-level description of the overall VoIP routing architecture,
> players and data-flows.
> first?
>
> That is sorely missing in speermint.

Isn't that Speermint's role to do?  (I'm not clear on that either)

-hadriel
_______________________________________________
PEPPERMINT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/peppermint