Re: [Gen-art] dealing with many the secdir and genart comments [on draft-ietf-anima-bootstrapping-keyinfra]

On 2018-11-30 11:36, Michael Richardson wrote:
> 
> {This is the first of many replies to the various reviews}
> 
> Jari Arkko <jari.arkko@piuha.net> wrote:
>> My first bigger comment is that I believe the security and privacy
>> considerations section should have provided an actual in-depth
>> analysis of the characteristics offered by the protocol, perhaps under
>> several different situations, as the protocol can be operated in
>> different modes.
> 
> The authors seriously believe that this will result in an attempt to boil the
> ocean.  Yes, BRSKI is exciting for many and opens many doors, but in
> the context of the *ANIMA* Charter, we strongly think that this
> document should leave the oceans alone, and deal only with the
> ANIMA ACP usage.

Yes, violent agreement. From all the interest outside ANIMA, the basic
idea of BRSKI is a big hit and will be re-used in other contexts. I think
a strong statement about the specific scope of *this* document belongs
in the Abstract and Introduction, with a comment that variant usages
of BRSKI in other scenarios will be documented separately.

> Other users of BRSKI *SHOULD* write a new profile.
> Would it be acceptable for us to provide a section that might be
> entitled:
>         "The ACP mode of operation of BRSKI"
> 
> or perhaps some other section that would clarify the applicability of this
> document?

That too, but make sure that the reader gets the point in the first
few seconds of reading.

> 
> We would list the assumptions and maybe even reduce the options for use
> in the ACP?
> 
> The authors do not object to writing more documents about more situations
> where BRSKI might be used, but we think that putting it all into one
> document is a way for continuing scope creep.
> 
> In accepting the constrained work into the ANIMA WG, the chairs and area
> director have already been very generous.
> 
>> My second comment is that the protocol as defined is quite focused on
>> manufacturer-controlled situations. As Christian mentioned, there is
>> some discussion of other situations in the document (Section 6.4), but
>> not much, and there's little information on what happens if one tries
>> to use the protocol in this way.
> 
> The above comments would seem to apply to this as well.

Correct. The last call discussion has convinced me for one that we need
to tackle the issue of non-MASA scenarios, and I have some ideas about
it, but *the scope of this document* is MASA-based scenarios for
professionally managed networks. Let's make that clear (see above)
but not dilute the present text with it.

   Brian

> 
> As I previously indicated when you first wrote this, we have turned your
> comments into a series of issues on github, and we will be closing those
> issues as quickly as we can.
> 
> Some will come with proposed text changes, but a number will need discussion,
> and we will start new subject lines in this thread for them.   I don't want
> to innudate you, so I've set the Reply-To.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 