Subject: [drinks] DRAFT minutes of the DRINKS design team call on 2012-05-31

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 6 Jun 2012 10:18:17 +0000

All, 

please find the minutes of the design team call on May 31 attached. Sorry for the late action - i was travelling the last two days.

Alex

--
DRAFT minutes DRINKS design team call May 31 2012
=================================================

Participants
------------

- Vikas Bhatia
- Manjul Maharishi
- David Schwartz 
- Dean Willis
- Alexander Mayrhofer
- Syed Ali
- Ken Cartwright
- Sumanth Channabasappa 

ACTION ITEMS
------------

1/ Re-Check the URI Type definition text in context of the SEDFunctionType 

addition - David (+all)
2/ Change rteRecType to SEDRecType (+related types) - David
3/ Add SEDFunctionType - David

Agenda
------

1/ Work on documented open issues

Minutes
-------

The group continues with the discussion of the "categorization" issue.
David has sent a proposal to the mailing list:

http://www.ietf.org/mail-archive/web/drinks/current/msg01194.html

Ken: Who would be using that - David and Syed saying they 
will be using such a mechanism.

Ken: Naming - asks what is the difference in the actual action once such info
is encountered during lookup? why not call it LRF and LUF ? David says terms are 

ambigiuous. 

Calling it "lookup" and "routing" would be better. Group agrees to use 
the following snippet (also replacing the "undefined" enum value with an 
minOccurs 0)

<simpleType name="SEDFunctionType">
  <restriction base="token">
    <enumeration value="routing"/>
    <enumeration value="lookup"/>
  </restriction>
</simpleType>

<complexType name="SEDRecType" abstract="true">
  <complexContent>
    <extension base="sppfb:BasicObjType">
      <sequence>
        <element name="sedName" type="sppfb:ObjNameType"/>
        <element name="sedFunction" type="sppfb:SEDFunctionType" minOccurs="0"/>
        <element name="isInSvc" type="boolean"/>
        <element name="ttl" 
                 type="positiveInteger" minOccurs="0"/>
      </sequence>
    </extension>
  </complexContent>
</complexType>

Vikas mentions that there is some text in the existing definition 
of the URI type regarding the use of information and dereferencing - 
this could overlap with info here? - David agrees we need 
to re-read the URI specification.

David offers to re-read the URI type specs, and propose changes.

ACTION ITEM: Re-check the URItype text - David & all

Decision: Change Rte* to SED* - David has the ACTION ITEM to change this.

Vikas notes that both the Framework and SOAP document are affected

Q: Anybody opposed to adding the FunctionType?
Vikas: Adding the function type is fine, as long as we solve the URI 
problems discussed before. Keep the discussion about the values open. 

Ken: we identified the two type names, let's go with them.
David: No open string, we have two use cases, let's stick with them.

Decision: Add the FunctionType, keep "lookup" and "routing"

Q: Rename?
Yes, decided - rename.

Last remaining sub-issue:

replace all rectypes with URI+ereg. Alex explains that this is not 
possible since the dns: URI type reflects only DNS *queries*, not response 
data.
Dean agrees that it's fine.

David: peering / route group offer generalization offer can 
now be closed, since it's an SEDGrpOffer

other open issues:

I18n - need to propose text (Alex)
DoS - need to talk it through (Jeremy, Ken?)