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

Guys,

I apologize if my previous comments came across as a little frustrated
with the discussion.  I am just concerned we will continue to go around
and around on nuances without moving forward.  We should/must take the
time we need to make sure everyone is "generally" moving in the same
direction.  We do not want a situation where some do not understand the
purpose of the working group; however, I think sometimes we can nit pick
things too much.  I just don't want to be discussing the charter for
another 6 months, and if you think that is exaggerated; there are plenty
of examples in the IETF to point at...you can start with the speermint
terminology draft. ;-)  I just want to avoid arguing the differences
between a sofa and a couch. :-)

--Daryl 

-----Original Message-----
From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
Sent: Wednesday, April 23, 2008 11:27 AM
To: Dwight, Timothy M (Tim); Daryl Malas; peppermint@ietf.org
Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter ..comments please.

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: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?
> 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