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

[Nir Sopher <[e-mail]>]

Resending with "reply to all"

On Thu, Jun 22, 2023 at 6:11 PM Nir Sopher <[e-mail]> wrote:

> Hi,
>
> We had just released v12 of the draft.
> Handling items 8 and 9. See additional comments inline.
> We used "footprintunion" when we refer to the type name, and "footprint
> union" when we refer to the logical object.
> You might see the "footprintunion" including in section headers. I hope it
> is OK.
>
> We have reviewed the doc for inclusive language (item 12) and did not find
> any issue.
>
> Cheers,
> Nir
>
>
> On Thu, Jun 15, 2023 at 11:08 PM Nir Sopher <[e-mail]> wrote:
>
>> Hi,
>> And thank you very much for the comments.
>> See responses inline.
>> WRT item #8, #9, #12 we will do our best to prepare a new XML with the
>> proper changes by the beginning of next week.
>> Many thanks,
>> Nir
>>
>>
>> On Wed, Jun 7, 2023 at 6:22 AM <[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.
>>>
>>> -->
>>>
>> [NS/SM]
>> We think it would be best to change the wording a bit:
>> Original:
>>
>> This document also supplements RFC 9241 with relevant ALTO entity domain types.
>>
>> Suggested:
>>
>> Furthermore, this document defines a new entity domain type registered in the ALTO Entity Domain Types Registry, as defined in section 7.4 of RFC 9241.
>>
>>
>>>
>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
>>> the title) for use on https://www.rfc-editor.
>>> org/search. -->
>>>
>>
>> [SM/NS]
>> Can you please clarify?
>>
>>
>>>
>>> 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.
>>> -->
>>>
>>
>> [SM/NS]
>> Agree, thanks
>>
>>
>>>
>>>
>>> 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.
>>> -->
>>>
>>> [SM/NS]
>> Suggested:
>> Appendix B of [RFC8008] specifies the semantics for Footprint
>>    Advertisement such that multiple footprint constraints are additive.
>>
>>
>>> 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.
>>> -->
>>>
>>> [SM/NS]
>> Agreed. Thanks
>>
>>>
>>> 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?
>>>
>>
>> [SM/NS]
>> We can drop the "-minus" and leave only the "hyphen".
>> Note that we took the "hyphen-minus" terminology for the actual ISO
>> defining the country subdivision values:
>> See https://www.iso.org/obp/ui/#iso:std:iso:3166:-2:ed-4:v1:en
>>
>>
>>> b) Is this spacing correct?
>>>
>>> Original:
>>> Characters from A-Z;0-9
>>>
>>> Perhaps:
>>> Characters from A-Z and 0-9
>>>
>>> -->
>>>
>> [SM/NS]
>>  For the ease of reading we agree with your suggestion.
>> Yet again, this was copied from the ISO defining the values structure
>>
>>
>>>
>>> 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/>.
>>> -->
>>>
>> [SM/NS]
>> We will stick to version 2.0
>> We are working to get the OC-RR webpage updated to reflect version 2.0.
>> We would also push forward adding Thomas Edwards to the authors list
>> (Yoav is already listed in the document).
>> Please note that in the proposal Yoav was added as "Y. Yoav" instead of
>> "G. Yoav" or to be consistent "Gressel, Y."
>>
>>
>>>
>>> 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)
>>>
>>
>> [SM/NS] we changed all instances to lower case "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"
>>>
>>> [SM/NS] We are comparing the draft with previous RFCs and trying to come
>> up wit a consistent scheme for different use cases
>> 1) "Footprint Type": "type" should  be in lower case unless it is part of
>> the section header
>> 2)  "footprint-type": the dash is OK when it is part of an anchor or when
>> it stand for the property name (in the different examples)
>> 3) "Footprint Union": should be capitalized
>>
> ==> footprint union should be lower case
>
>> 4) "footprintunion" should be used in some cases - we are trying to
>> understand where
>>
> ==>  "footprintunion" is now used only when it stands for the actual
> footprint type
>
>>
>>
>> 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
>>>
>>> [SM/NS] this case is similar to the "Footprint Union" case. We will work
>> on it and would update
>>
> ==>  "subdivisioncode" is now used only when it stands for the actual
> footprint type
>
>>
>>
>
>>
>>> 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
>>>
>>> -->
>>>
>>> [SM/NS] This is again the "footprint union" vs. "footprintunion" issue.
>> We will find a consistent usage
>>
> ==>  "ipv4cidr" /"ipv6cidr" are now used only when they stand for the
> actual footprint types
>
>>
>
>>
>>> 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).
>>>
>>
>> [SM/NS]  Agreed
>>
>>
>>> 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.
>>>
>>
>> [SM/NS] Agreed
>>
>>
>>>
>>> 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".
>>> -->
>>>
>> [SM/NS] Agreed
>>
>>>
>>>
>>> 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].
>>>
>> [SM/NS]
>> Maybe:
>> The "subdivisioncode" data type specified in Section 2.1.1.1
>>    describes a country-specific subdivision using a code* as defined* 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]).
>>> -->
>>>
>>> [SM/NS] Agreed
>>
>>
>>>
>>> 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).
>>> -->
>>>
>> [NS] I do not fully understand the point here.
>> Will try to read more about it, but if you can give more details/an
>> example it would greatly assist me.
>>
>>>
>>>
>>> 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
>>>
>>>
>>>