I've now had a first look through Charlie's detailed comments. Most of them are "OK, we can clarify or fix that." A handful I personally would argue against (but I think even those indicate that some clarification is needed). However, I don't think we want to do that without some AD/WG Chair guidance on the larger questions mentioned below.
Regards Brian On 14/02/2017 12:18, Brian E Carpenter wrote: > Charlie, > > CC to [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/anima
