[Dime] Notes for DIME Virtual Meeting, Feb 19, 2008

["Hannes Tschofenig" <[e-mail]>]

Hi all, 

We had a good discussion during our virtual interim meeting and we went
through our documents and discussed a few issues. I believe it was worth to
organize it. 

Thanks to those who contributed!

Ciao
Hannes

----------

* Participants

 - Victor Fajardo
 - Martin Dolly
 - Sebastien Decugis
 - Janet Gunn
 - Mark Jones
 - Behcet Sarikaya
 - Jouni Korhonen
 - Hannes Tschofenig
 - Viqar Shaikh
 - Glen Zorn
 - Tom Taylor

Meeting minutes by Victor

* Slides

  http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge

* WG Status

  Hannes goes through the slides. 

  - RFC 5447 published
  - API Draft still waiting for update


* Diameter API
 
  Presentation was skipped. Dave was not on the call. He will report to the
list 
  about the document. 

* 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.
  Viqar   : 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 lists 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.
  Viqar   : ALRP has references to session layer but some confusion in other
references.
  Hannes  : 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  : We need to figure out the way forward.
  Hannes  : Pls post a mail on the list summarizing this issue.
  Martin  : Will do today. 

* Base Protocol
  
  Glen    : 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 ago. There is no 
            technical issue that has changed since then and we told folks to

            write that document because we wanted to have it separate. 
            We should stick with our initial decision and progress the
document
            as planned. 

  Victor  : Rev up the version number because of backward compatibility
issue
  Glen    : Agree
  Hannes  : Victor, make an announcement on list of the rev increase. 
            Label it "Diameter Version 2" -- this will wake up folks. 

  Glen    : Change bis heading to clearly include rev number

  --> Diameter NAI presentation was skipped because of the discussion in the
context 
      of RFC 3588bis.

* QoS attributes

  Mark goes through the slides. Status - the next draft update 
  is ready to go to IESG. Draft will be submitted next week. 

  No comments
  
* Diameter ERP

  Sebastian leads through the presentation. 
  Status - Initial Rev. Many design aspects are not yet clear.

  Hannes  : Impression that you have to define a new app-id.
  Glen    : There's a mis-understanding of hokey. There is no problem with
            Diameter routing. In hokey, we assume that there is a separate 
            hokey server and it gets contacted by whatever protocol is used
to 
            carry the AAA messages. 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 ?
  Glen    : 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.
  Glen    : 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 and contain an architectural description. 

* Mip6 split

  Jouni goes through the slides and the document is in good shape and
progressed 
  by the IESG. 
  
  Hannes  : Document is with the AD. Will check with Dan on the status.

* PMIP6

  Jouni goes through the slides and explains what the new draft update will
contain. 

  Hannes  : When is the new doc ready ?
  Jouni   : As soon as the draft authors give their OK. Early next week.
  Hannes  : Very good. 

* Routing Status Update

  Tom presents the slides. 

  Glen   : 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.
  Glen   : Expect that we don't need any sponsor. 
  Hannes  : Host level based solution did not find traction 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.
  Glen    : Will work with Tina on a document that can be submitted to the
RFC Editor 
            as an independent submission