Re: : AD review of: draft-ietf-aaa-diameter-sip-app-10.txt

Hi Bert:

Thanks for your review. I have logged all your issues in the tracker, so 
we can easily monitor them.

http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/

Now, some comments inline.

Wijnen, Bert (Bert) wrote:
> 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.

Agreed, we will add an acronyms section at the beginning of the document.

> 
> - 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:
> 
>        <UAR> ::= < Diameter Header: aaa, REQ, PXY >
>                  < Session-ID >
>                  < Auth-Application-Id >
> 
>   ... snip ..
> 
>    The Message Format of the UAA command is as follows:
> 
>        <UAA> ::= < Diameter Header: aaa, PXY >
>                  < Session-Id >
>                  { Auth-Application-Id }
> 

The first one is a typo, since we are referring to the Session-Id AVP 
defined in RFC 3588.

> - 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.

Agreed.

> 
> - 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.

Yes, these are AVP specific values. So I agree we can create the IANA 
registry. I will add this and other sections to the IANA considerations 
section.

> 
> - 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.

Ok, I will initiate such discussion with the security AD(s). However, I 
must say that, what we are doing is just transporting HTTP Digest 
authentication in Diameter. The problem is that HTTP Digest 
authentication uses MD5 and not SHA-1, so we are constrained on that area.


> 
> - 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.

Ok, I'll take a look at these issues.

Thanks,

        Miguel

> 
> Bert
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email protected]
Nokia Research Center      Helsinki, Finland