Subject: [Dime] DIME Meeting minutes (IETF70)

From: Victor Fajardo <[email-masked]>
Date: Thu, 06 Dec 2007 13:14:01 -0500

Agenda Bashing
--------------

* Very full agenda
* Two parts, WG documents that are to be completed and new work

RFC3588Bis Work
---------------

* All open issues are now closed
* Version 09 is in LC
* Version 10 will contain latest comments from reviewers
* No open issues. WGLC under way. Need more reviews. A few recent issues 
resolved.

Hannes  : Asked for reviewers - Jouni, Mark, Lionel

MIPv6: NAS-HAAA support
-----------------------

* Changes from 0x -> 05: Big rewrite to support RFC4285bis
* Changes from 05 -> 06: Fixes surrounding 4825bis again
* RO support
* Open issues
   - split the ID into two
   - Replay protection
* WGLC

Hannes  : We not going to split, we pass one LC and people are happy 
with the doc
Gerardo : Disagree, 4285 solution is all informational in the bis
Hannes  : This is not a problem. In proto writeup its a downward reference.
Gerardo : Don't see a reason why standard track document refers to 
informational docs.
Hannes  : Some sections are informational or downward reference.
Dan     : Could have non-normative reference.

MIPv6: HA-AAA support
---------------------

* Changes from 05 -> 06: Fine tuning
* Changes from 06 -> 07:
    - Home-link-prefix AVP
    - Correcting flags again to make it application independent
    - Provide clear examples how to use MPv6 feature
* Submit to IESG ?

Hannes  : WG LC already on this document. Need to issue a short LC for 
one week before IESG

Qos Attributes
--------------

* Changes from 01->02:
    - Add Qos profiles
    - Add flow states and direction
    - Add Qos object types
* Chnages 02 -> 03: Renaming of AVPs etc
* ID extends diameter base
* New AVPs convey Qos as part of the NAS
* Qos maybe pre-provisioned or NAS
* Next steps:
    - Error codes
    - Reviews for WGLC required

Hannes  : Still has WGLC. Document has been sent to other SDOs and had 
good feedback

Qos Parameters
--------------

* Issued WGLC early. Turned out to be good since we found conflicts with
  NSIS and TSVWG.
* Resolution was that tsvwg-emergency-rsp will create IANA register then
  QSPEC and DIME documents will point to the registry

Francious : Resoultion announcement did not make it to the list. Will 
resend.

Diameter App Guidelines
-----------------------

* Updates from reviewers
    - Added M-bit clarification
    - Added min count on optional AVP
    - Added Vendor specific command codes
    - Fixed accounting model that uses different app-ids in header and body
   
Reviewers : Jouni, Lionel, Mark

Proxy MIPv6
-----------

* NETLM WG is finalizing the PMIPv6
* ID aims to support: MAG (NAS) to AAA and LMA(HA) to AAA
* Proposed solutions: extends MPv6 boostrapping which is not specific to 
PMIPv6
* Issues:
    - RADIUS internetworking
    - Accounting on MAG & LMA
    - Session mngt
    - etc
* Adopt as a WG work item ?

Hannes   : New work classified into categories. One would be work related to
           other work being done from other WGs
Gerardo  : Normal procedure is that the related mobility WG give us 
requirement
           for the work before starting something. Is this a procedural 
issue ?
           Do we need some requirement ?
Hannes   : We have several documents to look at for new work. But we do not
           need formal requirements from other WG to start work.
Gerardo  : NETLMM has a lot of issue for bootstrapping MAG and LMA. 
Those things
           belong to the NETLMM WG. Should this work be there as well ?
Bechet   : Similar issues arise for draft with RADIUS for NETLMM. We 
need to support
           this work. Regarding NETLMM requirements, theres no official 
view on this
Glen     : Is it a good thing to throw over to NETLMM since they know 
what they want to do ?
Hannes   : Worth while idea

Dimaeter Qos
------------

* Changes: Split the document into framework and protocol. Still not sure
  if this is good idea or not. It may slow us down.
* Changes:
    - Editorials
    - New terms
    - Handle discovery and selection (for push mode)
    - etc

Francious : This does not cover control of signaling proxy behavior, do 
we all
            agree that this will taken care of in the next rev ?
Hannes    : More details are needed in the doc. Are there any IPR 
related issue ?
Francious : Not sure. Not aware of one.
Hannes    : Most documetns are making good progress in the group except 
maybe this
            document.

