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) <sabine.randriam...@nokia-bell-labs.com> 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 <nore...@ietf.org> > >Sent: Sunday, December 5, 2021 8:21 AM > >To: The IESG <i...@ietf.org> > >Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org; > >alto@ietf.org; Vijay Gurbani <vijay.gurb...@gmail.com> > >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. > > > >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
