On 2018-11-30 11:36, Michael Richardson wrote:
>
> {This is the first of many replies to the various reviews}
>
> Jari Arkko <[email protected]> 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 [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> [
>
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> Gen-art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
