Warren Kumari has entered the following ballot position for
draft-ietf-anima-grasp-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Firstly, thank you for addressing Joel's OpsDir review.
As others have noted, this is a long document :-) I think that, in spite
of this, it is very well written.... 

These comments were written against v-11, but I think are still
applicable to -12.


Section 2.1, D1:
"... the protocol can represent and discover any kind of
   technical objective ..." While the document *does* say that readers
should be familiar with RFC7575, RFC7576, and
I-D.ietf-anima-reference-model, I think it would still be helpful to
(briefly) describe an objective here, or simply mention that "technical
objective" is a term of art and point to the Terminology section (or Sec.
3.10). When I initially read this it sounded incredibly broad, once I
found the Terminology section it all made more sense...


S2.2.  Requirements for Synchronization and Negotiation Capability

   "SN5. 
   ...
   It follows that the protocol’s resource requirements must be
appropriate for any device that would otherwise need human intervention."


I found this sentence confusing / hard to parse. I *think* that you are
saying that the protocol should not require so many resources that it
cannot be deployed on devices (and so humans would still need to manually
manage them)?
If so, I think that this could be clearer, but, unfortunately I cannot
provide better text...

3.2.  High Level Deployment Model
"A more common model is expected to be a multi-purpose device capable of
containing several ASAs."
I'm sure you are right... but for a reader new to the topic this is not
obvious (nor clear) - would it be possible to provide some sort of
examples of such devices (or brief description of why a more common model
would have several ASAs?) E.g: "multi-purpose device capable of
containing several ASAs (such as a router or large switch)" (or
whatever...)


"..it is essential that every implementation is as robust as possible."
 --  this sounds suspiciously like "Don't write bad code...".  What is
the purpose if this statement? Do you think that it will somehow make
people write better / more robust code? If so, shouldn't this be in our
standard boilerplate? This whole paragraph feels like it is not
actionable / is something that all code for all implementations of
everything should follow... (I have a horrible feeling that I'm heading
off on a soapbox rant / that this is a pet-peeve...)


_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to