[11:47:21] --- loughney has joined
[12:04:59] --- Dave Nelson has joined
[12:05:14] <Dave Nelson> review of mielstones
[12:05:33] * Dave Nelson has changed the subject to: DIME WG Meeting at IETF-67
[12:10:45] <Dave Nelson> discussion of Diameter application design guidelines
[12:11:15] <Dave Nelson> how to label new applications and new versions of existing applications?
[12:13:35] <Dave Nelson> John L. volunteers to write up a "brain dump" on how to deal with these application identity issues.
[12:14:06] <Dave Nelson> Dave K. O&M AD takes note of late milestones.
[12:15:21] <Dave Nelson> Discusion has been held on what should go into the base revision draft and what should go into an extension.
[12:16:13] <Dave Nelson> Q: Status of Diameter SIP.
[12:16:45] <Dave Nelson> JL: Now an RFC, folks should be implementing, the mailing list would be a place to discuss that.
[12:17:59] <Dave Nelson> GZ: Suggestions, API useless until protocol is revised. On the current API draft, shut "ship it". URI is basically done. Just "ship it".
[12:18:38] <Dave Nelson> GZ: QoS, good in theory. Approach to editing is unclear.
[12:20:06] <Dave Nelson> Hannes thinks that Glen Zorn is the editor. This comes as a surprise to Glen. Plese send him the source code, and he'll edit it.
[12:21:52] <Dave Nelson> GZ: Question on procedure on recycling a PS vs progressing to DS.
[12:22:14] <Dave Nelson> Presentation by Victor F.
[12:24:00] <Dave Nelson> Review of Issue Tracker status.
[12:26:01] <Dave Nelson> Add clarifications to the URI scheme to the 3588bis draft.
[12:27:22] --- m_ersue has joined
[12:27:52] <Dave Nelson> Discussion of Applications IDs. Issues with use of Ap ID 0?
[12:28:56] <Dave Nelson> Issue seen in the field where there are relay agents in front of load balancers.
[12:31:13] <Dave Nelson> GZ: Not teh original intent. The document is curently confused. Two kinds of messages. Inter-Diamter messages, e.g start a session between peers, exchange capabilities. Second king is messages to support applications. Approriate for those messages to use an Ap ID, but not 0.
[12:32:23] <Dave Nelson> May need to update any RFCs that specify to use Ap ID of 0 for these non-code messages. But what would be the impact to fielded implementations?
[12:32:53] <Dave Nelson> Recommendation is to not use Ap ID 0 in these cases.
[12:34:22] <Dave Nelson> What is the implication of a message that is defined in the base protocol being reused in an application?
[12:34:57] <Dave Nelson> Needs to be addressed in the Diameter applications guidelines. Need to have a discusson on this issue.
[12:36:45] --- keyajima has joined
[12:37:30] <Dave Nelson> Resolved issues will be added to the 3588bis draft.
[12:42:33] <Dave Nelson> Issue 13 needs some clarifying text as to "why it's there".
[12:44:52] <Dave Nelson> GZ: Recollection about why there were two Ap IDs. One in the header. Need to be able to distinguish an NAS appllication thay is accounting. One or the other of the IDs is supposed to be nothing or be accounting.
[12:45:36] <Dave Nelson> GZ: Does not affect routing because all applications include accounting.
[12:46:13] <Dave Nelson> GZ: But maybe acocunting is a useless feature, since so few applications actually include it.
[12:49:25] <Dave Nelson> Q: Regarding expected behavior on errors and retries. When to retry?
[12:49:56] <Dave Nelson> JL: File as a formal issue.
[12:50:39] <Dave Nelson> Presentation on Mobile IPv6 Dimater support. HA-to-AAA support. Juilen B.
[12:53:24] --- keyajima has left: Replaced by new connection
[12:53:39] <Dave Nelson> New application only for the authorization actions.
[12:57:02] <Dave Nelson> May need an authentication token, provided by one AAA to be presented to another AAA, to provide proof of previous authentication.
[12:58:20] <Dave Nelson> GZ: Agrees that authen, authoriz and acct all need to be bound. Simpler way than using a token. Define Diameter MIP6 as Diameter EAP, using a separate Ap ID. Then you need only one AAA server.
[12:59:09] <Dave Nelson> GZ: Splitting the servers isn't a good idea.
[12:59:52] <Dave Nelson> Splitting the servers isn't required but should be supported.
[13:00:13] <Dave Nelson> GZ: Yes, but the security analysis is simpler if it's all one server.
[13:02:17] <Dave Nelson> MN: Sees the same conerns with binding.
[13:03:19] <Dave Nelson> Yes, but it is the HA that talks to the second AAA, and th HA is a trusted party.
[13:04:07] <Dave Nelson> C: In EAP the MN communicates directly with th HAAA, right?
[13:04:51] <Dave Nelson> C: How do you relate that session to a subsequent one, authorized by a different server? How would th HA know which AAA server performed the original authentication?
[13:05:03] <Dave Nelson> Works the same way as accounting works.
[13:08:14] <Dave Nelson> Lenghthy, back and forth discussion of this issue ensued.
[13:09:27] <Dave Nelson> GZ: It's fine to trust the HA, but it's better not to if you don't have to.
[13:16:49] <Dave Nelson> Issue, how would the IKEv2-R know that IKEv2-I wants MIP6 service?
[13:17:31] <Dave Nelson> GZ: If you re-use the Diameter EAP application, with changes, it solves this problem.
[13:25:34] <Dave Nelson> JL: Thinks the need for split scenario, with its attendant issues of binding, needs to be justified in order to go forward.
[13:26:26] <Dave Nelson> Presentation on NAS-to-HAAA interface for MIP6 bootstrapping.
[13:26:49] <Dave Nelson> Jouni M.
[13:27:25] <Dave Nelson> Draft checked against MIP6 AAA Goals.
[13:27:53] <Dave Nelson> 4 issues raised and discussed on the list.
[13:31:12] <Dave Nelson> Hannes: Call for expert review.
[13:31:50] <Dave Nelson> JL: Looking for reviews completed by the next IETF meeting.
[13:35:17] <Dave Nelson> Yoshi: Question about mandatory natur eof added AVPs.
[13:35:45] <Dave Nelson> JL: Yoshi, please submit a document review.
[13:36:07] <Dave Nelson> Presntation by Tina on QoS draft.
[13:38:47] <Dave Nelson> Hannes: Like ot have different strawman proposals to review. Up to the WG to decide which approach to follow.
[13:41:42] <Dave Nelson> JL: Soliciting comments on the list, as to pros and cons of each approach, and issues of interest to the reviewers.
[13:42:29] <Dave Nelson> Problem in finding a common set of QoS parameters that will meet everyone's needs.
[13:44:54] <Dave Nelson> Hannes: Different SDOs use different data structures. We want to be in sycn with our own IETF efforts in the Transport Area, and NSIS WG.
[13:45:26] <Dave Nelson> Q: How far down the road is everyone with these data formats?
[13:45:34] <Dave Nelson> Q: Too far to make changes?
[13:46:07] <Dave Nelson> JL: Mix of L2 an L3 QoS.
[13:47:12] <Dave Nelson> C: Many SDOs have stable releases with existing data structures.
[13:48:23] <Dave Nelson> GZ: Hardest task is the abstraction of QoS into a generalized concept.
[13:49:26] <Dave Nelson> JL: There is ongoing work in NSIS to define QoS formalisms.
[13:50:55] <Dave Nelson> DR: Faces with a problem that needs to be decomposed. We are not chartered to define a data model for QoS. Have a clear reference to a document of the information model we want to use.
[13:54:05] --- Dave Nelson has left: Replaced by new connection
[13:56:02] --- Dave Nelson has joined
[13:59:54] <Dave Nelson> AD: Bring the two documents together.
[14:00:34] <Dave Nelson> Presentaion by Dong Sun on Diameter Resource control Application.
[14:02:11] <Dave Nelson> Focuses on QoS wuthorization triggered by path-coupled signalling (e.g. RSVP/NSIS).
[14:09:40] <Dave Nelson> DR: There is a good reason for separatation for separation of application layer network control plane. This level of control is not typical in today's ISP deployments.
[14:10:53] <Dave Nelson> Push model, pull model, need for an integrated model.
[14:12:32] <Dave Nelson> Functional model where resoruce control server is the Diameter server and the resource control client is the Diameter clienjt.
[14:16:27] <Dave Nelson> Presentaion on Diameter Interop by Arun Handa.
[14:17:04] <Dave Nelson> Looking for feedback on holding another interop session.
[14:17:45] <Dave Nelson> IntelliNet will be hosting. Chosen Orlando Florida, USA for a site.
[14:18:21] <Dave Nelson> January 22 - February 9, 2007. Will that be OK?
[14:19:04] --- m_ersue has left
[14:19:10] <Dave Nelson> Venue at Valencia Community College, Enterprise Center. Room for30 persons
[14:19:59] <Dave Nelson> Will provide static IP addresses.
[14:20:44] <Dave Nelson> Will not rely on DNS services for realm-based routing decisions.
[14:21:12] <Dave Nelson> Remote connectivity options?
[14:22:00] <Dave Nelson> Requires the remote site to have the Cisco VPN Client on the remote end.
[14:22:32] <Dave Nelson> The campus is served by (2) T1's.
[14:23:38] <Dave Nelson> Proposing 3 day event.
[14:24:13] <Dave Nelson> Areas of interest for protocol testing? Basics? Advanced featrues?
[14:25:51] <Dave Nelson> Hannes: We have a test suite document. Looking for feedback to be sure that the test cases are event-structured?
[14:26:00] <Dave Nelson> Volunteers solicited.
[14:26:44] <Dave Nelson> Open mike section of the meeting.
[14:27:10] <Dave Nelson> GZ: The best forum for this presentation (interop) is the mailing list.
[14:28:00] <Dave Nelson> Hannes: Need sufficient advance notice to get the broadest participation.
[14:28:32] <Dave Nelson> C: Competion of recnet interop event. Have some test cases and test results.
[14:28:54] <Dave Nelson> Will feed in any useful results.
[14:29:42] <Dave Nelson> End of the agenda. Out of time. Two presentations skipped. Please send summary for discussion on the list.
[14:30:23] <Dave Nelson> <EOM>
[14:30:34] --- Dave Nelson has left
[14:32:24] --- loughney has left
[14:48:17] --- loughney has joined
[14:50:02] --- loughney has left
[14:53:33] --- frank has joined
[14:54:27] --- frank has left