Subject: [drinks] DRINKS Meeting Notes.

From: "Richard Shockey" <[email-masked]>
Date: Thu, 9 Apr 2009 16:06:09 -0400

IETF 74 DRINKS WG agenda - with embedded notes
          ========================
          
     Data for Reachability of Inter/tra-NetworK SIP (drinks)
          
     TUESDAY, March 24, 2009
          
     0900-1130 Morning Session I
          
     Continental 1&2 RAI  drinks Data for Reachability of Inter/tra-NetworK
SIP WG

     Chair(s):
     ---------
          
     Richard Shockey <[email-masked]>
          
     Alexander Mayrhofer <[email-masked]>
          
     WG Secretary:
     -------------
          
     Deborah Guyton <[email-masked]>
          
     RAI Director(s):
     ----------------
          
     Jon Peterson <[email-masked]>
     Cullen Jennings <[email-masked]>

     RAI Area Advisor:
     -----------------
          
     Jon Peterson <[email-masked]>
          
     Agenda:
     =======
          
     0. Welcome / Note Well / Agenda bashing (Chairs, 5m)

     Notes: There were no changes or additions to the agenda.

     1. Document status (Deborah Guyton, 5m)

Notes: Debbie reviewed active contributions. She provided a brief overview
of the
Requirements Design Team purpose, meeting structure and major participants
and
contributors working on the usecases and requirements draft.

     2. DRINKS use cases / requirements (Sumanth Channabasappa, 60m)
          
        Title      : DRINKS Use cases and Protocol Requirements
        Author(s)  : S. Channabasappa
        Filename   : draft-channabasappa-drinks-usecases-requirements-02.txt
        Pages      : 22
        Date       : 2009-02-03
          
        This document captures the use cases and associated requirements for
        interfaces to provision session establishment data into SIP Service
Provider
        components that aid with session routing.  Specifically, the current
version
        of this document focuses on the provisioning of one such element,
termed the
        registry.
          
        A URL for this Internet-Draft is:
 
http://www.ietf.org/internet-drafts/draft-channabasappa-drinks-usecases-requ
irements
-02.txt

Notes: There was a request for a show of hands as to who had read the
document.
Approximately 15.

Sumanth started with a recap of the components, the scope, terminology, and
entity-relationships. He discusssed the three current use case categories.
He provided a one line summary of each use case identifying each by Use Case
Number.
He asked for questions. 

John Elwell had a question - who has access to the registry? As each service
provider peers with others they need to have access to the registry.  How
many
registries will exist?

Alex said the protocol should not be determining the number of registries.

John asked about registry to registry interactions.

Rich said that is an item on the agenda to be addressed: Registry to
Registry.

Martin Dolly - Here did the design team end up with LRF/LUF?  Sumanth
answered that
we did not include that distinction in our requirements.

Jabber - Dan said that it seems like one big registry in the sky.  Design
team said
no! What is missing is registry to registry. All agreed that we need to add
use cases
in this area. Alex reiterated that we want the Working Group (WG) to
participate and contribute input.

Ken Cartwright said that the scope diagram does show registry to registry -
there
will be more than one.

Adam Uzelac said he took an item from SPEERMINT to look at the impact of
LUF/LRF but
we seemed to ignore it.

Sumanth said we made a concious effort to distinguish this and discussed it
at length
but could not make a distinction.

Rich said we punted the issue because we need to get a framework or
superstructure
for the use cases established. The Design Team was to come up with a rough
architecture. The WG needs to progress this.

John referred to the scope document and wanted to see different registries
with
different sets of SSPs. Alex said he would clarify.

Ken said we must distinguish beteween LUF/LRF.  Otmar did talk about
layering. Until
we make this distinction, we are pressing on.

Rich mentioned the ENUM contribtion on trunkgroup data.  Daryl Malas was
asked to
summarize.

Daryl said he wasn't sure how he wanted to answer the question. SPEERMINT
5486 has definitions of LUF/LRF and those definitions are complete. There
seemed to
be less arguments than expected.  For WG SPEERMINT co-chair - the issue
seemed to be
solved. But that's separate.
ENUM draft - For the ENUM service type defined for trunk, in general folks
thought
it wasn't valuable and not a valid approach.  Wanted to query on a TN - in
the query
for LUF, you want to get LRF info - trunk group to route to. You can put
4904
parameters in a NAPTR.

