Francesca Palombini has entered the following ballot position for draft-ietf-alto-unified-props-new-21: 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/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/ ---------------------------------------------------------------------- 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. 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). ---------------------------------------------------------------------- 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") 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. 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). 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" 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. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
