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

["Dwight, Timothy M (Tim)" <[e-mail]>]

Richard, 

> >  
> >  Richard,
> >  
> >  It is precisely because this is a bounding exercise, and
specifically a
> >  bound placed on potential solutions, that this is a concern.  We
are
> >  trying to define the solution before defining the problem.
> 
> No there is no definition of the solution here.  Remember that is the
IETF.
> It is a requirement of  new WG's that the scope of the proposed work
be
> properly bounded so that WG do not go "wandering off the reservation".
It
> not about defining the solution as much as defining what the 
> WG will NOT do.

To define what the solution will not be, is to constrain the solution.
That's my point.  Is it not sufficient, to keep the WG "on the
reservation", to constrain the problem space (rather than the solution
space)?  Obviously you have more IETF experience than me, but in my
experience when working groups struggle it's more often because they
lack clarity with respect to the problem they're trying to solve.


> >  Basically I find this debate contradictory.  If the text starting
> >  "Typical SED data types might include..." below is truly meant only
as
> >  examples that might or might not be part of the eventual solution
> >  developed by the WG, then it doesn't bound squat. 
> 
> I beg to differ. In the context of IETF WG charters this is perfectly
> acceptable problem scoping. It does not propose a data model.

We are in violent agreemnt that the *problem* needs to be scoped.  But
the text in question says nothing about the *problem*.  It only proposes
"typical SED data types".  Whether you consider that a data model or not
(sure looks like one to me) I don't see how it constrains the problem.


> > and it doesn't accomplish anything, let's
> > delete it and declare victory.  

To your question at the end, this is my proposal.


> > If on the other hand its intent is to
> > function on a bound on potential solutions, then it's disingenuous
to
> >  refer to it as "Typical" and say it "might" include... more honest
> >  words would be something like "the WG will be strongly incented to
use the
> >  following data model...".  To which I would object.
> 
> 
> Well what is your proposed WG scope text? 

See above.



> Again (with some frustration) ... if anyone has a problem 
> with the current
> text then they had better come up with what they propose at 
> the alternative.
> I'm simply going to ignore any more objections that do not 
> propose real
> alternatives to the text.

I'm sure we can all agree to ignore each other.  I'm not sure what that
accomplishes.  


