Diameter Session Initiation Protocol (SIP) Application
draft-ietf-aaa-diameter-sip-app-12

State Change Notice email list have been change to aboba@internaut.com, bernard_aboba@hotmail.com, david@mitton.com, john.loughney@nokia.com; miguel.an.garcia@nokia.com; maria.carmen.belinchon@ericsson.com; miguel-angel.pallares@ericsson.com; carolina.canales@ericsson.com; kalle.tammi@nokia.com,bwijnen@lucent.com from aboba@internaut.com, bernard_aboba@hotmail.com, david@mitton.com, john.loughney@nokia.com; miguel.an.garcia@nokia.com; maria.carmen.belinchon@ericsson.com; miguel-angel.pallares@ericsson.com; carolina.canales@ericsson.com; kalle.tammi@nokia.com

[Ballot discuss]
There is a discussion on the radext digest authentication draft about
problems with the client generated nonces.  At least one option on the
table the last time I looked at the discussion was to remove the
feature.  We should coordinate between these two drafts and make sure
that they solve the same problem the same way especially since they
can gateway between each other.

[Ballot comment]
The Introduction could use some additional text explaining that the functions described in this document go well beyond authentication and authorization methods, but furthermore deals with user profiles, message routing, and the like.

The use of the term "SIP server" in this document is as a bit ambiguous. There are numerous "server" roles that an entity might play in SIP: UASs, proxies, redirect servers, registrars, etc. It would be nice when the term server is used (especially in the first few sections) if it were explicit whether or not the text was meant to apply to some or all of those roles.

The scope of this document includes functions that overlap with RFC3263 - I would especially note the example given in 6.7 and the whole function of LIR/LIA. The relationship between DIAMETER-based message routing and traditional message routing as described in RFC3263 is a little unclear to me. In particular, I'm unsure how a DIAMETER server maps onto the "location service" abstraction defined in RFC3261. The manner in which a SIP server might be "assigned" to a user seems confusing to me when I read text like (from 8.6):

  This is typically the situation when the user is either
  registered, or unregistered but a SIP server is still assigned to the
  user.

Unregistered but a SIP server is assigned to a user? Are these servers responsible for the domain specified in the host portion of the AoR, as a location service per RFC3261 would be? If not, what is the nature of this assignment? Or conversely, if I used the procedures in RFC3763, is it possible or likely that I would reach some server other than the one that has been "assigned" to the user?

Also, some further text on the intended use of SIP-Server-Capabilities (which in 9.3.1 and 9.3.2 appears to be left in syntax and semantics entirely up to local policy) would probably shed some light on its relationship with traditional SIP message routing. Use of capabilities to identify the next proxy server to which a request might be forwarded sounds like a substantial departure from traditional routing.

IANA Comments:
Upon approval of this document the IANA will register the
following:
1 New Application-ID in the standards-track address space 
12 New Command Codes in the IETF Consensus space
25 New AVP Codes
New Result-Code AVP Value
6  new Result-Code AVP values (success category)
1  new Result-Code AVP value (transient failure category)
9  new Result-Code AVP values (permanent failures category)
New registry for SIP-Server-Assignment-Type AVP values
New registry for SIP-Authentication-Scheme AVP values
New registry for SIP-Reason-Code AVP values
New registry for SIP-User-Authorization-Type AVP Values
New registry for SIP-User-Data-Already-Available AVP values

These registrations will take place in the following registry:
http://www.iana.org/assignments/aaa-parameters

What are the registration rules for the new registries created?

[Ballot comment]
Very disappointed the OAM area does not coordinate to bring the related
radius document at the same time.  That needs management
to get closure - there is excessive perfectionism going on.  The radius
document as well as the diameter document are very strong requirements
in the external community.

[Note]: 'A new rev is expected Feb 9 or 10 to address some AD review comments and a comment from Sam Hartman on MD5 usage.
PROTO SHEPHERD: John Loughney ' added by Bert Wijnen

AD review (as posted to AAA WG mailing list):

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of
Wijnen, Bert (Bert)
Sent: Tuesday, January 24, 2006 00:17
To: Aaa-Wg (E-mail)
Subject: [AAA-WG]: AD review of: draft-ietf-aaa-diameter-sip-app-10.txt


Summary: I think this document is ready for IETF Last Call.

I have some (non fatal) comments below, but as far as I am
concerned we could do IETF Last Call now and consider the
below as initial IETF Last Call comments.

Up to the WG chairs what they want to do, pls let me know asap.

