Subject: Re: [Dime] AD Review of draft-sun-dime-itu-t-rw-00.txt

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Mon, 14 Jul 2008 10:44:56 -0500

Dan,

See my comments inline.
I will upload the revised version before the end of today.

Rgs,
Dong 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 10:41 AM
To: Sun, Dong (Dong)
Cc: Hannes Tschofenig; [email-masked]
Subject: AD Review of draft-sun-dime-itu-t-rw-00.txt

Here is the Area Director Review of draft-sun-dime-itu-t-rw-00.txt. I
have divided the commented in Technical and Editorial. A Revised-ID is
needed before sending the document to IETF Last Call. 

T1. RFC 2434 was obsoleted by RFC 5226
>> done.

T2.Section 4.1 - I do not believe that the document should ask IANA for
the allocation of 'the next value' (probably the next available value),
but rather just for the allocation of a value in the specified range. 
>>done. "the next value" is removed.

T3. Section 4.3 needs to be re-written.- The nine values of the AVP
codes should be TBD and assignment be required from IANA at the
recommended values. The values in Table 1/Q.3303.3 in Section 7.3.1 of
[Q.3303.3] can be recommended but the final assignment should be made by
IANA after the document is approved (rationale - another ITU-T SG may
have already asked for the assignment of the same values)
>> The range of these AVP codes has been assigned to ITU for its
specific use and the IETF is not responsible for nailing down the
concrete AVPs within this range on behalf of ITU. In the ITU, there is a
single authority being responsible for assigning the AVP codes for all
pertinent applications. So there will not have overlapping problem.

E1. I suggest that the title of the document should be consistent with
the title of RFC5224 so instead of  'Diameter Policy Enforcement
Interface: ITU-T Rw' rather  'Diameter ITU-T Rw Policy Enforcement
Interface Application'
>> done.

E2. In the Introduction Section s/to send a request and receiving a
response/to send a request and receive a response/ 
>> done.

E3. Section 2

   Additionally, the terms and
   acronyms defined in Section 4 of [Q.3303.3] are used in this
   document.

Actually in [Q.3303.3] Section 3 defines terms and section 4 acronyms. 
>> done

E4. I find section 3 pointless as it stands now. A one-two executive
summary paragraph placing the interface described in the document in the
context of Q.3303.1 and ITU-T Y.2111 and mentioning that the scope of
the interface is to control policy enforcement functions in the
transport devices, including QoS resource control, NAPT/NAT traversal
control, etc. would be appropriate. 
>> done.

E5. Section 4.1 - the reference is incorrect s/Section 3/[Q.3303.3]
Section 7.2.1
>> done.

E6. Section 7.4.2 - the references are incomplete - add to each that
they refer to [Q.3303.3]
>> done.

Regards,

Dan

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