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

Well, limiting the scope sounds good.  But on what basis do we limit it?
How do we know that a proposed data model supports anything useful?  

I assume that proponents of a particular model will have some use
case(s) in mind.  So why not state them explicitly?  Then we can discuss
whether the resulting set of problems to be solved, is sufficient (and
sufficiently bounded).

To me this is simply an issue of determining requirements before we
settle on an implementation.  Settling on an implementation (data model)
first, will have the effect of bounding the set of requirements we might
satisfy.  But doesn't that seem backward?

Tim

> -----Original Message-----
> From: Daryl Malas [mailto:D.Malas@cablelabs.com] 
> Sent: Wednesday, April 23, 2008 11:48 AM
> To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey; 
> Otmar Lendl; peppermint@ietf.org
> Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> 
> I think the purpose here is to contain the scope of the charter.  The
> subsequent use cases will then be limited to the scope of the charter.
> If you do not clearly define the scope, then the use cases can run all
> over the place.  If this occurs, it just creates many years 
> of debate, a
> very frustrated set of co-chairs and working group.
> 
> I think this is the right approach, but we need to be careful 
> to balance
> putting enough detail in to clearly contain the scope without too much
> detail as to make the charter a working group draft.
> 
> --Daryl
> 
> -----Original Message-----
> From: Dwight, Timothy M (Tim)
> [mailto:timothy.dwight@verizonbusiness.com] 
> Sent: Wednesday, April 23, 2008 10:43 AM
> To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl;
> peppermint@ietf.org
> Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> 
> Do we have to determine the data model now?  This seems premature when
> we've not yet considered use cases. 
> 
> Tim
> 
> 
> > -----Original Message-----
> > From: peppermint-bounces@ietf.org
> > [mailto:peppermint-bounces@ietf.org] On Behalf Of Hadriel Kaplan
> > Sent: Wednesday, April 23, 2008 11:34 AM
> > To: Daryl Malas; Richard Shockey; Otmar Lendl; peppermint@ietf.org
> > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Daryl Malas [mailto:D.Malas@cablelabs.com]
> > >
> > > I recommend we further simplify:
> > >
> > > The scope will be limited to defining the following
> > criteria necessary
> > > for a SSP to respond with the necessary Session
> > Establishment Data (SED)
> > > for both internal and external purposes:
> > 
> > OK, so here you're defining the minimal data needed to be 
> exchanged by
> 
> > DRINKS, in order for an SSP to provide SED - right?
> > 
> > 
> > >         + Routes
> > >                 - Destination SIP/SIPS/TEL URI Egress and
> > Ingress Routes
> > >                 - Relevant route names, identifiers, and services
> > >                 - NAPTR context and associations
> > 
> > When you exchange data, it may be in the form of a NAPTR in 
> syntax and
> 
> > maybe even semantics, but it's not really a "NAPTR" DNS entry - it 
> > just happens to be that you chose to format the resultant route 
> > information in the form of a NAPTR.  So I think the word "NAPTR" 
> > shouldn't be in the charter's list of data to be exchanged.  We may 
> > just happen to use that format in the end for the data, but there's 
> > nothing about the data that demands it. (and in fact I personally 
> > think it's confusing and misleading to be using that 
> specific format 
> > in the data exchange directly, but we can argue about that later :)
> > 
> > 
> > >         + Service Areas
> > >                 - Individual, ranges, or groups of ENUMservice 
> > > identifiers
> > >                 - Route associations
> > 
> > I don't know what a "Route association" is?
> > 
> > 
> > >         + Treatment Profiles
> > >                 - Priority
> > >                 - Location
> > 
> > I note this doesn't directly include originating or source 
> > information, which is fairly essential to SIP routing, afaict.  Is 
> > that something you'd classify under "route associations" or 
> "treatment
> 
> > profiles", or do you specifically not want that in the charter?
> > 
> > -hadriel
> > _______________________________________________
> > PEPPERMINT mailing list
> > PEPPERMINT@ietf.org
> > https://www.ietf.org/mailman/listinfo/peppermint
> > 
> 
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.ietf.org/mailman/listinfo/peppermint