Here are my review comments:

- In figure 1 and 2, you are using a lot of acronyms that only
  get expanded and explained later (sometime much later) in the
  document. Migth be good to either give a list of acronyms
  early in the document, or to expand them in/around figures
  1 and 2.

- Is the use of Session-ID (sect 7,1) and Session-Id (sect 7.2)
  intentionally inconsistent or is it just an accident:

  The Message Format of the UAR command is as follows:

        ::= < Diameter Header: aaa, REQ, PXY >
                < Session-ID >
                < Auth-Application-Id >

  ... snip ..

  The Message Format of the UAA command is as follows:

        ::= < Diameter Header: aaa, PXY >
                < Session-Id >
                { Auth-Application-Id }

- Page 48, table 2.
    Probably it would be better to change the column heading
    "AVP name" into "Attribute name".
  At least my understanding (right now) is that table 2 matches
  the first 4 columns of the tbale on page 54 of RFC3588.
  If that is a correct understanding, it may be better to use
  same column headers as much as possible.

  Same for table 3.

- I wonder if the values in sect 8.4  need to be registered
  and administered by IANA? They are AVP specific values, no?

  You have a few more of such sections for which I have the
  same question of course.

- I wonder if security ADs may have trouble with use of MD5 as
  in section 8.5.6.1. The reason I wonder is that recently MD5
  has had a lot of attention as being problematic and not strong
  enough naymore. I guess it would be wise if you check with one
  (or both) security AD(s) asap. Pls copy me on such communication.

- I note that normative document ietf-radext-digest-auth (rev 06
  is curernt version) has quite a few (serious) IESG DISCUSSes
  and is in New Revision Needed state.
  So you may want to push and help RadiusExt WG to follow
  up on these DISCUSSes.

Bert

PROTO-write-up for the record:

-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Monday, November 28, 2005 13:14
To: bwijnen@lucent.com
Cc: david@mitton.com; aboba@internaut.com; Miguel.An.Garcia@nokia.com
Subject: Submision of the Diametere Session Initiation Protocol (SIP)
Application for AD & IESG review


Bert,

Here is my 5th attempt at the write-up.  I have had 3 HD crashes, which
caused not a little hassle on my side.  Sorry for the delay in getting
this
document to you.

AAA WG has completed last call on Diameter Session Initiation Protocol
(SIP) Application I-D.
The I-D is now ready for AD and IESG review. Below are details about the
I-D:

Title:  Diameter Session Initiation Protocol (SIP) Application
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-10.t
xt

Status: Proposed Standard

Response to template:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes. The ID has had 3 working group last calls.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No concerns.  The document has been reviewed by the AAA working group,
members of the SIPxxx WGs and members from the RADext working group.
Additionally, people participating from 3GPP have also reviewed the
working group.
 
4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

Several comments, considered minor, were received after WGLC.  These
issues
were not show-stoppers.  There was not WG consensus to reopen the
document
to address these small points.
 
5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

There is a strong consensus in the WG supporting this work.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes. An output of the run on this revision of the ID by the online nits
checker:
idnits 1.82

tmp/draft-ietf-aaa-diameter-sip-app-10.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
   
    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.
    No nits found.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0
form
    feeds but 80 pages

  Miscellaneous warnings:
    None.

    No nits found. 

8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

The document does split references into normative and informative ones.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

This draft proposes Diameter application to allow SIP-based services to
be
used within a AAA deployment, for authentication of users and
authorization
of SIP resources usages.  The document defines the overall framework for
this as well as the Diameter AVPs and Command Codes to be used.

  - Working Group Summary

There have been 3 WGLC on the document. Effort was made to align this
with the
RADIUS Extension for Digest Authentication draft.  There seems to be
strong
consensus behind this document, and some WG members have indicated that
they
are implementing the draft.

  - Protocol Quality

This document was reviewed by the working group chairs as well as key
Diameter
and RADIUS experts.  We feel that this document is ready.  Additionally,
this
document has participated in the Early Copy-Edit experiment.

State Change Notice email list have been change to aboba@internaut.com, bernard_aboba@hotmail.com, david@mitton.com, john.loughney@nokia.com; miguel.an.garcia@nokia.com; maria.carmen.belinchon@ericsson.com; miguel-angel.pallares@ericsson.com; carolina.canales@ericsson.com; kalle.tammi@nokia.com from aboba@internaut.com, bernard_aboba@hotmail.com, david@mitton.com, john.loughney@nokia.com