** Rechartering Discussion

Hannes    : What are the priority for MIPv4 dime application ? Can we 
hum for interest in this work ?
  ** Hum: not strong but seems no objection
Gerardo   : What is the scope of this work ? Which are we talking about 
? MAG profiles or bootstrapping
            of security ?
Hannes    : Who has read MIPv6 application ? We can take the discussion 
to the list

Auditing
--------

* History: 2 drafts on the subject, requirements and state-recovery 
(expired). The second
  considers possible design approachs
* Why include this work ?
    - Evidence of functionlity and the need for both soft and hard state 
storage
* Drafts go into requirements in details
* Next steps ?
    - Add to the charter and merge both drafts
    - Decide use of resource management

Hannes    : We have ask the group in the past if work in this area is need ?
            There was good response plus liason from TISPAN for this work
Glen      : There are bunch of requirments in that document but not sure 
what
            the problem they're trying to solve or why theres a need for box
            communication
Speaker   : In the use cases section, there's are explanations for 
reasons and what
            the document is trying to solve
Glen      : There where use cases but did not lay out the problem they are
            trying to solve
Speaker   : The second doc talks at lenght on why a protocol method is 
needed.
Hannes    : This can be an action item to sort this out in the list.

Diameter MIPv4 application
--------------------------

* This is an alternative approach to DIME MIPv4
    - we highligthed performance issue with respect to radius
* RFC4004 provies AAA and MSA allocation but does not rely on
  access auth for MIPv4 MSA allocation
* MIPv4 RRQ/RRP are coupled with RFC4004
* 3GPP2 and WIMAX use EAP for access auth
* HA in 3GPP2 and WiMAX need to fetch MN-HA secret key
* Recommendations
    - New model for diameter MIPv4 must support new messages between
    HA and HAAA for MIPv4 authorization and MH-HA, FA-HA, MSA
* Can approve a need for diameter MIPv4

Glen     : 3GPP2 and WiMAX has taken standard IETF protocol and misuse it
           and now want us to change the standard to support them ?
Ahmad    : Old MIPv4 does not use access authentication. They still need
           diameter at the HA.
Hannes   : There are many details so lets take it to the list, Pete's
           going to talk about MIPv4 that has a different deployment model

RFC4004bis
----------

* Changes: No major overhaul, just fixes a few bugs
* Left out the AAA-SPI needed for 3957, MN-FA SPI is created by the FA
  but not being transfered in the AMR
* MN-HA SPI is not needed in the MN-HA MSA AVP
* Changed text in section 9.5

Hannes   : Its not a competing type with the alternative dime MIPv4 apps.
           The document change is a small effort. Some of these issue came
           up with dime MIPv6 work as well.
Alper    : Is this going to be done in DIME. In WiMAX, we only discuss 
concept.
           We would like to separate signaling from diameter. We would 
like to
           bring this to idea to IETF.
Hannes   : We generally do not care where the idea came from. We will 
still review it.

Diameter Classifier
-------------------

* Document defines a grouped AVP which can be used to express and IP or L2
  packet classifier
* Benefits: more extensible than ASCII and decouples condition from action
  and in the filter rule
* Propose this as a dime WG work item. Its straight-forward work and 
well-defined

Hannes   : Presented in last IETF. Came in the context of the RADEXT
Hannes   : Who has read the document ... only a few

Prefix Delegation
-----------------

* The LMA prefix managment in proxy MIPv6
* NEMO requires prefix manamagement
* Diameter-PD vs DHCP-PD, both solutions are complementary with each other
* operators can choose a solution
* It is a natural extension to IP address manaanment
* Proposals: put it into DIME re-charting

Hannes   : We can discuss this issue in the mobility working group, mext 
group

Support for ERP
---------------

* Support for ERP (EAP re-authentication)
* Message needs to be carried over RADIUS/Diameter
* Carry new EAP codes in diameter messages. Nas needs to copy the content of
  rikname-nai tlv, rmsk is sent via eap-master-sesison-key
* dsrk request and delivery

Hannes   : Work in some other WG, some interaction with backend.
           Use next weeks to discuss different proposals.
           Who wants them and for whatever reasons. Claim the need for that
           work is justified.
Speaker  : Some discussion in the HOAKEY WG
Dan      : Criteria - Need to prove operational need for the doc. pool of
           reviewers for this doc.

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime