I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-sun-dime-itu-t-rw-01.txt
Reviewer: Brian Carpenter
Review Date: 2008-07-29
IETF LC End Date: 2008-08-18
IESG Telechat date: (if known)

Summary: Technically OK; IANA concerns

Comments: 

I don't have any purely technical issues with this draft, but I have
some IANA concerns. The draft states that:
 
"The main information is conveyed by the Rw interface:

   o  Resources reservation and/or allocation request for media flows;
   o  QoS handling request such as packet marking and policing to use;
   o  Gate control (opening/closing) request for a media flow;
   o  NAPT and NAT traversal requesting the necessary address mapping
      information;
   o  Resource usage information request and report for media flows"

The IANA Considerations of RFC3588 says:

  "Diameter is not intended as a general purpose protocol, and
   allocations SHOULD NOT be made for purposes unrelated to
   authentication, authorization or accounting."

I would like to ask whether there has been discussion of the apparent
conflict between these two statements. It doesn't seem that the Rw interface
is primarily a AAA interface; the resource reservation, QOS policy and NAT 
traversal signaling in particular do not seem to be AAA functions.

I think the draft should at least explain why it is OK to ignore
the SHOULD NOT in RFC3588.

I am rather surprised that it is proposed to assign a "vendor-specific"
application identifier when the primary usage is not specific to a vendor;
an ITU-T Recommendation is not a vendor. RFC3588 says
"Vendor-Specific Application Identifiers, are for Private Use." This is
not for private use. Why isn't this a standards track application identifier?