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]> 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]> 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]> >> 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]> 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] >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> >> >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
