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

[Hadriel Kaplan <[e-mail]>]

Yeah I'm with Tim on this - this does seem like putting the cart before the horse.  I have no doubt we will get use-cases and data-types that will cause debate in the WG, but that's partly what a WG is there to decide, no?

I don't think it will take too long to reject ones there isn't interest in, and we haven't needed to be able to point to a charter to say "out of scope" to do that usually in other WG's.  If there are ones brought forth there *is* interest in, then we can either spend time in a WG arguing over them, or spend the same amount of time arguing about it before a WG is formed.  At least with doing it in the WG, we can make progress on the ones that are less contentious.

Also, I don't think the type of data we've been talking about is going to constrain much anyway.  Items named "Routes", "relevant route names, identifiers, and services", and "route associations" are broad/generic enough to cover a whole lotta stuff.  We'll read into them what we want to read into them.

-hadriel


> -----Original Message-----
> From: Dwight, Timothy M (Tim) [mailto:[e-mail]]
> Sent: Wednesday, April 23, 2008 1:00 PM
> To: Daryl Malas; Hadriel Kaplan; Richard Shockey; Otmar Lendl;
> [e-mail]
> Subject: 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:[e-mail]]
> > Sent: Wednesday, April 23, 2008 11:48 AM
> > To: Dwight, Timothy M (Tim); Hadriel Kaplan; Richard Shockey;
> > Otmar Lendl; [e-mail]
> > 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:[e-mail]]
> > Sent: Wednesday, April 23, 2008 10:43 AM
> > To: Hadriel Kaplan; Daryl Malas; Richard Shockey; Otmar Lendl;
> > [e-mail]
> > 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: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Hadriel Kaplan
> > > Sent: Wednesday, April 23, 2008 11:34 AM
> > > To: Daryl Malas; Richard Shockey; Otmar Lendl; [e-mail]
> > > Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Daryl Malas [mailto:[e-mail]]
> > > >
> > > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/peppermint
> > >
> >
_______________________________________________
PEPPERMINT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/peppermint