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

[David Schwartz <[e-mail]>]

This is getting silly. If you take out federations you may as well  
take out enterprises as well. It never ceases to amaze me how one  
little word keeps making so many people feel uneasy.

I am against removing it.

D.

On Apr 21, 2008, at 9:26 PM, "Richard Shockey" <[e-mail]>  
wrote:

>
>>
>> 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
_______________________________________________
PEPPERMINT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/peppermint