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

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

Richard,

I would assume the description in Section 3.3 of the Speermint
terminology draft is not substantial enough in provide a scope of SED
relative to DRINKS?  I would assume the described aspects of SED would
need to be provisioned and shared as necessary between peers.  We can
definitely get more granular, but I didn't know if this would work at a
high level.

--Daryl 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Richard Shockey
Sent: Tuesday, April 22, 2008 10:25 AM
To: 'Hadriel Kaplan'; 'Otmar Lendl'; [e-mail]
Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

Thank you Hadriel. 

Now after some conversations with our AD, I think we are in good shape
with the charter as its currently written including the rename. 

There is some clarification in the text I'll fix however there is a
strong suggestion that that we specify a more detailed list of SED data
to be addressed. That means expanding out this sentence below somewhat.
We don't need a exhaustive list only a list that sufficiently bounds the
work to be undertaken. In other words, the AD don't want us wandering
off the reservation.

"Typical SED data includes the mapping of phone numbers to URIs,
policies surrounding admission to various points of network
interconnection, and various other types of interconnect data."  

Anyone want to suggest some text?

>  -----Original Message-----
>  From: [e-mail] 
> [mailto:[e-mail]]
>  On Behalf Of Hadriel Kaplan
>  Sent: Tuesday, April 22, 2008 11:19 AM
>  To: Otmar Lendl; [e-mail]
>  Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  
>  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:peppermint-  
> [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

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