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

On 2008/04/20 06:04, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
> > 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.

This makes sense.  

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

Then let's take "federations" out of this definition NOW.

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

A "registry" within a SSP is simply a "database". The word "registry"
implies some kind of centralized database (with a provisioning and an
access protocol). If that is not what we have in mind here, then we
need to avoid the word "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)

Do you see such an item in the speermint milestones? I don't.

IMHO we need something like RFC 1034 for the whole speermint /
peppermint setup.

/ol
-- 
// Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.ietf.org/mailman/listinfo/peppermint