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