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

["Richard Shockey" <[e-mail]>]

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

Why will this bit us? 


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

I'm not convinced this is a problem.  Frankly its splitting hairs on
terminology. I don't understand why a federations could not be considered a
SSP? But if there is consensus on taking it out .. OK.


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

Right ..

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

NO.

The notion of 'a registry' is well understood in this context.  Namely a
"trusted source of data" which multiple SSP internally or externally may
draw data from. Instead of SSP bi-laterally exchanging data, which is OK,
SSP could use a registry to aggregate their data for re-distribution. No
different from Domain Name operations or Centralized Numbering Databases
like the NPAC or the UK NICC.

A registry may be the 'trusted source of data' internal to the network as
well that redistributes data to local databases or caches. This is the way
the world works today in phone networks. A SSP may need to aggregate
multiple data sources' in to a internal registry for distribution to
localized databases, typically known as Service Control Points in PSTN
speak..

Which is different than a database is a structured format for organizing and
maintaining information that can be easily retrieved.

There is a very logical difference between the notion of a registry and a
database. 

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


Well Hadriel is right ... that is a Speermint issue. 

And I've sent the last revision to the AD's for comments. We'll see what
they have to say.


>  
>  /ol
>  --
>  // Otmar Lendl <[e-mail]>, T: [phone] - 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
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/peppermint

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