[Anima] Alexey Melnikov's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-anima-grasp-12: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a small list of issues that I would like to discuss before
recommending approval of this document:

1) The first reference to UTF-8 needs a Normative reference to RFC
3629.

2) In Section 3.10.1, you say:

   The names of generic objectives MUST NOT include a colon (":") and
   MUST be registered with IANA (Section 7).

In Section 7 you only say:

   GRASP Objective Names Table.  The values in this table are UTF-8
   strings.  Future values MUST be assigned using the Specification
   Required policy defined by [RFC5226].

IANA is not going to review section 3.10.1 and there is no back reference
in Section 7. IANA needs to know that values with ":" are not to be
registered.


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

As a general comment, the document has several SHOULD/MUST level
requirements which are sometimes addressed at people deploying the
protocol, sometimes at UI designers and sometimes at designers of new
objectives. I generally don't mind, but the document doesn't always make
it clear what is the intended audience for different requirements.

Other smaller things:

"Fully Qualified Domain Name" probably needs a Normative Reference.


3.5.4.3.  Discovery Procedures

In 6th para:

   The cache mechanism MUST include a lifetime for each entry.  The
   lifetime is derived from a time-to-live (ttl) parameter in each
   Discovery Response message.  Cached entries MUST be ignored or
   deleted after their lifetime expires.  In some environments,
   unplanned address renumbering might occur.  In such cases, the
   lifetime SHOULD be short compared to the typical address lifetime
and
   a mechanism to flush the discovery cache MUST be implemented.

How can the discovery cache be flushed?


3.9.5.4.  Locator URI option

   In fragmentary CDDL, the URI option follows the pattern:

     uri-locator = [O_URI_LOCATOR, text]

I suggest inclusion of optional transport protocol here to match other
locators and to follow best practices for not encoding transport
information in URIs.