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. > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
