Subject: [drinks] Draft minutes from the DRINKS design team call (2/22)

From: Sumanth Channabasappa <[email-masked]>
Date: Wed, 22 Feb 2012 10:16:11 -0700

IETF DRINKS DESIGN TEAM CALL 
============================
2/22/2012, 10:00a-11:10a (Eastern)/8:00a-9:10a (Mountain)
 
Participants
============
- Vikas Bhatia
- Dean Willis
- Jeremy Barkan
- Ken Cartwright
- Sumanth Channabasappa 

Apologies:
- Alexander Mayrhofer
- David Schwartz
- Syed Ali

ACTION ITEMS UPDATE
===================

General
-------
- [Ken, Vikas] Send a recommendation related to the representation of the SPID
- [WG] Make a decision around the peering offer/accept; see discussion below

Framework document
------------------
AI-1/ Address Diagram Inconsistencies (Vikas)
AI-2/ Investigate Route group offer generalization (David)
AI-3/ Propose text about structure of non-numeric PI (Ken, Vikas) (Originally listed as "Decide on type of CoR identifier)
AI-4/ TNType to RteRecRefType pointer: reconsider (David)
AI-5/ Remove priority from RteRecBaseType (Vikas)
AI-6/ Also add isinservice flag on RteRecBaseType (Ken, David)
("Define 'service' in the base route rec type was considered obsolete)
AI-7/ Move up "ttl" field to base route rec type (Vikas)
AI-8/ Reconsider "extension" options with new info (David)
AI-9/ Consider adding "service" field to Egress Route (David)
AI-10/ Discuss on mailing list how registry handles batches (Jeremy)
AI-11/ Review Security Cons section (All)
AI-12/ Organize early expert review of Security Cons section  (Chairs)
AI-13/ Clarify bulk operations and the DOS threat; also allow for the  rejection of bulk operations based on criteria such as size limitations, and a generic mechanism to return the reason in the response 

SOAP document
-------------
AI-13/ Clarify/remove definition of transaction id type (to "Token"), or remove definition from here (Vikas)
AI-14/ Evaluate whether to expand "Dtl" and make Type names consistent (Vikas)
AI-15/ Add max length to result code/message definition (Vikas)
AI-16/ Clarify behaviour/expiration of offers, include a lifecycle Diagram? (Alex, David)
AI-17/ Internationalization/Comparison Ops (Alex)
AI-18/ Ensure internal consistency on terminology and structure (David)
AI-19/ Clarify uniqueness of object-type names (Vikas)

AGENDA
======
1/ Discuss follow-up from interim
2/ Next Steps

NOTES
=====
1/ Discuss comments on the documents
   - We discussed comments shared by David Schwartz on the list; see: 
     http://www.ietf.org/mail-archive/web/drinks/current/msg01118.html

   + We spent quite a bit of time on the peering offer/accept. David's assertion that there are a few use cases that are not currently addressed were
     acknowledged, since the protocol was not meant to address everything. 
     > (Jeremy) made the observation that the protocol does a good job with registry provisioning (i.e., the transactional aspect), but lacks enough
       clarity around peering (offer/accept)
     > (Dean) suggested that perhaps we should stick to what the protocol does best, and defer what it doesn't to an external extension or a different
       protocol (outside of the current scope)
     > (Ken) indicated that while some of the use cases can be addressed, we would need to flesh them out more and this would take time and effort. 
       He was OK with removing the peering offer/accept, with the caveat that this will render the offer/accept non-standard and perhaps unaddressed
       (in a standard manner) for a long time.
     > (Vikas) was in favor of removing the current peering offer/accept.
 
     > (Sumanth) detailed a few options:
       A) Do nothing. (But this does not address the comment.)
       B) Leave the peering offer/accept in the document, but ensure it is extensible for future work.
       C) Remove the peering offer/accept and consider it out of scope

     > In general, there was agreement with B) - we need to discuss this on the list and get WG consensus since we are not going to be addressing
       a use case we agreed to. We should also consider the caveat from Ken while making this decision. 
       - Sumanth requested that we highlight this on the DRINKS mailing list

    + Towards the end we discussed the suggestion around batch request
      6. Batch request should be an implicit subscription. New method NOTIFY should be sent when processing is done including summary of the operation. 
   
      - (Jeremy, Dean) clarified that the intention was to have a response indicating 'I received the batch request' and a subsequent notification when
        the processing has been completed. 
      - (Ken) clarified that, currently, the operations are expected to be synchronous. He also added that batch provisioning was explicitly left out of
         scope, based on previous discussions. 
      - (Sumanth) confirmed, and added that there was a call for batch provisioning proposals at one point in time. In the absence of such proposals
        we decided to keep it out of scope. 

      - (Dean, Vikas, Ken, Sumanth) then discussed the possibility of DOS attacks and if we should say or do anything, e.g., limit the number of requests
      - (Ken) highlighted that DOS attacks are true of various API calls and that it is not unique
      - (Sumanth) indicated, and recommended, that we address it as a security threat and provide a mechanism for rejection with a reason (e.g., when the
        number of requests is too high).
      - (Dean) indicated that perhaps we could have a query mechanism to identify the number of supported transactions.
      - (Sumanth) suggested that one could also have a response mechanism within which such a limit is indicated (in lieu of a query mechanism)
      - (Dean) agreed that this was a possibility, provided it was clear enough
      - (Vikas) indicated that the reason such as mechanism is usually unspecified is because there are multiple ways to do it (e.g., byte size, # of transactions) 
        etc.
      - (Suamnth) agreed; now, that's the criteria for rejection, which can be left unspecified. The proposal is to provide a mechanism to convey this limitation
         so that the client can be made aware. 
      - (Vikas) agreed.

    - We also discussed the remaining action items and came to the following conclusions
   
    Action items currently exist for the following:
    3. IsInService should be attribute of routeRecord as well
    4. Need to have a URI type as a PI or else LUF resolution (URI) cannot be fed back into the system for LRF resolution.
    7. Diagram in SPPF doc should be cleaned up 

    Need more clarification around:
    5. Need to have in introduction option to just go identifier-> LRF without first LUF querying

    The note-taker (Sumanth) missed the conversation around the following:
    2. EgressRoute is just a special case of a RouteRule and should be made more general. This is needed as well to address the route manipulation aspect of sorceIdent flag.
    (Design team members, please clarify resolution on the mailing list.)

2/ Next Steps
   - (Authors) to continue incorporating comments
   - (Everyone) make progress on the action items

---

From: "Bhatia, Vikas" <[email-masked]>
Date: Wed, 29 Feb 2012 09:48:27 -0500

Hi,

With respect to AI-3 (Propose text about structure of non-numeric PI - see design team meeting minutes) below is the proposal:

Proposed structure for non-numeric PI:

  <complexType name="URIPubIdType">
    <complexContent>
      <extension base="sppfb:PubIdType">
        <sequence>
           <element name="uri" type="anyURI"/>
           <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

The key definition in the protocol shall be as follows:

    <complexType name="PubIdKeyType">
      <complexContent>
       <extension base="sppfb:PubIdKeyType">
        <sequence>
         <element name="rant" type="sppfb:OrgIdType"/>
         <element name="dgName" type="sppfb:ObjNameType" minOccurs="0"/>
         <choice>
          <element name="number"
          type="sppfb:NumberType"/>
          <element name="range"
           type="sppfb:NumberRangeType"/>
           <element name="uri"
           type="sppfb:URIPubIdType"/>
         </choice>
        </sequence>
       </extension>
      </complexContent>
     </complexType>

We currently have a "URIType" for RRs - so to avoid namespace conflict and for clarity the name of "URIType" shall change to "URIRteRecType"

    <complexType name="URIRteRecType">
     <complexContent>
      <extension base="sppfb:RteRecType">
       <sequence>
        <element name="ere" type="token" default="^(.*)$"/>
        <element name="uri" type="anyURI"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>

Let me know if anyone has comments/suggestions.

Thanks,
Vikas

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sumanth Channabasappa
> Sent: Wednesday, February 22, 2012 12:16 PM
> To: [email-masked]
> Subject: [drinks] Draft minutes from the DRINKS design team call (2/22)
>
> AI-3/ Propose text about structure of non-numeric PI (Ken, Vikas)
> (Originally listed as "Decide on type of CoR identifier)
> AI-13/ Clarify bulk operations and the DOS threat; also allow for the
> rejection of bulk operations based on criteria such as size limitations,
> and a generic mechanism to return the reason in the response
>
> SOAP document
> -------------
>    + We spent quite a bit of time on the peering offer/accept. David's
> assertion that there are a few use cases that are not currently
> addressed were
>      > (Jeremy) made the observation that the protocol does a good job
> with registry provisioning (i.e., the transactional aspect), but lacks
> enough
>      > (Dean) suggested that perhaps we should stick to what the
> protocol does best, and defer what it doesn't to an external extension
> or a different
>      > (Ken) indicated that while some of the use cases can be
> addressed, we would need to flesh them out more and this would take time
> and effort.
>        He was OK with removing the peering offer/accept, with the caveat
> that this will render the offer/accept non-standard and perhaps
> unaddressed
>      > In general, there was agreement with B) - we need to discuss this
> on the list and get WG consensus since we are not going to be addressing
>       6. Batch request should be an implicit subscription. New method
> NOTIFY should be sent when processing is done including summary of the
> operation.
>
>       - (Jeremy, Dean) clarified that the intention was to have a
> response indicating 'I received the batch request' and a subsequent
> notification when
>       - (Ken) clarified that, currently, the operations are expected to
> be synchronous. He also added that batch provisioning was explicitly
> left out of
>       - (Sumanth) confirmed, and added that there was a call for batch
> provisioning proposals at one point in time. In the absence of such
> proposals
>       - (Dean, Vikas, Ken, Sumanth) then discussed the possibility of
> DOS attacks and if we should say or do anything, e.g., limit the number
> of requests
>       - (Sumanth) indicated, and recommended, that we address it as a
> security threat and provide a mechanism for rejection with a reason
> (e.g., when the
>       - (Dean) indicated that perhaps we could have a query mechanism to
> identify the number of supported transactions.
>       - (Sumanth) suggested that one could also have a response
> mechanism within which such a limit is indicated (in lieu of a query
> mechanism)
>       - (Vikas) indicated that the reason such as mechanism is usually
> unspecified is because there are multiple ways to do it (e.g., byte
> size, # of transactions)
>         etc.
>       - (Suamnth) agreed; now, that's the criteria for rejection, which
> can be left unspecified. The proposal is to provide a mechanism to
> convey this limitation
>     4. Need to have a URI type as a PI or else LUF resolution (URI)
> cannot be fed back into the system for LRF resolution.
>     2. EgressRoute is just a special case of a RouteRule and should be
> made more general. This is needed as well to address the route
> manipulation aspect of sorceIdent flag.
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.