{This is the first of many replies to the various reviews}
Jari Arkko <jari.ar...@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.
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 [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