> 
> 
> >  
> >  Tim
> >  
> >  
> >  > -----Original Message-----
> >  > From: Richard Shockey [mailto:[e-mail]]
> >  > Sent: Thursday, April 24, 2008 9:31 AM
> >  > To: 'PFAUTZ, PENN L, ATTCORP'; 'Hadriel Kaplan'; Dwight,
> >  > Timothy M (Tim); 'Daryl Malas'; 'Otmar Lendl'; 
> [e-mail]
> >  > Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter 
> ..comments please.
> >  >
> >  > I think we are all talking past each other here .. this is a
> >  > charter.  This
> >  > is about what we might do not what we will do.. This is 
> a bounding
> >  > excersise.
> >  >
> >  > What I have now is
> >  >
> >  > **************
> >  >
> >  > More specifically, DRINKS will provide details of how Session
> >  > Establishment
> >  > Data (SED) is collected, what comprises SED, how SED 
> should be used
> >  to
> >  > properly identify an optimal path to a destination SIP user
> >  > agent (UA), and
> >  > the secure manners in which SED and the SIP session data is
> >  exchanged
> >  > between the peering functions.
> >  >
> >  >
> >  > Typical SED data types might include:
> >  >
> >  > + Routes
> >  >      - Destination SIP/SIPS/TEL URI Egress and Ingress Routes
> >  >      - Relevant route names, identifiers, and services
> >  >      - NAPTR context and associations
> >  >      - PSTN database information
> >  >
> >  > + Service Areas
> >  >      - Individual, ranges, or groups of ENUMservice identifiers
> >  >      - Route associations
> >  >
> >  > + Treatment Profiles
> >  >      - Priority
> >  >      - Location
> >  >
> >  > Potential SED Data types not in scope will be session rating or
> >  other
> >  > billing or pricing information between SSP's
> >  >
> >  > **************
> >  >
> >  >
> >  >
> >  >
> >  >
> >  > >  -----Original Message-----
> >  > >  From: PFAUTZ, PENN L, ATTCORP [mailto:[e-mail]]
> >  > >  Sent: Thursday, April 24, 2008 8:02 AM
> >  > >  To: Hadriel Kaplan; Richard Shockey; Dwight, Timothy M (Tim);
> >  Daryl
> >  > >  Malas; Otmar Lendl; [e-mail]
> >  > >  Subject: RE: [PEPPERMINT] DRINKS PROPOSED Charter
> >  > ..comments please.
> >  > >
> >  > >  Putting the Service Area concept in the charter still gives me
> >  > >  heartburn. If Drinks is about more than ESPP that doesn't
> >  > make sense.
> >  > >  If
> >  > >  you want to introduce the concept of some aggregate 
> later, after
> >  > >  robust
> >  > >  discussion, fine. Not all of us are ready to drink 
> the kool-aid.
> >  > >
> >  > >
> >  > >  Penn Pfautz
> >  > >
> >  > >  -----Original Message-----
> >  > >  From: [e-mail]
> >  > [mailto:[e-mail]]
> >  > >  On Behalf Of Hadriel Kaplan
> >  > >  Sent: Wednesday, April 23, 2008 11:45 PM
> >  > >  To: Richard Shockey; 'Dwight, Timothy M (Tim)'; 'Daryl
> >  > Malas'; 'Otmar
> >  > >  Lendl'; [e-mail]
> >  > >  Subject: Re: [PEPPERMINT] DRINKS PROPOSED Charter
> >  > ..comments please.
> >  > >
> >  > >
> >  > >  > -----Original Message-----
> >  > >  > From: Richard Shockey [mailto:[e-mail]]
> >  > >  >
> >  > >  > No one is proposing a solution. We are describing  
> that we do
> >  not
> >  > >  propose
> >  > >  > exchanging data on Collateralized Debt Instruments 
> and Mortgage
> >  > >  Interest
> >  > >  > Swaps among SSP's
> >  > >
> >  > >  Sure, I'm all in favor of getting a charter approved
> >  > post-haste.  Even
> >  > >  if it means my ideas for "Mortgage Interest eXchanges"
> >  > (MIX) will have
> >  > >  to wait for a charter update.  (too bad too, 'cause a
> >  > draft-drinks-mix
> >  > >  would have been a recipe for success in my opinion)
> >  > >
> >  > >  But seriously, how "detailed" do we need to be in the charter
> >  > >  regarding
> >  > >  this data?  I think Daryl's proposed data with some 
> minor nits is
> >  > >  broad
> >  > >  enough not to cause heartburn later, while not letting us
> >  > get drunk in
> >  > >  the possibilities. :)
> >  > >
> >  > >  How about this:
> >  > >
> >  > >  [begin]
> >  > >  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:
> >  > >
> >  > >          + Routes
> >  > >                  - Destination SIP/SIPS/TEL URI Egress 
> and Ingress
> >  > >  Routes
> >  > >                  - Relevant route names, identifiers, 
> and services
> >  > >                  - Attributes affecting route selection
> >  > >          + Service Areas
> >  > >                  - Individual, ranges, or groups of user-agent
> >  > >  identifiers
> >  > >                  - Route-to-service-area associations
> >  > >          + Treatment Profiles
> >  > >                  - Priority
> >  > >                  - Location
> >  > >
> >  > >  The mechanism(s) chosen should be extensible, in case 
> additional
> >  > >  criteria are deemed necessary to achieve the goals of 
> the WG in
> >  the
> >  > >  future.
> >  > >  [end]
> >  > >
> >  > >  -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