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]> 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]> 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
