Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-ietf-cdni-additional-footprint-types-11> for your review
rfc-editor@rfc-editor.org Wed, 07 June 2023 03:22 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CED3C14CE55; Tue, 6 Jun 2023 20:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.808
X-Spam-Level:
X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.84, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-BSnfRj5QTx; Tue, 6 Jun 2023 20:22:01 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BA4C151097; Tue, 6 Jun 2023 20:21:57 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id D1EA21978E66; Tue, 6 Jun 2023 20:21:57 -0700 (PDT)
To: nir@apache.org, sanjay.mishra@verizon.com
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, cdni-ads@ietf.org, cdni-chairs@ietf.org, kevin.j.ma.ietf@gmail.com, francesca.palombini@ericsson.com, auth48archive@rfc-editor.org
Content-type: text/plain; charset="UTF-8"
Message-Id: <20230607032157.D1EA21978E66@rfcpa.amsl.com>
Date: Tue, 06 Jun 2023 20:21:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/phH4aiyaReEmc7fH-Gc14PfX9qw>
Subject: Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-ietf-cdni-additional-footprint-types-11> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jun 2023 03:22:06 -0000
Authors and *AD, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!--[rfced] *AD - Should RFC 9241 be added to this document's header as being updated by this document? We see the following in the Abstract: "This document also supplements RFC 9241 with relevant ALTO entity domain types." And in the document announcement message (see https://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/writeup/): "The document also updates RFC 9241 with relevant ALTO entity domain types." The current header only indicates RFC 8008 as being updated by this document. Please advise. --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor. org/search. --> 3) <!-- [rfced] For clarity, may we update the sentence as follows ("is defined" / "defines" and "matching" / "that match")? Also, may we update "Herein" to "This document"? Or does "Herein" refer to RFC 8006? Original: Herein is defined the subdivisioncode simple data type, as well as a footprint type allowing the dCDN to define constraints matching geographic areas with better granularity, specifically using the [ISO3166-2] Country Subdivision codes. Perhaps: This document defines the subdivisioncode simple data type as well as a footprint type, allowing the dCDN to define constraints that match geographic areas with better granularity, specifically using the [ISO3166-2] Country Subdivision codes. --> 4) <!-- [rfced] Appendix B of [RFC8008] shows "Semantics for Footprint Advertisement"; we don't see "semantics of Footprint Objects array" in that section. Please review and let us know if any changes are necessary. Original: Appendix B of [RFC8008] specifies the semantics of a Footprint Objects array as a multiple, additive, footprint constraints. Perhaps: Appendix B of [RFC8008] specifies the semantics of a Footprint Advertisement (including a Footprint Objects array) as multiple, additive, footprint constraints. --> 5) <!-- [rfced] FYI, to avoid awkward hyphenation and article issues with singular/plural, we updated this sentence. Please review and let us know any objections. Original: The footprint union also enables composing a countrycode and subdivisioncode based footprint objects. Current: The footprint union also enables the composing of footprint objects based on the countrycode and subdivisioncode. --> 6) <!--[rfced] We had the following questions about text in the Table in Section 4.1. Note that we will communicate any necessary changes to IANA upon completion of AUTH48. a) What does "hyphen-minus" mean? Is this trying to communicate that some people might call it a hyphen and some might say minus sign? Or something else? b) Is this spacing correct? Original: Characters from A-Z;0-9 Perhaps: Characters from A-Z and 0-9 --> 7) <!-- [rfced] For reference [OC-RR], the provided URL points to a page that shows the document being both Version 2.0 and 2.1. Which version is correct? Also, the provided URL shows two more contributors: Thomas Edwards and Yoav Gressel. Would you like these to be added to the reference as authors? Original: [OC-RR] Finkelman, O., Ed., Hofmann, J., Klein, E., Mishra, S., Ma, K., Sahar, D., and B. Zurat, "Open Caching - Request Routing Functional Specification", Version 2.0, 15 January 2021, <https://www.svta.org/product/open-cache-request- routing-functional-specification/>. Perhaps: [OC-RR] Finkelman, O., Ed., Zurat, B., Sahar, D., Klein, E., Hofmann, J., Ma, K.J., Stock, M., Mishra, S., Edwards, T., and Y. Yoav, "Open Caching - Request Routing Functional Specification", Version 2.0, 15 January 2021, <https://www.svta.org/product/open-cache-request-routing- functional-specification/>. --> 8) <!-- [rfced] Terminology: Throughout the document, we spotted the following issues related to terminology. Please review each question below and let us know how to update, using old/new where necessary. Note that you are welcome to update the xml file itself if that is easier than explaining the changes via email. 1) Please review the way that the following terms appear throughout the document with regard to capitalization, hyphenation, quotation, spacing, phrasing, etc. and let us know if/how we may make these terms consistent: a) object vs. Object CDNI Footprint object vs. CNDI Footprint Object Footprint Objects vs. Footprint objects vs. footprint objects (Note that RFC 8006 uses Footprint object) b) Footprint, Footprint Types, Footprint Values, Footprint Union footprint (as a general noun) Footprint Types vs. footprint-type vs. footprint types vs. "footprint-type" -See also "Country Code" footprint type and "IPv4CIDR" and "IPv6CIDR" footprint types. Footprint-value vs. footprint value Union Footprint type "Footprintunion" footprint type "Footprintunion" object Footprint object of type "footprint union" c) Subdivision Subdivision Code Footprint Type a footprint object of type "subdivisioncode" SUBDIVISION Domain (and SUBDIVISION domain) country Subdivision code vs. Country Subdivision codes subdivisioncode vs. subdivision code 2) For the following terms, would you like to match their use in past RFCs, specifically RFC 8006? Please review the various styles that appear in the document currently and our suggested updates to make those forms consistent throughout the document and with RFC 8006. Current: Country Code vs. countrycode vs. country code Perhaps: countrycode Current: ipv4cidr vs. IPv4CIDR Perhaps: ipv4cidr Current: ipv6cidr vs. IPv6CIDR Perhaps: ipv6cidr --> 9) <!--[rfced]Please review the uses of the word "match" throughout the document. In some places, it is not clear that the constraint does not have to match both patterns given. Examples with some possible updates to help the reader. Original: The Footprint Object in this example creates a constraint matching clients in the states of New Jersey and New York, USA (ISO [ISO3166-2] codes "US-NJ" and "US-NY", respectively). Perhaps: The Footprint Object in this example creates a constraint that matches clients in the state of either New Jersey or New York, (ISO [ISO3166-2] codes "US-NJ" and "US-NY", respectively). Original: Using Footprint Objects of these types, one can define FCI Capability Advertisement Object footprint constraints that match IPv4 or IPv6 clients. However, the described "narrowing" semantic of the Footprint Objects array, as described in Appendix B of [RFC8008], prevents the usage of these objects together to create a footprint constraint that matches IPv4 clients together with IPv6 clients. Perhaps (adding "either...but not both", cutting "together", and combining the sentences): Using Footprint Objects of these types, one can define FCI Capability Advertisement Object footprint constraints that match either IPv4 or IPv6 clients, but not both, due to the described "narrowing" semantic of the Footprint Objects array (Appendix B of [RFC8008]) that prevents the usage of these objects together to create a footprint constraint that matches IPv4 clients with IPv6 clients. Original: Below is an example for an attempt at creating an object matching IPv4 clients of subnet "192.0.2.0/24", as well as IPv6 clients of subnet "2001:db8::/32". Perhaps: Below is an example attempting to create an object that matches IPv4 clients of subnet "192.0.2.0/24" as well as IPv6 clients of subnet "2001:db8::/32". --> 10) <!--[rfced] Please review the following with regard to ISO citations. a) Is ISO 3166-2 the name of the code? If not, perhaps the following change would be helpful to the reader. Note that there may be more occurences, please review all as this is simply an example. Original: The "subdivisioncode" data type specified in Section 2.1.1.1 describes a country-specific subdivision using an [ISO3166-2] code. Perhaps: The "subdivisioncode" data type specified in Section 2.1.1.1 describes a country-specific subdivision using a code described in [ISO3166-2]. b) Similar issue to that in a), but please also review if the second parenthetical should also mention "alpha-2 codes"? Original: In Figure 4, we create a constraint covering autonomous system 64496 within the US (ISO [ISO3166-1] alpha-2 code "US") and the Ontario province of Canada (ISO [ISO3166-2] code "CA-ON"). Perhaps: In Figure 4, we create a constraint covering autonomous system 64496 within the USA (ISO alpha-2 code "US" as described in [ISO3166-1]) and the Ontario province of Canada (ISO code "CA-ON" as described in [ISO3166-2]). --> 11) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> 12) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/st/mf *****IMPORTANT***** Updated 2023/06/06 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info/). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-editor@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9388.xml https://www.rfc-editor.org/authors/rfc9388.html https://www.rfc-editor.org/authors/rfc9388.pdf https://www.rfc-editor.org/authors/rfc9388.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9388-diff.html https://www.rfc-editor.org/authors/rfc9388-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9388-xmldiff1.html The following files are provided to facilitate creation of your own diff files of the XML. Initial XMLv3 created using XMLv2 as input: https://www.rfc-editor.org/authors/rfc9388.original.v2v3.xml XMLv3 file that is a best effort to capture v3-related format updates only: https://www.rfc-editor.org/authors/rfc9388.form.xml Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9388 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9388 (draft-ietf-cdni-additional-footprint-types-11) Title : Content Delivery Network Interconnection (CDNI) Footprint Types: Subdivision Code and Footprint Union Author(s) : N. Sopher, S. Mishra WG Chair(s) : Kevin J. Ma, Sanjay Mishra Area Director(s) : Murray Kucherawy, Francesca Palombini
- [auth48] AUTH48: RFC-to-be 9388 <draft-ietf-cdni-… rfc-editor
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… rfc-editor
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Megan Ferguson
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Nir Sopher
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Nir Sopher
- Re: [auth48] [E] Re: [AD] AUTH48: RFC-to-be 9388 … Mishra, Sanjay
- Re: [auth48] [E] [AD] AUTH48: RFC-to-be 9388 <dra… Megan Ferguson
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Nir Sopher
- Re: [auth48] [E] [AD] AUTH48: RFC-to-be 9388 <dra… Nir Sopher
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Murray S. Kucherawy
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Nir Sopher
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Rebecca VanRheenen
- Re: [auth48] [E] [AD] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Murray S. Kucherawy
- Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-i… Rebecca VanRheenen
- Re: [auth48] [E] AUTH48: RFC-to-be 9388 <draft-ie… Mishra, Sanjay
- Re: [auth48] [E] [AD] AUTH48: RFC-to-be 9388 <dra… Nir Sopher
- Re: [auth48] [E] AUTH48: RFC-to-be 9388 <draft-ie… Rebecca VanRheenen
- Re: [auth48] [E] AUTH48: RFC-to-be 9388 <draft-ie… Nir Sopher
- Re: [auth48] [E] AUTH48: RFC-to-be 9388 <draft-ie… Rebecca VanRheenen
- Re: [auth48] [E] AUTH48: RFC-to-be 9388 <draft-ie… Mishra, Sanjay
- [auth48] [AD] Re: [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] Re: [E] AUTH48: RFC-to-be 9388 … Mishra, Sanjay
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Mishra, Sanjay
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Nir Sopher
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Mishra, Sanjay
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Mishra, Sanjay
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Mishra, Sanjay
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Mishra, Sanjay
- Re: [auth48] [AD] Re: [E] AUTH48: RFC-to-be 9388 … Murray S. Kucherawy
- Re: [auth48] [AD] Re: [E] AUTH48: RFC-to-be 9388 … Mishra, Sanjay
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Mishra, Sanjay
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Murray S. Kucherawy
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Rebecca VanRheenen
- [auth48] [IANA] Re: AUTH48: RFC-to-be 9388 <draft… Rebecca VanRheenen
- Re: [auth48] [AD] [E] AUTH48: RFC-to-be 9388 <dra… Mishra, Sanjay
- [auth48] [IANA #1276431] [IANA] Re: AUTH48: RFC-t… Amanda Baber via RT
- Re: [auth48] [IANA #1276431] [IANA] Re: AUTH48: R… Rebecca VanRheenen
- Re: [auth48] [IANA #1276431] [IANA] Re: AUTH48: R… Rebecca VanRheenen