Subject: [secdir] dealing with many the secdir and genart comments

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Nov 2018 22:36:14 -0000

{This is the first of many replies to the various reviews}

Jari Arkko <[email-masked]> 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.

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?

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.

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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Nov 2018 13:57:26 +1300

> document should leave the oceans alone, and deal only with the

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.
 
> or perhaps some other section that would clarify the applicability of this

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

> 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

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>