Jean Francois Mule - i don't think the LUF/LRF discussion is relevant.  We
had 4
sessions discussing it and it had no meaningful impact on requirements. In
the data
model we should support elements that support lookup functions. Some said we
will do
dynamiclookup.  Some said we should include some LRF. We seem to have these
discussions over and over again.
Jean Francois Mule asked "what needs to be resolved"? If you have issues,
send text.

Hadriel Kaplan - I don't want to talk about that topic.  My point is about
the trunk
group topic. The reasone the trunk group service made sense to me is that it
is
optional. With the current draft you might get these parameters back and you
don't
know whether you process it or pass it on.  If you have a service type, If
you don't
process locally you just pass it on.

John Elwell had a question about destination groups - e.g., *example.com. We
don't
say anything about SIP URI at this time.  Would it be wildcarded?

Alex said if you have millions and millions of identifiers, if you have to
change
something about the routing, we only want to change the routing behind it
with a
detination group. Currently it is an abstraction.

Sumanth moved on to review the requirements - There are two kinds: data and
functional. These are numbered in the draft.  Some are more developed than
others.
He reviewed the list of requirements.

Eric for the Jabber room - David doesn't like the term "COR" as it feels
like a 
telco thing - maybe "primary provider".   Alex - who is allowed to provision
isn't
specified in the protocol - it can be implementation specific.

Rich - and we don't want any discussions of who 'owns' a public identity.
That's
a rat hole.

Alex asked, is everyone confused or contemplating whether there are
additional use
cases to be defined? Are folks just digesting?

Hadriel - there is a requirement that a provisioning protocol support an
extensible
list of future elements. Which is the key versus the key lookup? Look up key
is TN.
Also, why distinguish between a TN and an RN?

Manjul - RN could be aggregated. You know that you have done a portability
dip
beforeyou query if you query on an RN - you need to know if you are querying
for
a TN or an RN.

Hadriel -the database query client has to know what to query, If the
database has
to have a different entity type, it has to convey that to the local
resolver. There
is no way to do this today.  Basically at the resolver, a key must be used
to
lookup and get a result. They both work the same way.  The resolver needs to
know
what key it is getting.
Hadriel - the real question - is there a difference in the answer - if yes,
we have
a problem.

Jabber - David - are there any routing ownership to the Public Identify or
is it
just an identifier?  In the protocol it is just an identifier. You can't use
3263
for it. They can't put the domain name in it. Not a sip URI.

Ken cartwright - we don't want to issue new data types we don't need. But TN
and
RNs are different. A use case, if you know it is an RN, you can look up
ownership
in NPAC with confidence. If you have a TN you don't know. We have customers
who
explode out an rN to the TNs it represents.

Alex - as Otmar noted, the use cases are affiliated with PSTN things.  We
would
like additional use cases that are not that tightly associated with the
PSTN.

Darryl Malas, while we may chose to say we want to use sIP for non-TN based
applications, the broadest application is PSTN replacement.

Alex - it's good to know what else is out there. We need to know other uses
beyond
voice application. 

Jabber - if you want non service provider use cases, submit non service
provider
use cases.

Hadriel is it for e164 number use case routing or non - e.g., email style
(non
"+ starting", non digit strings) is this the use case we are looking for?
Is
public identify more than a TN? Alex says it can be something else.

Jon Peterson - my understanding is that it is non TN specific.

But all admitted 95% of use cases are tN oriented.

Sumanth - we have had discussions on transit providers. Otmar sent across
good
commmentsand thoughts. Questions? Other use cases and requirements?

Jabber - David - how do you prioritize service providers if you don't use
COR?

Manjul use ENUM preference and order and SIP priority.

Hadriel - definitely in favor of having it become a WG draft.

Rich - This is version 00 of a working group draft.  Need to have the WG
progress
this.

Daryl this is to frame the work - not define the solution space.  Good work
to
get this effort going on use cases and requirements.

Jabber - Otmar - most requirements assume there is a registry. This is
putting
the cart before the horse.  They need to decide what data a registry needs
and
then decide if they need a registry to put the data in.

Alex said to reference his draft to review elements that may be aggregated
versus exchanged peer to peer.

