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

["Daryl Malas" <[e-mail]>]

Comments in-line... 

-----Original Message-----
From: Dwight, Timothy M (Tim)
[mailto:[e-mail]] 
Sent: Wednesday, April 23, 2008 11:00 AM
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?
[DM] For starters, we limited it as the charter already spells out...

"The DRINKS working group is chartered with a scope that is orthogonal
to SPEERMINT and ENUM.  The protocol work OF DRINKS will be designed to
build from the work of SPEERMINT and ENUM to identify and define the
data structures and data exchange protocol(s) among SIP based Multimedia
administrative domains.

These administrative domains may be of any practical size and could be
any type of SSP, such as recognized telephony carriers, enterprises,
end-user groups, or Federations.  Data exchanges among these
administrative domains may be bi-lateral or multi-lateral in nature, and
could include bulk updates and/or more granular real-time updates.

Typical data includes the mapping of phone numbers to URIs, policies
surrounding admission to various points of network interconnection, and
various other types of interconnect data.  In addition, there is a
specific need for the exchange of such data between the Registry and
various types of PSTN network databases.

The working group will draw upon expert advice and on-going consultation
from the ENUM and SPEERMINT working groups, and also the XML
Directorate.
The working group will consider the reuse of elements of RFC 4114.

The final work product(s) from this working group will utilize and be
based on XML documents and XML document exchanges."

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.

  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.

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?

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