Re: [Dime] AD-review of draft-ietf-dime-ikev2-psk-diameter-05.txt

Hi, 

Thank you for the revised version. I am sending the document to IETF
Last Call. I am fine with the changes you made to the document. One
issue was introduced by this version - mentioning references is not
recommended in Abstract sections. You may want to take out the [RFC5778]
reference from the Abstract and leave the one in the Introduction. You
can do this after the last call.

Thanks and Regards,

Dan 

> -----Original Message-----
> From: Cakulev, Violeta (Violeta) 
> [mailto:violeta.cakulev@alcatel-lucent.com] 
> Sent: Thursday, May 19, 2011 10:12 PM
> To: Romascanu, Dan (Dan); dime@ietf.org
> Subject: RE: AD-review of draft-ietf-dime-ikev2-psk-diameter-05.txt
> 
> 
> Dan,
> Thanks for the comments please see inline [VC].
> 
> Thanks,
> -Violeta
> 
> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On 
> Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, May 05, 2011 10:50 AM
> To: dime@ietf.org
> Subject: [Dime] AD-review of draft-ietf-dime-ikev2-psk-diameter-05.txt
> 
> 
> 
> Hi,
> 
> Please find below the AD review of
> draft-ietf-dime-ikev2-psk-diameter-05.txt. While the document 
> is in pretty good shape, there are a few key technical and 
> editorial issues that need to be addressed before we can send 
> the document to IETF Last Call.
> 
> See below. Technical requirements are marked Tx and Editorial 
> requirements are marked Ex.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> T1. In the Abstract section I find the following:
> 
> > This document therefore extends
>    the functionality offered by [RFC 5778] with pre-shared key based
>    authentication offered by IKEv2 when no EAP is used.
> 
> Would not this imply that the document should have the note 
> 'Updates RFC
> 5779 - when approved' in the header?
> [VC] This is a good point. This wording indeed implies that 
> the document is actually updating RFC 5778 and that is not 
> the case. We changed the wording in v6.
> 
> T2. In any case it seems to me that RFC 5778 should rather be 
> a Normative Reference rather than an Informative reference.
> [VC] I looked into this carefully a while back. This document 
> is specifying new Diameter application, AVPs etc. in other 
> words nothing from RFC 5778 is being reused. I don't think 
> that RFC 5778 must be read to understand or implement the 
> technology in this document. Nevertheless, for the sake of 
> completeness I think it is worth referencing it.
> 
> 
> 
> E1. [RFC5778] is the correct label for the reference and not 
> [RFC 5778]
> 
> E2. In Section 1 s/IKEv2 protocol allows/The IKEv2 protocol allows/
> 
> E3. Expand HAAA at the first occurrence which is in Section 1
> 
> E4. Section 4.2 - s/IKE_SA correspond/IKE_SA corresponds/
> 
> E5. Section 9 IANA Considerations needs a serious re-write. 
> The first paragraph should not use verbs at past time as we 
> are describing here codes and values defined in this 
> specification. All the other sections need to be explicit 
> about what allocations are required from IANA. For example it 
> would be good to use the format 'IANA is required to allocate 
> the following AVP Codes: IKEv2 Nonces - TBD5, Ni - TBD5, etc.'
> [VC] v6 addresses all of the above.
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> 