Alex - now we would like to ask the WG if they accept as first WG draft.
Needs
broader scope from WG.  Took a hum. Folks are in favor of adopting this
effort
as a WG document.

Alex - Once this document becomes stable we can progress the work on the
protocol. Asked that Sumanth still serve as the edit or the document.
Sumanth
said 'sure'.

     3. SED Elements (Alex Mayrhofer, 20m)

       Title       : Potential Elements of Session Establishment Data
       Author(s)   : A. Mayrhofer
       Filename    : draft-mayrhofer-drinks-sed-elements-00.txt
       Pages       : 6
       Date        : 2009-03-04
          
       This document provides a list of potential Session Establishment Data
Elements 
       in the Scope of SPEERMINT/DRINKS work.  The list is provided to seek
input from
       the community, and with the intent to aid in the definition ofDRINKS
       requirements/protocols.

     A URL for this Internet-Draft is:
 
http://www.ietf.org/internet-drafts/draft-mayrhofer-drinks-sed-elements-00.t
xt

Notes: Alex presented. he thought it might be useful to identify data
elements from
a bottoms up approach.  This is just a list of data elements that may be
needed for
peering. He also referenced the "Hancock" draft. If folks thinks this is a
useful
exercise we can expand the list and review the data.

John - I thought we would be looking at a query and get back SED, do we need
to
know who the user is. The LRF cannot give you the user data.

Hadriel- I'm confused.  I thought it was the data we need to get back to
route for
a query.  But the list goes beyond that. Not possible to go through this
list - as
a vendor we have over 1200 possible configurable elements.  We need to come
up
with a list of what we do need, maybe major attributes that we need.  We
could
extend the list in the future.

Rich asked should it be the maximum number of parameters or a minimum
subset.

Hadriel - obviously the minimun set.  Should not include constraints.

Alex - we should try to get it down to the minimum set and not include items
not
relevent to routing. Do not list data that would be exchanged in the actual
session.

Manjul - you need to know about the media and codec in the peering part.

Alex - my broader question is - is it useful to progress - I only have a
shopping
list now.

Jabber - David, keep it to a simple minimal set.

Eric - if you have lots of stuff, you are begging for disaster.  

Hadriel - of course the SBEs should know about bandwidth - in the forwarding
plane, but should not be part of the registry or database.

Alex how do they know about bandwidth?

Hadriel today it is an SLA. Today each other does not provision each others
routers
or SBEs.  Can not expect someone else to control your equipment.

Daryl Malas - it is a little early to hash out.  The registry is likely to
have
CNAME (ENUM working group) you can do queries without ever processing a
call.
You said SED talks about data for the next hop.  If I'm going to route  to
an
ingress point, I might need to know where I egress. These would be valuable
and
should have a framework around it and be part of this draft.

Jon Peterson - has to be a distinction of static information on a registry
and
real time forwarding decisions.  Make the distinction. Draw a line and
declare
before we go forward with the document. We can go forward with what Hadriel
said
and draw this line.

Alex - would anyone who knows more about this than I do, pick up the draft
and
extend it or add data elements.

Rich said the concensus I hear is a) this is useful to define the necessary
data
elements of SED, 2) minimal subset, and 3) static versus dynamic data.

John Elwell - SED will include some dynamic data, but not a concern in
DRINKS. We
should focus on the static part. SPEERMINT should define the SED.  Then the
aspects of provisioning should be the charter of DRINKS.

Daryl malas, speermint co-chair, i don't think we should define the SED - we
define what it is but we don't define all of the attributes.  We define how
SSPs
peer and what they need to peer. What they need and attributes to complete a
negotiation is not in SPEERMINT.

John Elwell, suppose you want to get to Destination X.  Provisioned data may
say
go via A, but if A is not available go by B.  SED may say go via either A or
B.

[Note that when folks were discussing information about LUF versus LRF, they
were
saying "hmm" versus "hmm", not again wanting to get into details of
distinguishing
each.]

Daryl Malas - if we hum every time we say L*F, I might go insane. Let's
figure out
later if LUF or LRF. First come up with the appropriate data. Let's define
what
we need to do. Then define the spec around it.

     4. Discussion: Private use of DRINKS protocol (Richard Shockey leads,
20m)
          
     Issues involving how provisioning Private Peering data fits into the
