Subject: Re: [drinks] Rough Notes and AI list from the call on 6/3

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 16 Jun 2010 09:29:59 -0400

-----Original Message-----
From: Cartwright, Ken
Sent: Friday, June 11, 2010 12:11 PM
To: 'Sumanth Channabasappa'; Jean-Francois Mule; 'Alexander Mayrhofer'; David Schwartz; Maharishi, Manjul; Syed Ali
Cc: [email-masked]
Subject: RE: Rough Notes and AI list from the call on 6/3

I've submitted the preliminary SPPP over SOAP and HTTP document (what we call the "transport" document) as a WG doc.  Thanks Sumanth for the guidance.

http://www.ietf.org/staging/draft-ietf-drinks-sppp-over-soap-00.txt

Ken

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]]
Sent: Thursday, June 03, 2010 12:40 PM
To: Jean-Francois Mule; 'Alexander Mayrhofer'; David Schwartz; Cartwright, Ken; Maharishi, Manjul; Syed Ali
Cc: [email-masked]; Sumanth Channabasappa
Subject: Rough Notes and AI list from the call on 6/3

=======================================
IETF DRINKS REQS & PROTOCOL WEEKLY CALL
=======================================
6/3/2010, 10:00a-11:00a (Eastern)/8:00a-9:00a (Mountain)

=======================================
Participants (in order of announcement)
=======================================
- Alex Mayrhofer, enum.at GmbH
- Ken Cartwright, TNSI, Inc.
- Jean-Francois Mule, CableLabs (until 8:15a)
- David Schwartz, XConnect
- Manjul Maharishi, TNSI, Inc.  (>8:10a)
- Syed Ali, Neustar (8:15a)

- Sumanth Channabasappa, CableLabs

============
ACTION ITEMS
============
[David]
- Speak to some of the players (Rich, Gonzalo) regarding the Global SPID

[David]
- Provide thoughts on how best to represent priority values.

[Syed]
- Volunteered to put together examples based on the use cases

[Syed, Sumanth]
- Work on updating the use cases mapping document to contain requirement numbers.

[Ken]
Issues of active/inactive status for public identities.

[All]
Resolve the SPID issue?

======
AGENDA
======
- Discuss timelines for I-D updates and reviewers
- Global SPID
- Changes to the protocol documents
- Additional use cases

=====
NOTES
=====

= Discuss timelines for I-D updates and reviewers
  a) Non-transport protocol (Syed, Jean-Francois, Ken):
        - publish a wg draft-00 document by COB, Friday June 11
        - publish a wg draft-01 document by COB, Friday June 25

  b) Transport protocol (Ken):
        - publish a wg draft-00 document by COB, Friday June 11
        - publish a wg draft-01 document early July

= Global SPID

  (David) Are we going to wait for this to be solved for us, or should we do something?
  (Sumanth) Proposed the following:
      - Separate the protocol document from a direct dependency on the Global SPID resolution (e.g., leave it as a opaque string)
      - Work on a proposal independent of the transport protocol

      This will help us complete the current I-Ds on time, and not delaying them unnecessarily

      - After some discussion (Alex, David) we agreed with this.
      - In addition, David volunteered to check with Gonzalo and Rich regarding their thoughts on moving forward.

      -  (David) should we submit an -00 document?
      - Sumanth indicated that we should, if we have a proposal, unless there are other efforts.

      -  (Ken) cautioned that we should be careful about what we speak about when we said G-SPID;
          we are talking about administrative domains, not a generic Global SPID. We agreed.

      - (Ken) also reminded us that Rich took on ownership of this effort. David will check on this.

   Resolution: David to check on the best way forward.

= Changes to the protocol documents
  - (Sumanth) requested Syed and Ken to provide any main highlights based on their discussions
    (see the DRINKS mailing list for details)

  - (Ken) indicated that David had suggestions around priority values. For instance, same number in multiple destination groups.
  > AI: David to provide his thoughts on the mailing list.

  - (Syed) Raised the question as to whether we need a mandatory client transaction id? His proposal was to leave it optional on the client side, and conditional mandatory on the server side (i.e., if the client includes it in the request, the server includes it in the response)?
  > Resolution: After some discussion, David and Ken agreed that we could leave this optional.

  - (Syed) Should we use the terms COR and Transit, or Authoritative and non-authoritative?
  > Resolution: COR and transit

  - (Syed) Should the designation of COR and transit be explicitly indicated, or should there be a default - and where should this be reflected?
  > (Ken) recommended that this should be an attribute of the public identifier
  > AI: we agreed with Ken's recommendation

  - (Syed) Should we allow multiple requests within one?
  > Yes.
  > (Ken) will this be atomic?

= Additional use cases

David proposed the following use cases via email on 5/27; this was discussed earlier and David will follow-up.

1. Network management based load sharing/sequencing/failing: A network manager needs to assign priorities to routing elements within his/her network to allow for proper network management. This could include things like sharing or sequencing the load (load balancing) as well as providing for failure cases (hot standby).

2. Policy based traffic shaping: Need the ability to assign priorities to destination groups containing similar public identities. The priorities are needed for proper sequencing of the response set. Priority policy is out of scope.

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.