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

"Wijnen, Bert (Bert)" <[email protected]> Tue, 24 Jan 2006 00:16:49 +0100
Newsgroups gmane.ietf.aaa
Message-ID <7D5D48D2CAA3D84C813F5B154F43B1550922C4A3@nl0006exch001u.nl.lucent.com>
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:

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

- 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