[drinks] non numeric PI

["Bhatia, Vikas" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Sumanth Channabasappa
> Sent: Wednesday, February 22, 2012 12:16 PM
> To: [e-mail]
> Subject: [drinks] Draft minutes from the DRINKS design team call (2/22)
>
> 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
>
>
>
> _______________________________________________
> drinks mailing list
> [e-mail]
> 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.