DRINKS model.

Notes: Alex - an example is between SSPs.

Rich said this came up also as registry to registry in an SSP to SSP
concept. The question is do we need to come up with use cases to cover this?
Do we need to flesh
it out or let the implementation determine this with the existing use cases?
Do we
have a definitive statement on that?

Hadriel - statement of private versus public?

Rich said bad use of terms. The current scope is SSP to SSP or registry to
registry.
We haven't discussed bi-lateral or pairwise use of the protocol.

Hadriel said yes.

Rich said nothing in charter says pairwise is out of scope.  We haven't
explicitly
called out use cases for this.

Hadriel says it depends on the architecture. Whether you discuss LUF or LRF.
For
LRF you need a requirement to prevent loops. You don't need to worry about
this
for LUF. As the connections are a mesh and not fully hierarchical.

Alex - we shouldn't preclude any use of the protocol. There has been mention
of enterprise PBXs. We need use cases.

Daryl malas - short answer - There should be an ability to provsion registry
to
registry.How different is that from what is described in the use cases
today? You
have to able to identify a set of TNs from an enterprise - these are unique
to this enterprise. If globally unique, then you are getting to what Otmar
is saying -
example, there are going to be global registries. For this enterprise you
can
query up to the LUF. Need a use case that says this can be used for registry
to
registry provisioning.

Jon Peterson - I have no objection that this is within the scope of drinks -
when
we get into more detail, it may be a different protocol for registry to
registry.

Jabber - David said we need to cover a pull or subscription.  The local
stores
don't have a mind, just local stores. He volunteered to write the registry
to
registry use case.

     5. WG Status / Milestones Discussion (Alex Mayrhofer leads, 10m)

Notes: Alex covered the list of milestones. Requirements 9/08; Protocol
11/08 for
data providers to registry; 2/09 exchange of SED from registry to LRF
databases.
We need to update these.

Daryl had a question for the WG to consider, there probably are some more
things
to consider for registry to registry - consider as separate work from
provisioning
into a registry. Jon mentioned that it could end up having functionality
different
from provisioning a registry. There should probably be a separate document
for
defining these use cases.   And allow the current document to move forwrad.

Ken said we need to understand that, let's see what the use cases are, then
decide
if it needs to be separate or not.

Adam Uzelac - I agree with Ken, I dont see what would be different.

John Elwell, the question I raised about SED data - is it truly data that is
provisioned?

Alex - SED is derived from the provisioned data.

Alex - We had a rough idea to start a design team for the protocol itself.
Now
that we have adopted the use case doc as a WG item, we shoud add additional
use
cases. I'd like to get a feeling whether the approach for a design team for
the
protocol would fit as a way to go forward. My concern was that the WG
discussion
after our design team was low volume.  I want folks working once they
commit.
Silence was frustrating.

Ken cartwright - some feedback - the good thing about the design team was
there
were weekly meetings that gave progress.  If we move away from this
approach, we
need something else to create progress checkpoints - like weekly.

Spencer -  keep the notes on the main mailing list. This was agreed to.

Rich - are we ready to commence this as the use cases are in an advanced
stage?

Daryl malas - start the work as there are not major arguments against the
use
cases.

Spencer - I echo that, it's a long time until the next IETF - late July -
let's
start it.

Sumanth - having a design team continue working on the protocol may identify
additional requirements and use cases. Let's progress it.

Rich - let's form a design team for the protocol.  Operate in the same
manner,
weekly phone calls, and minutes be published on a regular basis.

The action item is for the chairs to draft up ideas to proceed. Solicit
volunteers
from the list.

Jabber - David - need to also get concensus on registry to registry info.

Eric - be careful starting too soon and say we've done so much on protocol
we
can't change for new use cases.

Daryl Malas, we moved forward on drafts but then waited for terminology.
but
relatively quick to align these.  The same thing can occur with minimal
amount
of risk.

David - did ask if the design team can deliberate with a conference bridge.

Alex- but need regular paricipants so we constantly don't explain earlier
decisions.

     6. General Discussion ... / AOB

Notes: The meeting ended.

Richard Shockey
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101 

LinkedIn : www.linkedin.com/in/rshockey101