Re: [auth48] [AD] AUTH48: RFC-to-be 9388 <draft-ietf-cdni-additional-footprint-types-11> for your review

[Megan Ferguson <[e-mail]>]

Greetings,

Just a friendly reminder that this document awaits author and AD attention.

Please let us know if we can be of assistance during your AUTH48 review.

Thank you.

RFC Editor/mf

> On Jun 6, 2023, at 11:21 PM, [e-mail] wrote:
> 
> 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
> 
>   *  [e-mail] (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).
> 
>   *  [e-mail], 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, 
>        [e-mail] 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
> 
>