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

[Brian E Carpenter <[e-mail]>]

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,

>      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.

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



On 23/05/2017 04:08, Alexey Melnikov wrote:
> 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.
> 
> 
>