Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hello Murray,

The V24 is up now, for your review
Thanks,
Sabine



The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/



There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-24



From: Murray S. Kucherawy <[e-mail]>
Sent: Monday, February 28, 2022 4:09 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Vijay Gurbani <[e-mail]>
Subject: Re: Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)

Thanks, those all sound like improvements to me.  If you let me know when -24 is up, I can review it once more.

On Mon, Feb 28, 2022 at 6:38 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]<mailto:[e-mail]>> wrote:
Hello Murray,
Thank you very much for your review and guidance.
I apologize as I realized I have not integrated all of the related updates in the v23 that has been posted.
To avoid confusion for the other reviewers, please find inline our related proposed updates.
A v24 integrating these updates is ready to be posted.
We refer to V24 for comments that are reflected in the V24 to be posted.
Please let us know whether they meet your expectations.
Thanks,
Sabine and co-authors

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-23

>-----Original Message-----
>From: Murray Kucherawy via Datatracker <[e-mail]<mailto:[e-mail]>>
>Sent: Sunday, December 5, 2021 8:21 AM
>To: The IESG <[e-mail]<mailto:[e-mail]>>
>Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>; Vijay Gurbani <[e-mail]<mailto:[e-mail]>>
>Subject: Murray Kucherawy's No Objection on draft-ietf-alto-unified-props-
>new-21: (with COMMENT)
>
>Murray Kucherawy has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: 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/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I support Francesca's DISCUSS.
>
[ [SR] ] This issue has been solved in version 22 and you may refer to Francesca's feedback

>The shepherd writeup says:
>
>  The chair has received IPR declarations from Richard Yang, Sabine
>Randriamasy,
>  Jensen Zhang, Wendy Roome, and Kai Gao.  During the discussion of this I-D
>  in the working group, no IPR issues has been raised to the best of my
>  knowledge.
>
>Just to be clear, I presume what the chair actually received was affirmations of
>compliance with BCP 78 and 79 from those people, and not declarations of the
>existence of IPR.
>
[ [SR] ] Indeed, the chairs have received in November 2020, from the authors a message saying "To the best of my knowledge, all IPR related to the Unified Properties document has been disclosed.". I am not aware of any existence of IPR related to this draft.  Maybe Med and Qin can confirm.

>The "Interoperability considerations" part of Section 12.1 doesn't seem to be a
>complete answer to the corresponding guidance in Section 6.2 of RFC 6838.
>
[ [SR] ] In V23, the content for this part has been set to "n/a" in sections 12.1 and 12.2. Please note that Section 12.1 of V21 is now split in 2 sections (i) 12.1.  application/alto-propmap+json Media Type and (ii) 12.2.  alto-propmapparams+json Media Type

>I'm bothered by the dangling SHOULD in Section 12.2.2.  If you're going to
>include that, I suggest including some guidance about when it would be
>legitimate to omit that information from a registration and still expect it to go
>through.
>
[ [SR] ] V24 - (now Section 12.3.2 in v23-24) Agreed. Thanks for noticing this. In V24, to be consistent with Section 5.1.1, the SHOULD has been replaced with MUST.

>The second-last paragraph in Section 12.3 appears to be broken.
>
[ [SR] ] in V24, the "It" has been removed, thanks

>For Sections 12.2 and 12.3, I suggest not including a registry entry for "priv:"
>because that's not an identifier, but everything else is.  It's fine to leave in
>prose saying nothing can be registered using "priv:" as a prefix, as those are
>meant to indicate private use.
>
[ [SR] ] the "priv" entry has been removed from Table 2 and Table 3 in v23
>[I-D.gao-alto-fcs] has expired.  What's the plan here?  It's an informative
>reference.
>
[ [SR] ] in V23 the reference has been removed

>I had the same thought as Ben did about the use of "GET-mode" and "POST-
>mode".
>
[ [SR] ] in v23, we updated item 3  of parag 5 as follows
OLD
The former is a GET-mode resource that
      returns the property values for all entities in one or more entity
      domains, and is analogous to a network map or a cost map in
      Section 11.2 of [RFC7285].  The latter is a POST-mode resource
      that returns...
NEW
The former a resource that is requested using the HTTP GET method,
      returns the property values for all entities in one or more entity
      domains, and is analogous to a network map or a cost map in
      Section 11.2 of [RFC7285].  The latter is a resource
      that is requested using the HTTP POST method, returns...

>It's a pity that the referenced documents didn't use ABNF, because it seems
>like Sections 5.1.1 and 5.1.2 would benefit from it.  But ultimately, I agree with
>the decision to be consistent.
>
[ [SR] ] Thanks, indeed awareness of ABNF is important.

>Also in 5.1.1, it seems strange to issue constraints for how private use entity
>domain types are to be specified.  If they're private use, interoperability is the
>concern of those participants only.
>
[ [SR] ] As per other review comments, in v23, section 5.1.1 and 5.1.2 have been updated and hopefully considerations  private use entity domain types have been well separated. For brevity of this message, you may refer to our response to Francesca

>Sections 6.1.1.1 and 6.1.2.1 (and later, 6.2.1) should include more than a
>single word.  I suggest something like:
>
>  The identifier for this Entity Domain Type is "ipv4".
>
[ [SR] ] thanks, in V24 we have accordingly updated sections 6.1.1.1 (ipv4),6.1.2.1 (ipv6), 6.2.1 (pid)

>In Section 6.2.3, "is" should be "are".
>
[ [SR] ] Thanks, in V24, we have corrected

>Do we need Section 7.3?  If we do, please turn it into at least a single
>sentence, like:
>
>  A Property Map has no Accept Input parameters.
>
[ [SR] ] Thanks, in V24, we have updated with your proposed text.
>