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

["Daryl Malas" <[e-mail]>]

Otmar,

Keep in mind, there is no limitation for federations to peer, much like
SSPs.  Therefore, to use your bird analogy, two flocks can peer and two
birds could peer.  You are right, a flock is not a bird; however, the
provisioning and exchanging of the data should be very similar if not
identical in methodology between the two distinct entities.

--Daryl 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Otmar Lendl
Sent: Tuesday, April 22, 2008 8:45 AM
To: [e-mail]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

On 2008/04/21 20:04, Richard Shockey <[e-mail]> wrote:
> >  
> >  > > 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? 

Because a SSP can be a member of multiple federations. Now, if you plan
to build a registry similar to a LERG/NPAC database, then you'll have to
deal with multiple federations inserting data about the same numbers.

That's the point where the registry moves from a store of authoritative
information of "who owns a number" and perhaps "what is the URI for the
number" to a distribution mechanism of routing announcements, where
there can be multiple possible records (=routes) per destination.

This has a profound impact on the overall design. Imagine that a domain
registry allows the provisioning of records concerning a domain by
multiple registrars at the same time. Yes, it's possible to build a
system based on this premise, but we need to make this explicit.

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

A federation is defined as a set of SSPs. 

Any terminology where "X" and "set of X" is of the same type is likely
to be flawed. (e.g. a "a flock of birds" cannot be a "bird")

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

Fine. Then what about describing this in the charter properly. e.g. by

 Administrative domains may exchange data directly between each other
or might use an external registry (perhaps operated by a federation)  to
aggregate data from multiple administrative domains into  a single view.

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

<tongue in cheek>
So the aim of peppermint^Wdrinks is to move the PSTN thinking and
databases into an IP based setting? Will this be anything more than just
porting the concepts behind LERG/NPAC/NICC/... to SIP? 

Will there be any innovation in call routing, or are we just replacing
aging provisioning protocols with new ones, while retaining the
dependency on unloved fat registries?

As we're saying good-bye to the end2end principle for VoIP routing, is
falling back to the PSTN way of routing calls really the path the IETF
should be choosing?
</t-i-c>

Other open questions: 

* Will DRINKS just consider "push" style provisioning protocols,
  or will DRINKS also look at on-demand lookup protocols towards
  these registries?

* Speermint has separated out the LUF (who owns the destination?)
  from the LRF (What's my SED towards the destination network?).

  Given the fact that DRINKS is supposed to build upon speermint,
  can you make clear whether DRINKS is about the LUF or the LRF?

  Or are we mixing up these things *again*?

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

So you want to define a set protocols without having a reference
scenario against which to test whether the protocols do what we want?

Good plan.

As it has worked so brilliantly for speermint, we have to replicate it
in DRINKs as well, don't we?

/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