Notes for DIME Virtual Meeting, Feb 19, 2009 -------------------------------------------- * WG Status - RFC 5447 published - API Draft still waiting for update * QoS parameter Martin : We view priority as different from Qos parameters. Priority handling is done separately but related to QoS. Certain levels are related by they are different. ??? : Concerned why priority is lumped together in QoS Martin : Example: pre-engineer a VPN with certain QoS. Priority is something that is added on top of QoS. So this is mixing apples and oranges. Tom : Are they in the same controlling entity ? Martin : Generally no. We engineer QoS based on traffic. Tom : My use case is PCN termination. Martin : In the case of the US, we do not do pre-emption. QoS and priority is related by they are different. Hannes : All parameters come from RSVP. Martin : But RSVP deals with media priority. In 3GPP, diameter is signaling. Hannes : Understand where the point is heading. Example is application-level resource priority. Martin : There's a debate going on what's the proper AVP to use for priority. All the interface in-and-around HSS. There's no impact to the media, it's just signaling. Hannes : What specifically should be clarified in this document ? Martin : From service provider, the end-user is always not trusted. Hannes : This document just list a couple of AVPs but does not specify their use. It points to the documents where these AVPs come from. We did not go into details on how they are used in specific use cases. Did not think this was an issue. ?? : ALRP has references to session layer but some confusion in other references. Hannes : Some documents has a different uses for ALRP. Trying to figure out if the reference to the specific document is correct. Martin : We would run additional authorization procedures for entities not perceived to be secure. We don't assume where the policy decision and policy control are being made. We run into problems when we make this generic. Hannes : Need to figure out the way forward. Hannes : Pls post a mail on the list summarizing this issue. * Base Protocol Glenn : Would like to roll over nai doc into bis Victor : Would prefer to keep it separate Mark : Need to move forward with the bis so not including nai is ok Hannes : Stick with the decision we made a few months agod Victor : Rev up the version number because of backward compatibility issue Glenn : Agree Hannes : Make an announcement on list of the rev increase Glenn : Change bis heading to clearly include rev number * QoS attributes Status - Ready to go on submission to IESG No comments * Diameter ERP Status - Initial Rev. Many aspects are not yet clear. Hannes : Impression that you have to define a new app-id. Glenn : There's a mis-understanding of hokey. Current assumption is that this just a diameter problem. In hokey, we have not specified the fact there is separate hokey server. So using to the same proxy for round-trip path is not correct. In re-auth, there is not even a need for a proxy to be involved. If diameter is used, a new app-id is needed. Sebastian: You want to send key material even you don't know who gets it ? Glenn : The hokey server will get it. It just needs to be notified and key sent to it along with identifying material. Hannes : We need to have an architectural diagram in this document. Glenn : Too tight coupling with diameter infrasturcture and hokey infrastructure. They are different. Need to fix that in hokey. Hannes : We should go forward with the document at least with the issue related to diameter. Document needs to be change such that you define a new diameter id. * Mip6 split Hannes : Document is with the AD. Will check with Dan on the status. * PMIP6 Hannes : When is the new doc ready ? Jouni : As soon as new reviews are ready * Routing Status Update Glenn : Don't understand the diff between combined server and client and a proxy Tom : Understand that the design is not robust. We just need this in application level. So individual drafts and verdor specific AVPs is needed by the apps. Glenn : Expect that we don't need any sponsor. Hannes : Host level based solution did not find tracktion in IETF. So we just wrestle with realm based redirect. Tom : Basically, we are guardians of protocols that are totally reliable and don't want anything to retract from that.