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
