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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 22 May 2017 09:08:42 -0700

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 May 2017 08:50:09 +1200

Hi Alexy,

All your DISCUSS comments are valid and easy to fix. Unfortunately I'm
on personal travel this week so can't update until next week.

Assuming we need a new version, we will of course also review your and
other's COMMENT comments.

Specifically,

> locators and to follow best practices for not encoding transport

I have no objection to that but since it's a (minor) protocol change we
would definitely need to run it by the WG.

Thanks
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 May 2017 13:57:48 +1200

Alexey,

We'll look at that, but specific pointers would help.

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

FQDN is in the RFC Editor's list of acceptable abbreviations. But
I don't believe it has a normative reference - it isn't defined
in the DNS spec, anyway. I've had this problem before, way back
in RFC1900!

>    lifetime SHOULD be short compared to the typical address lifetime and

I think that's completely implementation-dependent, so what can we say?
(In the prototype, it's an API call.)

> locators and to follow best practices for not encoding transport

I have asked the WG about this in a separate mail.

    Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 May 2017 21:24:44 +0100

Hi Brian,

> (In the prototype, it's an API call.)

I think you just demonstrated my point that some requirements are not very clear whom they apply to. Passive voice is causing ambiguity here.

I think I would like to see more text on what different possible alternatives are and which entities need to implement the MUST.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 May 2017 21:25:38 +0100

Hi Brian,

> in the DNS spec, anyway. I've had this problem before, way back

Thank you. I am Ok with no change.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 May 2017 08:31:38 +1200

> I think I would like to see more text on what different possible alternatives are and which entities need to implement the MUST.

In this case, I'm more inclined to simply delete the reference to flushing, because it's really part of a much more general problem: https://tools.ietf.org/html/rfc7010#section-7 . The previous comment about the cache lifetime is sufficient.

[In fact, renumbering would be an interesting use case for autonomics, but that's a whole topic in itself.]

    Brian

   Brian