Minutes for DRINKS at IETF-interim-2011-drinks-1
minutes-interim-2011-drinks-1-00

IETF DRINKS INTERIM MEETING (81.5)
==================================
Aug 31, 2011 (Wednesday); 1p-5:20p (Eastern) / 17:00 - 21:20 (UTC)

Participants (in order of announcement on the bridge)
============
- Dean Willis
- Syed Ali
- Jeremy Barkan
- Ken Cartwright
- David Schwartz
- Manjul Maharishi
- Daryl Malas
- Dan Romascanu

Chairs
======
- Alex Mayrhofer
- Sumanth Channabasappa

Scribes
=======
- Alex Mayrhofer
- Syed Ali

ACTION ITEMS
============
[David S., 9/2] Present a proposal to allow for extensibility in an
interoperable manner. [Alex, 9/2]     Propose considerations around
internationalization [Chairs, 9/8]   Check with the ADs (or IESG members) to
see if we will need to refine the current separation of protocol and transport
documents [Authors, 9/8]  Incorporate comments based on the discussions at the
interim [Chairs]        Finalize a response to the ITU liaison statement
(https://datatracker.ietf.org/liaison/518/)

AGENDA
======
0/ Welcome and Administrivia
1/ OpenSPPP Demo  -- new item
2/ Review and resolve open items related to the following
 a) protocol draft
 b) transport draft
3/ Discuss and Respond to the ITU Liaison
4/ Open Discussion
5/ Next Steps

0/ Welcome and Administrivia
----------------------------
- Sumanth started the meeting and presented note well
- Call for scribes resulted in volunteers from Alex and Syed
- A new item was added to the Agenda -> OpenSPPP demo
There were no objections to this

- Discussion
Jeremy: Wants to check whether some functional aspects are covered in the
        protocol with respect to the use cases / requirements document.
        specifically, the route offer logic.
Sumanth: Let's discuss this during the protocol document discussion

1/ OpenSPPP Demo  -- new item
-----------------------------
- Dean and Jeremy provided an overview of the OpenSPPP demo
- Comments were also presented by the developers

+ Notes
- The system uses a MySQL database, implemented in Java, runs on top of Tomcat.

- Dean starts from database scheme "upwards", Organization table is discussed,
there is some confusion whether the Organization objects are used as rant or
rar's.

- Destinationgroup scheme - notes that foreign keys should be integers, rather
than strings.

- Dean shows adding, getting, re-adding a Destinationgroup, then trying to "get"
an unknown destination group. shows that deleting an already deleted destniation
group still returns success - intended?

- As organizational basis, sourceforge is used to collaborate.

- Dean: instructions on how to get the code, or play with the code. shows in
a term window how to pull the code and compile it. Deployment would be the
next step and standard tomcat container will do the job.

- Dean: bug tracking tool is actively in use

+ Alex: question-- how complete is this implementation
- (Dean) RouteGrp / RouteRec operations may not be complete. Route/NAPTR/URI
  handling is missing right now.
- (Dean) estimates that 20% of functionality is there
   and about 50% of needed total code written.

+ Q&A
- Get destination group without any key - should that return a list of all
destination groups? This does currently not work, could be a bug in the
implementation

- Ken noted that the use of rqstObj in a successful transation may
be incorrect. Dean to further look into that, and result of that
would either be update of spec, or update of OpenSPP code.

+ Ken: Public ID handling implemented yet?

- Jeremy: Vijay is handling the schema need to add the code

+ Ken: What about route grp offer

- Jeremy: needs to be implemented

+ Ken: What about the services and server status commands implemented?

- Jeremy: still needs to be implemented

+ Discussion
- (Jeremy) The solution seems to use generic SOAP, but relies on the XML
for functions for operations; this resulted in some overhead.
(Ken) indicated examples of netconf where the usage is similar
(Dean) expressed the need for separation of nouns and verbs
(David) Data Model discussions
   - Verbs are on top of the nouns
(Dean) Data Model, Operations and Binding need to be clear
(Dean) In summary, the implementation as we have specified works.
          However, we could make it better

