Note Well presented verbally. Agenda : accepted. Status ====== Jouni presenting. 3588bis -- Victor Fajardo has no time to maintain. Jouni is taking it on for the moment. Need new editor for MIBs -- if no action, will drop. Lionel: Glen Zorn and Dan have been discussing. No comments. RFC3588bis Update ================= Jouni Korhonen AVP flags: Mark Jones proposed that we add the text "sender MUST set to 0, receiver MUST ignore". Agreed in principle. Will not address matter of application-defined flags, since nothing is broken. Jouni will propose text. No action on Grouped flag. Application can define one if needed. Result Codes: Jouni proposes to keep 3588bis aligned, retain 5016, put some note to explain difference from 3... SCTP data chunk protocol identifier: will reserve a non-zero value to make debugging analysis easier. Glen Zorn: some misalignment between the updated IANA section and the references to it in the body of the text. Jouni will propose text to the list. Diameter NAT Control ==================== Frank Brockners Review of Genart review comments. Entity naming issue. Glen Zorn: Diameter really being used as peer to peer protocol in this application. Use the term "peer". Mark Jones agrees. Roles are defined by the application. Lionel: agrees. Frank: how to distinguish the peers -- what terms? Mark Jones: NAT, NAT controller. Glen Zorn: labels don't matter, just make message flow clear at any point in time. Frank: lack of "client" and "server" bothers some people. Lionel: not a big problem. Just be clear that this is using a new architecture for Diameter. Glen: DIME shouldn't be overly concerned with preconceptions of external reviewers. Tom Taylor: can use the terms "requesting peer" and "responding peer" if discussing at an abstract level, otherwise use the concrete terms "NAT", "Nat Controller". Further discussion -- Frank worried because some people were so concerned with terminology. Dan Romanascu: confirm on list. Genart reviewer is effectively one member of the Working Group. Lionel: Frank to propose terminology on list, explaining the new Diameter architecture on the list. Further discussion, but effectively that was the conclusion. Note: some thought to fact to fact that this sets a precedent for the architecture. Realm-Based Redirect ==================== Reviewed list comments. Most can be dealt with easily -- present proposed text changes to list. On issue of changes to base behaviour of redirect agent, present issue to list for resolution. 4005bis ======= No activity. A review has been posted by Mark Jones. Diameter General Purpose Session ================================ Marco Liebsch Returning proposal (presented in IETF78, IETF79). Some 3GPP related activity on hold pending Dime acceptance. Basic idea: be able to run sessions applying to groups of users. Various coding proposals. Comments received. Proposal: split into two drafts to cover the two ideas: Diameter group sessions (shared session ID), encoding for bulk sessions (reusable for other session types) Glen Zorn: not an extension to the base protocol. Concerned that changing semantics will lead to interoperability problems. Non-AAA: not in charter scope. Lionel: let's first guage interest. Jouni: play with session, clobber applications. On the other hand, could have advantages. Mark Jones: generally useful, doesn't need justification by other SDOs, useful, supports. Dan Romascanu: yes, could be concerned about change in semantics. Broader question is whether it is in scope of Diameter. Does need charter change or new WG -- not AAA. Frank Brockners: question for clarification -- did he understand correctly that the bulk encoding would be reusable for other other applications? Marco: not usable by current applications, but could be used by new ones. Dan: understands Marco's interest, but this is definitely beyond the scope of Dime as currently constituted. Could work through 3GPP liaison channels to set work in motion. Jouni: could conceivably broaden charter. Dan: would like to see charter proposal, then get a view of consensus in this room and on the list. Mark Jones: other SDOs also have an interest in bulk signalling. Doesn't want to push too hard without seeing others' interest. Glen Zorn: inclination would be to call a BOF. Also noted that it is possible to split meeting time between interest groups. Frank Brockners: can be useful. Getting different solutions now -- standardization would be nice. Gave examples of TISPAN, 3GPP.\ Dan: would like to see charter proposal. Make clear that this extends the existing scope, make sure charter is not open-ended. Need usual assurance of availability of people to do the work. Could be extension of Dime or new WG. Glen: noted how two of the new AVT spinoffs met back-to-back in the same room. Lionel summed up resolution as above Other Business ============== Jouni Origin-Host and a Diameter node with multiple DiameterIdentity values. Base issue. Problem is that a host can contain multiple Diameter nodes, each of which can be identified by multiple FQDNs. Sec. 4.3 of 3588 says a Diameter node should (small letters) use a single identity. Sec. 6.3 says that an Origin-Host value is unique within the host. Jouni proposes text in 4.3 to ensure that a Diameter node always uses the same Origin-Host value for the life of the transport connection. Tom Taylor argued an interpretation of 6.3 that made it irrelevant to the question. 4.3 should be addressed on its own merits. Jouni clarified this is a problem when peers are directly connected and the request with the changed identity was not proxied. Could be a result of some kind of load balancer activity that does not implement Diameter protocol properly. Lionel Load balancing issue. Mark Jones suggested we had to pull in the vendors of load balancers to participate in DIME.