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

>  -----Original Message-----
>  From: Dwight, Timothy M (Tim)
>  [mailto:timothy.dwight@verizonbusiness.com]
>  Sent: Wednesday, April 23, 2008 1:00 PM
>  To: Daryl Malas; Hadriel Kaplan; Richard Shockey; Otmar Lendl;
>  peppermint@ietf.org
>  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
>  
>  Well, limiting the scope sounds good.  But on what basis do we limit
>  it?

As a practical matter we limit WG scope to what the AD's are prepared
accept. 

In reality we are not limiting ourselves at all ..only limiting what we
attempt to do first. 

>  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