Subject: [Anima] Mirja Kühlewind's No Objection on draft-ietf-anima-grasp-14: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 07 Jul 2017 04:30:41 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-anima-grasp-14: 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:
----------------------------------------------------------------------

Thanks for addressing my discuss in the upcoming version -15!

-----
Old comments for the record (I didn't check these):

Other mostly editorial comments:
- ASA needs to be spelled out in the intro.
- I would recommend to move section 2 and 3.3 into the appendix
- section 3.5.4.2: "A neighbor with multiple interfaces will respond with a
cached discovery response if any."
   "cached response" is explained in the next section and not clear in this
   paragraph.
- section 3.5.4.3: "After a GRASP device successfully discovers a locator for a
Discovery
   Responder supporting a specific objective, it MUST cache this
   information, including the interface index via which it was
   discovered.  This cache record MAY be used for future negotiation or
   synchronization, and the locator SHOULD be passed on when appropriate
   as a Divert option to another Discovery Initiator."
   Not sure why the first is a MUST and the later is a SHOULD. I guess a SHOULD
   for caching would be sufficient.
- section 3.8.6 "If a node receives a Request message for an objective for
which no
   ASA is currently listening, it MUST immediately close the relevant
   socket to indicate this to the initiator."
   How is that indicated? Should really be further clarified
- Also section 3.8.6: "In case of a clash, it MUST discard the Request message,
in
   which case the initiator will detect a timeout."
   Why don't you send an error message instead? How does the initiator know
   that is should retry (assuming there is a TCP connection underneath that
   provides reliable transport)?
- Also section 3.8.9: "If not, the initiator MUST abandon or restart the
negotiation
   procedure, to avoid an indefinite wait."
  How does the initiator decide for abandoning or restarting instead? Needs
  clarification!
- Could be useful to include an optional reasoning field in the Invalid Message
and make copying the received message up to the maximum message size of this
message a SHOULD (section 3.8.12.). - Not sure I fully understand the purpose
of the No Operation Message (section 3.8.13.). If you just want to open a
socket for probing, you perform a TCP handshake and send a RST right after. No
need for further application layer interactions. And should there also be an
optional reasoning phrase? - Not sure why the objectives flag is needed. I
assume that unknown objectives are ignored anyway and if a objective is known
the receiver should know if that objective is valid for the respective message
type (section 3.10.2). - section 3.10.4: "An issue requiring particular
attention is that GRASP itself is a stateless protocol."
   It's not. It caches information and needs to remember previous messages sent
   to reply correctly.
- section 5: "Generally speaking, no personal information is expected to be
      involved in the signaling protocol, so there should be no direct impact
      on personal privacy."
   I don't think this is true because the protocol is so generic that you
   cannot say anything about the services it is used for.
Please see also further comments from Martin's tsv-art review (Thanks again!)!