Hi, -Agree with your comment on “mandatory-to-implement”. I think the Introduction should be changed, and I suggest using something like the text used in RFC7321 “Algorithm Implementation Requirements and Usage Guidance”. RFC7321 also has a more explaining title.
- I think 1024-bit MODP should be “SHOULD NOT-” as it seems to be agreement that is should be “MUST NOT” in the next update. Might may sense to define “+” and “-” instead of “SHOULD+, SHOULD-, MUST-” - I think “Curve25519” should be included as “MAY” or “MAY+”, even if nobody has implemented it yet, it seems like the obvious choice long-term. Cheers, John From: IPsec <[email protected]<mailto:[email protected]>> on behalf of Daniel Migault <[email protected]<mailto:[email protected]>> Date: Wednesday 2 December 2015 23:24 To: Tommy Pauly <[email protected]<mailto:[email protected]>> Cc: IPsecME WG <[email protected]<mailto:[email protected]>>, Paul Wouters <[email protected]<mailto:[email protected]>> Subject: Re: [IPsec] RFC 4307bis Hi, Please find the updated version with the new section titles suggested by Yaron: 1.1 Updating Mandatory to Implement Algorithms 1.2 Updating Algorithm Requirement Levels 1.3 Document Audience BR, Daniel https://github.com/mglt/drafts/commit/ffb6e9ad82bc952f3a891de232cd10be353878a9 On Wed, Dec 2, 2015 at 4:01 PM, Daniel Migault <[email protected]<mailto:[email protected]>> wrote: Hi, Please se the current version of the document with the subsection in the Introduction. https://github.com/mglt/drafts/commit/ef72ea482af74d4226d3059237024f63d0add01b The subsections are: 1.1 Updating Mandatory to Implement Algorythms 1.2 Algorithm Status Update Policy 1.3 Audience of the Document Feel free to provide any comment. I beleive we have addressed all comments we received. I am finding the terminology mandatory-to-implement maybe a bit misleading for status like MAY or a MUST NOT. Any suggestion to clarify that? BR, Daniel On Mon, Nov 30, 2015 at 12:22 PM, Daniel Migault <[email protected]<mailto:[email protected]>> wrote: Hi Tommy, Thanks for the proposition Tommy, I thnik that will clearer to have dedicated subsections in the intro. Here are the subsection I would propose. I am waiting for the WG feed back before updating the draft, so please let m eknow whether: A) You like the idea of subsection in the intro B) You DO NOT like the idea of subsections C) If you like the following: c1) The need for mandatory-to-implement algorithms c2) The scope of the document (IKEv2 + implementer) c3) Updating algorithm status (deprecation of algorithms and the IoT section) D) If you have other propositions. I will update the draft this week according to the responses. BR, Daniel On Mon, Nov 30, 2015 at 12:20 PM, Tommy Pauly <[email protected]<mailto:[email protected]>> wrote: Hi Daniel, Thanks for making these changes! I think this makes the document much clearer. With regards to the Introduction, it may be beneficial at this point to have subsections of the introduction to make it easier to parse. Right now there seem to be several topics that don’t necessarily flow into one another: explaining mandatory-to-implement algorithms, explaining which version of IKE is relevant, explaining deprecation of algorithms, and the IoT section. Thanks, tommy On Nov 26, 2015, at 2:58 PM, Daniel Migault <[email protected]<mailto:[email protected]>> wrote: Hi Paul and Tommy, Please find the new update of the draft: 1) text in the introduction has been added to specify the IoT use case, and the motivations for having IoT considerations in this document. 2) IoT has been indicated in the tables with a comment specifying that the requirement is for IoT interoperability. I was not able to have two lines in the postamble. It seems <artwork> is not accepted as a children for <postamble> 3) RFCs have been added in the reference section to enable xml2rfc to run properly. The update is available here: https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652 Feel free to comment update the text. BR, Daniel On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters <[email protected]<mailto:[email protected]>> wrote: On Fri, 20 Nov 2015, Tommy Pauly wrote: On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, PRF_AES128_CBC, AUTH_AES-XCBC) are justified as being present for the purposes of Internet of Things devices. I tend to think that it would be more straightforward to have a separate document that explains the preferred algorithms for IoT devices (an IKEv2 profile for IoT, for example). However, if we do want to keep them in this document, I think it would help to have a section in the introduction to the document explaining the use case for the IoT devices and why they are now included in the bis document, whereas they were not relevant yet in RFC 4307. It may also be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; traditional VPN clients would generally not be interacting with IoT devices directly, and thus would have little reason to implement these algorithms. I would suggest if we want to do that, to just use a [*] notation where the [*] gets explained as "For interoperability with IoT clients only" I would not want to leave it out because that will cause us to get servers that won't support IoT devices. Paul _______________________________________________ IPsec mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
