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

["Richard Shockey" <[e-mail]>]

>  
>  Daryl,
>  
>  > 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?

But not in a WG charter ... eyes on the prize here folks. We can get a
charter approved pretty quickly and form the WG if the scope of what we
propose to do _first_ is sufficiently bounded. 


>  >
>  > [DM] Instead of explicitly defining the model at this point, I
>  believe
>  > we are trying to describe well-understood characteristics of
>  > the model.
>  
>  That sounds fine.  But maybe we're talking past each other.  I'm
>  responding to what appears to me to be a much more specific proposal,
>  that the supported data look something like this:

I think the operative term is "supported data MAY include" .


>  
>           + Routes
>                  - Destination SIP/SIPS/TEL URI Egress and Ingress
>  Routes
>                  - Relevant route names, identifiers, and services
>                  - NAPTR context and associations
>  
>          + Service Areas
>                  - Individual, ranges, or groups of ENUMservice
>  identifiers
>                  - Route associations
>  
>          + Treatment Profiles
>                  - Priority
>                  - Location
>  
>  That looks like a data model to me.

Now I'm getting confused. 

So BTW will have to be included. " Data types not in scope will be session
rating or other billing information between SSP's" 

Are we getting close here?

>  
>  
>  > Then we can discuss whether the resulting set of problems to be
>  > solved, is sufficient (and sufficiently bounded).
>  >
>  > [DM] IMHO, this BoF would not have had 2 successful sessions, and
>  have
>  > multiple drafts already proposed if the problem statement was
>  > not pretty well understood.
>  
>  Is it written down anywhere?
>  
>  
>  > 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?
>  >
>  > [DM] If you say you need to build a car...then you say we are going
>  to
>  > limit the scope to a seat, an engine, and some wheels; is that
>  > describing the implementation model?  All we said is...we need to
>  build
>  > a protocol (as described)...let's limit the scope to some SIP, some
>  way
>  > to identify user agents, and some way to know how to get between
>  > them...have we described the implementation model already?
>  
>  In saying you need to build a car, you are defining the solution not
>  the
>  problem.  What are the requirements?  It may turn out that you need a
>  pickup truck or (gasp) a minivan, not a car.
>  
>  I think the limitations in scope you state here, are better than those
>  implied by what I construe as a data model, above.  They're at least
>  directionally correct, meaning we are moving away from a proposed
>  solution and toward an understanding of the requirements.

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

>  
>  I also agree that we need both requirements and bounds on the solution
>  space (which is what I think you mean by scope).  I think the two have
>  to mature at the same time though.  What I'm sensing here is that one
>  (bounds on solution space) is out in front of the other (explicit
>  definition of requirements).  That's what makes me uneasy.  For
>  example
>  right now I'd agree that we will only use IETF protocols.  Until I
>  understand the requirements better I don't know that I'd accept a
>  restriction that SIP be the only protocol.

SIP is certainly not the only protocol nor is ENUM the only query mechanism.
If someone wants to use DRINKS for the exchange of H.323 gateway information
they certainly can.
>  
>  tim

_______________________________________________
PEPPERMINT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/peppermint