- (Ken) Operations and data structure are defined in one document, and the
envelope is defined in a separate transport document. The reason for this
approach is that the verbs and nouns need to be defined in the first doc.
SOAP WSDL could be written to again write the operations again (RPC),
though it would be repetitive.

 - (Dean) Thought it is good to define verb and nouns in one document. Though
    it becomes restrictive because they cannot be used for other.

 - (Ken) Noted that going with another interface, such as, REST, brings its
    own restrictions.

 - (Jeremy) REST verbs may have more flexibility in mapping the operations to
    other interfaces.

 -  (Ken) Agrees that Fieldings explained how the ops and codes can address the
    needs for almost all transport needs, but the decisions were made in the
    beginning about the SOAP approach.

 -  (Sumanth) clarified a couple of things:
REST is an architectural principle. RESTful web services is the application
      of these principles via the use of HTTP.
(as chair) when we started the work we asked for volunteers to work on an
      alternative approach, including RESTful web services. However, there were
      no volunteers. We then took a poll on the extent of refinement. There were
      no strong recommendations, apart from the design team going with what we
      have today.

  - (David) verb as an api is an issue. REST or not may not be.

  - (Sumanth) data model discussion is open. clarified that we don't get
     wrapped with only two choices (REST vs SOAP) and acknowledged that there
     multiple choices.

  - (Ken) understands that to realize that vision there can be no XSD in the
     protocol. describe the structure and leave it the implementers to
     execute...

(15 min break)

2/ Review and resolve open items related to the following
---------------------------------------------------------

= Plan to discussing the following topics:

- security considerations
- data validation
- internationalization
- Additonally, questions raised by the OpenSPPP developers.

