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

[Hadriel Kaplan <[e-mail]>]

Hi Otmar,
I don't disagree with some or many of our points, but I don't think we need to hash them out for the charter.  I think we can discuss these in the actual WG, after the charter is approved.  Nothing in the charter limits our ability to do that as far as I can tell. (right?)

-hadriel


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Otmar Lendl
> Sent: Tuesday, April 22, 2008 10: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