Hi Sabine, Thanks for addressing my review. I have cleared my DISCUSS (and kept the one COMMENT while waiting for the update), I believe the IANA section looks good now, and thanks for the clarifications, they did help me.
Francesca From: iesg <iesg-boun...@ietf.org> on behalf of Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <sabine.randriam...@nokia-bell-labs.com> Date: Tuesday, 25 January 2022 at 14:50 To: Francesca Palombini <francesca.palomb...@ericsson.com>, The IESG <i...@ietf.org> Cc: alto-cha...@ietf.org <alto-cha...@ietf.org>, draft-ietf-alto-unified-props-...@ietf.org <draft-ietf-alto-unified-props-...@ietf.org>, alto@ietf.org <alto@ietf.org>, Vijay Gurbani <vijay.gurb...@gmail.com> Subject: RE: Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT) Dear Francesca and Alexeï, We have posted a revision that addresses the DISCUSS points raised in Francesca's review. In particular, regarding the IANA registration, we would like to have the feedback of Alexeï. It is available here. We also addressed the COMMENTS of Francesca's review, except the one on the "priv:" prefix for entity domain types and property types. This COMMETN will be addressed in the next revision, where we plan to add a seperate section for private use entity domain types and property types. Please see inline for our proposed updates. We look forward to having your feedback, best regards, Sabine >-----Original Message----- >From: Francesca Palombini via Datatracker <nore...@ietf.org> >Sent: Wednesday, December 1, 2021 7:36 PM >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>; >vijay.gurb...@gmail.com >Subject: Francesca Palombini's Discuss on draft-ietf-alto-unified-props-new- >21: (with DISCUSS and COMMENT) > >Francesca Palombini has entered the following ballot position for >draft-ietf-alto-unified-props-new-21: Discuss > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Thank you for the work on this document. > >Many thanks to Spencer Dawkins for his thoughtful review: >https://mailarchive.ietf.org/arch/msg/art/BcZimefF1WXXgcmg0qjc3P__EGg/ , >and thanks to the authors for addressing it. > >I have two blocking comments, and some non blocking comments (to which I >would still appreciate answers) below. > >Francesca > >1. ----- > >Media type registration > >FP: I haven't seen the media type being reviewed by the media-type mailing >list, as requested by RFC 6838. Before progressing the document, I would >really appreciate the authors to post the registrations to the media-type >mailing list for review. > [ [SR] ] We have updated the IANA sections 12.1 and 12.2 accordingly, under the guidance that Alexeï provided for CDNI and this draft. >2. ----- > >Sections 4.6.1, 12.2.2 and 12.3 > >FP: The use of the term "unique" when referred to media types and entity >domains (or properties) is confusing - it makes it sound as if the authors mean >that each different entity domain (or property) is to be associated with a >different unique media type, which doesn't seem to be the intent. As this is >related to the media type registration, I believe this should be clarified and >possibly checked with the media type experts (so it would be good to copy >paste the relevant text in the email to the media-type mailing list). > [ [SR] ] the text has been hopefully clarified as follows: --- section 4.6.1: parag 3, item 5. OLD its media type is unique and equal to the one that is specified for the defining information resource of an entity domain type NEW its media type is equal to the one that is specified for the defining information resource of the entity domain type of D NEW --- section 12.3 .2 (was 12.2.2 in version 21), parag 3, item 5 OLD ... The authorized media type of a defining information resources MUST be unique and MUST be specified in the document defining the entity domain type. When an entity domain type allows combinations with defining resources, this MUST be indicated here, together with the authorized media type for the defining resources .... NEW ... For each entity domain type, the potential defining information resources have one common media type. This unique common media type is specific to the entity domain type and MUST be specified. ... --- Section 12.4, parag 6, item 3 OLD ... The media type of the possibly used defining information resource MUST be unique and MUST be specified here, as well as in the document that defines the property type ... NEW ... For each property type, the potential defining information resources have one common media type. This unique common media type is specific to the property type and MUST be specified. ... > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >3. ----- > > identifier. In this case, inheritance rules must specify how > entities in "subsets" inherit property values from their "superset". > For instance, if a property P is defined only for the entity set > identified by address block "ipv4:192.0.1.0/24", the entity set > identified by "ipv4:192.0.1.0/30" and thus included in the former > set, may inherit the property P value from set "ipv4:192.0.1.0/24". > >FP: Are the sets inverted in the paragraph above? (should it be >"ipv4:192.0.1.0/24" inherits from "ipv4:192.0.1.0/30") > [ [SR] ] They are not. Is the wording below clearer? OLD For instance, if a property P is defined only for the entity set identified by address block "ipv4:192.0.1.0/24", the entity set identified by "ipv4:192.0.1.0/30" and thus included in the former set, may inherit the property P value from set "ipv4:192.0.1.0/24". NEW For instance, suppose a property P is defined only for the entity set defined by address block "ipv4:192.0.1.0/24". We know that entity set "ipv4:192.0.1.0/30" is included in "ipv4:192.0.1.0/24". Therefore, the entities of "ipv4:192.0.1.0/30"may inherit the value of property P from set "ipv4:192.0.1.0/24". >4. ----- > >Sections 5.1.1, 5.2.1 > >FP: As it is defined now, all Private Use type identifiers are not valid, >because >they contain ":". I understand the intention, but it would be good to clarify >in >the text. > [ [SR] ] this will be addressed in the next revision, where we plan to add a seperate section for private use entity domain types and property types. >5. ----- > >Section 5.1.2 > >FP: Please add a note specifying the syntax used and a reference to it (it's >enough to just mention it the first time it appears, so in this section). > [ [SR] ] we updated in parag 3 as follows and added a reference for RFC 5511: OLD Each entity domain is identified by a unique entity domain name which is a string of the following format: NEW Each entity domain is identified by a unique entity domain name. Borrowing the symbol "::=" from the Backus-Naur Form notation [RFC 5511], the format of an entity domain name is defined as follows: with RFC5511 added to section 4.2. Informative References "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", Adrian Farrel, Old Dog Consulting, April 2009 >6. ----- > > they have the same value of the "ASN" property. The same rule > applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". > >FP: I believe the second one should be "ipv4:192.0.3.16/28" > [ [SR] ] ===> Indeed, thanks, this has been corrected and the content-length updated >7. ----- > > "properties" : [ "default-network-map.pid", > "alt-network-map.pid ] > >FP: I validated the JSON examples (which I recommend to do) and this one is >the only one that didn't validate as this is missing a closing " after "alt- >network-map.pid. > [ [SR] ] Thanks, this has been corrected. >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
