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

["Dwight, Timothy M (Tim)" <[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?
> 
> [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:

         + 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.


> 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.  

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.

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