Charlie,
CC to i...@ietf.org dropped for now, we don't need to bore
everybody. I have Bcc'ed Benoit since I mention him below.
Thanks for the careful review, it's just what we needed.
For now, just a few top level comments below:
On 14/02/2017 09:36, Charles Perkins wrote:
> Reviewer: Charles Perkins
> Review result: On the Right Track
>
> I think the document has some noteworthy issues. A lot of text is
> imprecise, which will surely lead to many misinterpretations. In some
> places, ACP seems to be mandated, and in other places that is relaxed
> to mean "a sufficient security mechanism". It would be better to
> identify the security requirements, and put them unmistakably in the
> Security Considerations section, which deserves to have teeth.
We'll look into that. The intention is to say the protocol MUST run
in a secure environment and that this SHOULD be the ACP. But we don't
intend to exclude usage without the ACP, and we must also allow
insecure instances during bootstrap. Also, my understanding is that
security is supposed to be placed wherever it fits in a specification,
with the Security Considerations being more of a summary. Anyway,
I expect we'll get a secdir review too?
> Other language is erroneously broad and therefore misleading and
> subject to
> misinterpretation. Other parts of the document seem more
> philosophical than
> prescriptive, adding to a general air of informality. These are noted
> in the
> annotated document below.
>
> It should be considered to break the document into a Requirements
> document and
> a more rigorously defined protocol solution document.
There's a bit of history. When the WG was formed, the chartering
AD (Benoit) was very insistent that we did not get bogged down
in formal use case & requirements work, and no requirements RFCs
were chartered. So some pre-existing requirements text was
included, as well as some of the philosophical material. If
the community wants us to pull that out (plus the appendix on
alternative solutions), we'll do that, but I can guarantee it
will not be a priority to turn it into a separate RFC.
> I am guessing
> that the
> protocol solution included with this document will require some
> iterations in order to be precise enough to really work, and in the
It really works, because I have running code. Whether a
second implementation would interoperate I don't know yet;
if we are very lucky we might find out at the hackathon.
But isn't that why we call them "proposed" standards?
> meantime the Requirements (separately) need to be a lot sharper.
That is specifically what Benoit asked us not to do.
That's it for now. I will look at the details as time
permits, of course.
Regards
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
