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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 May 2011 16:49:30 +0200

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? 

T2. In any case it seems to me that RFC 5778 should rather be a
Normative Reference rather than an Informative reference. 

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

---

From: "Cakulev, Violeta (Violeta)" <[email-masked]>
Date: Thu, 19 May 2011 14:12:11 -0500

Dan,
Thanks for the comments please see inline [VC].

Thanks,
-Violeta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 05, 2011 10:50 AM
To: [email-masked]
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

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.

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
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 20 May 2011 11:45:55 +0200

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 

> From: Cakulev, Violeta (Violeta) 
> [mailto:[email-masked]] 
> Sent: Thursday, May 19, 2011 10:12 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: AD-review of draft-ietf-dime-ikev2-psk-diameter-05.txt
> 
> 
> Dan,
> 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.
> 
> [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.
> 
> 
> 
> 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