= Sumanth (as Chair) decides we start with the open questions from the
developers.

 a) Protocol Document
 (http://tools.ietf.org/wg/drinks/draft-ietf-drinks-spprov/)

   + Comments around the lack of separation around data model, operations and
   binding + (Dean) There are two options
Option 1: Separate the data model, operations and binding NOW
Option 2: Go ahead with the current limitations

     - (Alex) Let'S fix what is important to fix, and let's understand the
     limitation of the other data model problems. - (David) There is confusion
     around policy; metadata is not policy. Metadata allows you to build policy
     rules. As soon as you add extensions you may break interoperability since
     we don't have a clean mechanism to do this (e.g., cost etc.).

(Ken) It is unclear what is being asked for: is it a request for new elements
or a modification (David) There is no clear way to make extensions without
affecting interoperability (e.g. video) (Ken) sounds like new requirement and
welcomes new addition (Jeremy) interoperability is more important. (Alex)
Metadata not necessarily within scope? Is the extensibility mechanism we got
good enough? (David) thinks the extensibility mechanism is good enough, but we
need to decide whether we want to have certain things in the core,
           rather than in extensions.
(Sumanth) requested David to present a text proposal around this.
(David) Agreed. See AI.

    - (Dean) The layering of the protocol; separate the data and operations and
    place it in one document, then map this onto SOAP or other protocols.
we may find situations where the current data model doesn't work
we may have to then update the data model a little down the road
Alex: if something needs to be fixed in the future, let's fix now

    - (Dean) Approach to data - operation - binding is still an issue that we
    are not all on the same page.
(sumanth) agrees and asks what are we trying to fix first.
(Dean) layering of the protocol needs to be fixed. operations are part of
           the core. And this means that the operations need to be mapped again
           for other bindings such as CORBA, SOAP, REST etc.

(ken): XSD that is defined is not tied to SOAP. It can be tied to RPC, tcp, and
other flavors;
          it cannot be as cleanly mapped to interprocess methods/tech that want
          to specify operations in a particular way: REST, COBA, RMI. we can
          remove the generic binding from SOAP and move to the specific
          instance.

(Dean) what will change in the protocol document?
(Ken) things will be copied and reflected in the protocol document.

     - (Dean) suggested that perhaps we should ask the ADs or IESG members if
     the current split was sufficient - (Sumanth & Alex, as chairs) agreed. see
     action item.

     - (Sumanth, as chair) also wanted to take a poll to see what the
     participants here think.

     ==== Poll#1: Is the current split valid?

     Question is do we want to change the split between the documents, so that
     the "protocol" document can become more "generic"? + Option #1: Do nothing
     + Option #2: We do some work to make this better

      Alex   : Unless we need to get by IESG, go with #1 (-- as a contributor)
      David  : Unless we need to get by IESG, go with #1
      Dean   : Unless we need to get by IESG, go with #1
      Jeremy : Wasn't present for the poll
      Ken    : #1 is the preference; unless we need to!
      Syed   : #1 is the preference; unless we need to!
      Sumanth: Unless we need to get by IESG, go with #1 (-- as a contributor)

     Summary: Looks like we are ok with the current I-Ds, unless we are asked
     to change it.

     ==== Poll#1: Is the current, generic usage, of SOAP acceptable?
    + Option #1: Leave it as-is, i.e., Generic WSDL usage
    + Option 2: Modify WSDL operations so that individually address the nouns
    and verbs

      Alex   : #1 (-- as a contributor)
      David  : #2 (if it is a few hours worth of work)
      Dean   : #2 (#1 works, but #2 would make it simpler)
      Jeremy : Wasn't present
      Ken    : Either works
      Syed   : #1
      Sumanth: Either works  (--as a contributor)

     Summary: No strong consensus. Leave it as is.

= We then move onto SECURITY; Sumanth (as chair) requests Syed to present.

- (Syed) Suggested XML Signatures for non-repudiation
(Alex) this is not widely implemented so we should be careful
(Ken) What is the use of this if we already have other mechanisms for message
integrity (Sumanth) agree with Ken (Syed) Explained the need for
non-repudiation e.g., within Accounting where we need a mechanism to validate
in the aftermath. (Sumanth) agrees that this could be a valid case; however we
will need to be clear on how this would work (David) XML signatures may be a
good thing. (Dean) How does a client find out whether it is supported on a
server? (Jeremy) mechanics are simple, processes are much more complicated.
(Jeremy) Be careful as to what you specify since there are PKI and other
issues. (Alex) Make clear it's not required, because it tends to be a hassle to
implement. (Sumanth) suggested that we indicate repudiation as an issue and
present ways to solve them (e.g., XML signatures)

    Summary: Syed to clarify the security concerns and issues, and present XML
    signature as one of many options.

- (Dean) presents the problem of policy - where does that policy information
come from? Who can see, modify what, and how is that decision made..
  Other protocols do "example policies", and mention what's typically done.
Authentication credentials used to identify the client? Already there from
authenticating the SPPP session (request)? authorization step comes in addition
to authentication. (Dean, Ken, Syed, Sumanth) Multiple use cases were presented:
    - the case of registrar acting on behalf of another registrar is not
    considered. - registrants having two registrars can happen
Suggested that we perhaps add the registrar field back in, to aid with
authentication and authorization? (David) doesn't like the fact that the "rar"
field could contain completely random stuff, because it's defined in the client.
     "rar" that has been authenticated vs. "rar" that has only been "noted" in
     a field.

    Summary: After much discussion we decided to re-add the registrar ID.

= DATA VALIDATION
 - Alex presented a proposal to validate data
Questions were raised around the validation of IP addresses and Ken's earlier
comment regarding '+'
     in TNs - may not exist in non-E.164 number TNs
(Jeremy) says that validation proposal from Alex is about 98% complete -
discussion around
     IP address validation.

   Summary: Alex's proposal will be incorporated and further modifications will
   be made to IP address validation.

= Internationalization
 - Alex to propose text and/or a discussion.


3/ Discuss and Respond to the ITU Liaison
-----------------------------------------
 - skipped due to time constraints - chairs will discuss privately

4/ Open Discussion
------------------
 - Covered as part of #1; no time for additional discussion, please use the
 reflector.

5/ Next Steps
-------------
 - See "action items" above