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

[Rebecca VanRheenen <[e-mail]>]

Thank you, Amanda!

Sincerely,
RFC Editor/rv



> On Jul 13, 2023, at 5:05 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi,
> 
> These changes are complete:
> 
> https://www.iana.org/assignments/cdni-parameters
> 
> Best regards,
> 
> Amanda Baber
> IANA Operations Manager
> 
> On Wed Jul 12 21:04:57 2023, [e-mail] wrote:
>> IANA,
>> 
>> Please update the "CDNI Metadata Footprint Types” registry as follows.
>> Here is the direct link to the registry:
>> https://www.iana.org/assignments/cdni-parameters/cdni-
>> parameters.xhtml#metadata-footprint-types.
>> 
>> OLD:
>>    ISO 3166-2 country subdivision code: alpha-2 country code,
>> followed by a hyphen-minus,
>>   and up to 3 characters from A-Z;0-9 as a code within the country.
>> 
>> NEW (remove comma and period):
>>    ISO 3166-2 country subdivision code: alpha-2 country code,
>> followed by a hyphen-minus
>>   and up to 3 characters from A-Z;0-9 as a code within the country
>> 
>> OLD (lowercase "footprint objects”):
>>   A combination of other Footprint Objects
>> 
>> NEW:
>>   A combination of other footprint objects
>> 
>> Thank you,
>> RFC Editor/rv
>> 
>> 
>> 
>>> On Jul 12, 2023, at 2:02 PM, Rebecca VanRheenen
>>> <[e-mail]> wrote:
>>> 
>>> Hi Murray, Sanjay, and Nir,
>>> 
>>> We have updated to the shorter version (corrected version that
>>> removes “an”) recommended by Murray. The updated files are listed
>>> below; note that you may need to refresh.
>>> 
>>> All questions have now been addressed, and we now have all approvals.
>>> In a separate email, we will request that IANA update the registry to
>>> match the approved document. We will then begin to prepare the
>>> document for publication.
>>> 
>>> Thank you all for your time, patience, and help during the AUTH48
>>> process for this document!
>>> 
>>> Updated XML file:
>>>  https://www.rfc-editor.org/authors/rfc9388.xml
>>> 
>>> Updated output files:
>>>  https://www.rfc-editor.org/authors/rfc9388.txt
>>>  https://www.rfc-editor.org/authors/rfc9388.pdf
>>>  https://www.rfc-editor.org/authors/rfc9388.html
>>> 
>>> Diff file showing all changes made during AUTH48:
>>>  https://www.rfc-editor.org/authors/rfc9388-auth48diff.html
>>> 
>>> Diff files showing all changes:
>>>   https://www.rfc-editor.org/authors/rfc9388-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9388-rfcdiff.html (side-by-
>>> side rfcdiff)
>>> 
>>> For the AUTH48 status of this document, please see:
>>>  http://www.rfc-editor.org/auth48/rfc9388
>>> 
>>> Thank you,
>>> RFC Editor/rv
>>> 
>>> 
>>> 
>>>> On Jul 11, 2023, at 8:45 PM, Murray S. Kucherawy
>>>> <[e-mail]> wrote:
>>>> 
>>>> I prefer the more terse text.  Since Sanjay indicated he can live
>>>> with it, let's proceed that way.  So that's Rebecca's proposed
>>>> correction that removes "an" only.
>>>> 
>>>> -MSK, ART AD
>>>> 
>>>> On Tue, Jul 11, 2023 at 11:18 AM Mishra, Sanjay
>>>> <[e-mail]> wrote:
>>>> Rebecca - While Murray is considering the new Abstract text, we have
>>>> one more suggestion to the proposed text. We could also not use
>>>> "removes" in the text and instead use "relaxes" for example, the NEW
>>>> abstract will read as follows:
>>>> 
>>>> Current:
>>>>  This allows for an
>>>>  additive semantics over the narrowing semantics defined in
>>>> Appendix B
>>>>  of RFC 8008 and therefore updates RFC 8008.
>>>> 
>>>> Revised:
>>>>  This new footprint union removes relaxes the narrowing constraint
>>>> of RFC 8008, where
>>>>  Appendix B states the following: "Multiple footprint constraints
>>>> are additive: the
>>>>  advertisement of different footprint types narrows the dCDN's
>>>> candidacy cumulatively.”
>>>>  This document defines  a footprint union that allows aggregation
>>>> of footprint objects and
>>>>  thus avoids the narrowing semantics defined in RFC 8008. As a
>>>> result, this change also
>>>>  updates RFC 8008.
>>>> 
>>>> Or we can leave as-is and just remove "an" from the abstract as
>>>> Murray pointed to.
>>>> 
>>>> Thanks
>>>> Sanjay
>>>> 
>>>> 
>>>> On Mon, Jul 10, 2023 at 1:35 PM Rebecca VanRheenen
>>>> <[e-mail]> wrote:
>>>> Hi Murray* and Sanjay,
>>>> 
>>>> Murray, we believe that you are suggesting cutting “an” from the
>>>> current sentence in the abstract (though let us know if there is
>>>> anything else in that sentence that you’d like to improve). Sanjay
>>>> has also suggested extending this text further. Which update is
>>>> preferred? Please discuss and let us know how to update the
>>>> document.
>>>> 
>>>> *Murray, if Sanjay’s new text is preferred, please let us know if
>>>> you approve it (we consider this update “above editorial” as it adds
>>>> new text).
>>>> 
>>>> Current:
>>>>  This allows for an
>>>>  additive semantics over the narrowing semantics defined in
>>>> Appendix B
>>>>    of RFC 8008 and therefore updates RFC 8008.
>>>> 
>>>> Perhaps (remove “an”)
>>>> This allows for
>>>>  additive semantics over the narrowing semantics defined in
>>>> Appendix B
>>>>    of RFC 8008 and therefore updates RFC 8008.
>>>> 
>>>> Or (Sanjay’s suggested text, with some minor edits):
>>>>   This new footprint union removes the narrowing constraint of RFC
>>>> 8008, where
>>>>  Appendix B states the following: "Multiple footprint constraints
>>>> are additive: the
>>>>   advertisement of different footprint types narrows the dCDN's
>>>> candidacy cumulatively.”
>>>>   This document defines  a footprint union that allows aggregation
>>>> of footprint objects and
>>>>   thus avoids the narrowing semantics defined in RFC 8008. As a
>>>> result, this change also
>>>>   updates RFC 8008.
>>>> 
>>>> Thank you,
>>>> RFC Editor/rv
>>>> 
>>>> 
>>>> 
>>>>> On Jul 8, 2023, at 3:20 PM, Mishra, Sanjay
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Hi Murray - Thank you for your comments. We think, replacing the
>>>>> original wording with the following might meet your suggestion and
>>>>> hopefully also add more context.
>>>>> 
>>>>> your comment:
>>>>> "The sentence that begins "This allows for an ..." in the modified
>>>>> abstract
>>>>> appears to contain a grammatical error, but apart from fixing that
>>>>> the new
>>>>> Abstract is approved."
>>>>> 
>>>>> Rebecca - Please see the suggested change:
>>>>> 
>>>>> OLD:
>>>>> This allows for an additive semantics over the narrowing semantics
>>>>> defined in Appendix B of RFC 8008 and therefore updates RFC 8008.
>>>>> 
>>>>> NEW:
>>>>> This new footprint union removes the narrowing constraint of RFC
>>>>> 8008, where the appendix B states that "Multiple footprint
>>>>> constraints are additive: the
>>>>> advertisement of different footprint types narrows the dCDN's
>>>>> candidacy cumulatively". This document defines
>>>>> a footprint union that allows to aggregate footprint objects and
>>>>> thus avoid the narrowing semantics defined in RFC 8008.
>>>>> As a result this change also updates RFC 8008.
>>>>> 
>>>>> Thanks
>>>>> Sanjay
>>>>> 
>>>>> On Fri, Jul 7, 2023 at 8:00 PM Murray S. Kucherawy
>>>>> <[e-mail]> wrote:
>>>>> The sentence that begins "This allows for an ..." in the modified
>>>>> abstract
>>>>> appears to contain a grammatical error, but apart from fixing that
>>>>> the new
>>>>> Abstract is approved.
>>>>> 
>>>>> -MSK, ART AD
>>>>> 
>>>>> On Wed, Jul 5, 2023 at 11:50 AM Rebecca VanRheenen
>>>>> <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>>> Hi Sanjay, Nir, and Murray*,
>>>>>> 
>>>>>> Sanjay and Nir, thank you for providing the additional edits. We
>>>>>> have
>>>>>> applied them all and posted updated files (see below). We did not
>>>>>> make any
>>>>>> changes regarding <aside> and consider that question closed per
>>>>>> your
>>>>>> response. Please review the updated files and let us know if you
>>>>>> approve
>>>>>> the document in its current form.
>>>>>> 
>>>>>> *Murray, as AD, please review the latest changes in the abstract
>>>>>> and let
>>>>>> us know if you approve. You can view the changes in this diff
>>>>>> file:
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=izrh5yCq36M_Mp9jyvN4prxiCrB_4Lv9qXtGjZj0WIc&e=
>>>>>> 
>>>>>> Updated XML file:
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=n8nqgkjRAO1xAzK1pN1RzXcjPRCRV1JzMHtiRPin8Go&e=
>>>>>> 
>>>>>> Updated output files:
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=0LWp4bviDj8SxKpwjsBA2bKPXEQ2e5YZ2suJM8RqSrg&e=
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=MeDbPGbIAixAixZdDSL4J-
>>>>>> 8d1-17t6VLWuKfznY61mw&e=
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=vuuh2LywyyPPjyFDjACeK7T0he_gTVSXYNAFAjcMdMA&e=
>>>>>> 
>>>>>> Diff file showing all changes made during AUTH48:
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=izrh5yCq36M_Mp9jyvN4prxiCrB_4Lv9qXtGjZj0WIc&e=
>>>>>> 
>>>>>> Diff files showing all changes:
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=8FGmPRkaOnT4wp7JEcjNLulabxLt4O9P1I0-
>>>>>> 29PlMDo&e=
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=r09pl7lX1i83651V75aSBavKut288c8KGAuXmlqVv2c&e=
>>>>>> (side-by-side
>>>>>> rfcdiff)
>>>>>> 
>>>>>> For the AUTH48 status of this document, please see:
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-
>>>>>> 2Deditor.org_auth48_rfc9388&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-
>>>>>> x6GdHR4ZTgoM&m=PlF4M8_QdgOcmznwdCMsxFh7aXWwvePuXEAGbxAQEynm34FjneeU8Olmzk4fY_sb&s=WM3-
>>>>>> w3gVwp_nbVxfp5d6BMb0jLOCc2qxBw9B6pQ5Y7M&e=
>>>>>> 
>>>>>> Thank you,
>>>>>> RFC Editor/rv
>>>>>> 
>>>>>> 
>>>>>>> On Jul 5, 2023, at 9:10 AM, Mishra, Sanjay
>>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi Rebecca - Thank you for the current edits. Please see our
>>>>>>> response
>>>>>> below.
>>>>>>> 
>>>>>>> With regards to the "aside" container. We did not find any need
>>>>>>> for it
>>>>>> in the document.
>>>>>>> 
>>>>>>> However, while scanning the document, we found a few additional
>>>>>>> edits:
>>>>>>> 
>>>>>>> 1. Abstract: (adding "for delegation" after "granularity to
>>>>>>> better
>>>>>> explain the context)
>>>>>>> OLD:
>>>>>>> Defining this country subdivision code improves granularity as
>>>>>>> compared
>>>>>> to the
>>>>>>> ISO 3166-1 country code footprint type defined in RFC 8006.
>>>>>>> 
>>>>>>> NEW (changes marked in bold for visual identification):
>>>>>>> Defining this country subdivision code improves granularity for
>>>>>> delegation
>>>>>>> as compared to the
>>>>>>> ISO 3166-1 country code footprint type defined in RFC 8006.
>>>>>>> 
>>>>>>> 
>>>>>>> 2. Abstract: (Remove "this" and join it with the prior sentence
>>>>>>> for ease
>>>>>> of flow of the sentence. text bolded for identification)
>>>>>>> OLD:
>>>>>>> The second footprint type defines a footprint union to aggregate
>>>>>> footprint objects. This allows for an additive semantics over the
>>>>>> narrowing
>>>>>> semantics defined in Appendix B of RFC 8008. This updates RFC
>>>>>> 8008.
>>>>>>> 
>>>>>>> New:
>>>>>>> The second footprint type defines a footprint union to aggregate
>>>>>> footprint objects. This allows for an additive semantics over the
>>>>>> narrowing
>>>>>> semantics defined in Appendix B of RFC 8008, and therefore updates
>>>>>> RFC 8008.
>>>>>>> 
>>>>>>> 3. Section 2.2 - a very long sentence that may be broken into 2
>>>>>>> parts.
>>>>>> Changes are shown in BOLD for identification of the new text
>>>>>>> OLD:
>>>>>>> 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, as described in Appendix B of that
>>>>>> prevents the
>>>>>> usage of these objects together to create a footprint constraint
>>>>>> that
>>>>>> matches IPv4 clients with IPv6 clients.
>>>>>>> 
>>>>>>> New:
>>>>>>> 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. This is due to the described "narrowing"
>>>>>> semantic of
>>>>>> the Footprint Objects array, as described in Appendix B of RFC
>>>>>> 8008 that
>>>>>> prevents the usage of these objects together to create a footprint
>>>>>> constraint that matches IPv4 clients with IPv6 clients.
>>>>>>> 
>>>>>>> 4. Section 1 Introduction (first bullet). Adding "Country" before
>>>>>> subdivision code. Text is bolded for identification.
>>>>>>> OLD:
>>>>>>> Subdivision code footprint type (e.g., for a dCDN advertising a
>>>>>> footprint that is specific to a state in the United States of
>>>>>> America)
>>>>>>> 
>>>>>>> NEW:
>>>>>>> Country subdivision code footprint type (e.g., for a dCDN
>>>>>>> advertising a
>>>>>> footprint that is specific to a state in the United States of
>>>>>> America)
>>>>>>> 
>>>>>>> 5. Section 2.2 - a typo (missing "i" and a space. also adding
>>>>>>> "country"
>>>>>> ahead of subdivision code)
>>>>>>> OLD:
>>>>>>> for example, an IPv4 CIDR together with an IPv6 CIDR or a country
>>>>>>> code
>>>>>> together with a subdivisoncode
>>>>>>> 
>>>>>>> NEW:
>>>>>>> for example, an IPv4 CIDR together with an IPv6 CIDR or a country
>>>>>>> code
>>>>>> together with a country subdivision code
>>>>>>> 
>>>>>>> 6. Section 2.2.2 - We don't think "the" is needed in this
>>>>>>> sentence (as
>>>>>> below) and also adding "country" in front of "subdivision code".
>>>>>>> OLD:
>>>>>>> The footprint union also enables the
>>>>>>> composing of footprint objects
>>>>>>> based on the
>>>>>>> country code and  subdivision code.
>>>>>>> In Figure 4, we
>>>>>>> create a constraint covering autonomous system 64496 within the
>>>>>>> USA
>>>>>>> 
>>>>>>> NEW:
>>>>>>> The footprint union also enables
>>>>>>> composing of footprint objects
>>>>>>> based on the country code and
>>>>>>> country subdivision code.
>>>>>>> In Figure 4, we
>>>>>>> create a constraint covering autonomous system 64496 within the
>>>>>>> USA
>>>>>>> 
>>>>>>> 7. Section 3.1.3 (adding "country" in front of the subdivision
>>>>>>> codes.)
>>>>>>> OLD:
>>>>>>> There is no hierarchy or inheritance for properties associated
>>>>>>> with
>>>>>> subdivision codes.
>>>>>>> New:
>>>>>>> There is no hierarchy or inheritance for properties associated
>>>>>>> with
>>>>>> country subdivision codes.
>>>>>>> Thank you very much.
>>>>>>> Nir and Sanjay
>>>>>>> 
>>>>>>> On Mon, Jul 3, 2023 at 1:21 PM Rebecca VanRheenen
>>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>> Hi Nir,
>>>>>>> 
>>>>>>> Thank you for addressing theses questions. We have updated the
>>>>>>> document
>>>>>> accordingly and added the keywords you provided to our database.
>>>>>>> 
>>>>>>> Regarding this:
>>>>>>> 
>>>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_en_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=aNcD_pgXb5qjTllxyCe5MJQgRTzMv518ReluUd8bmm0&e=
>>>>>> ).
>>>>>>>>>>>> -->
>>>>>>>>>>>> [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.
>>>>>>>>>> 
>>>>>>>>>> [rfced]  You may find more info at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=1M4B3QCqA-
>>>>>> VdOlGvuDQx_ARDiekvCjXUnsFEl3YM6OM&e=
>>>>>> .
>>>>>>>>> [NS] I'm not familiar with this concept but do not think we
>>>>>>>>> have a
>>>>>> need for such a change.
>>>>>>>> Can you please share an example for a document where it had been
>>>>>>>> in
>>>>>> use?
>>>>>>> 
>>>>>>> You can view examples in RFCs 9396 and 9393. Search for “Note:”
>>>>>>> in the
>>>>>> output files to see how these are formatted.
>>>>>>> 
>>>>>>> This is our final question. After it is addressed, we will ask
>>>>>>> Murray to
>>>>>> approve the latest changes in the abstract and then request that
>>>>>> IANA
>>>>>> update the registry to match the edited document.
>>>>>>> 
>>>>>>> Updated XML file:
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=rnI8C1TMJM7slUpITW4U5Vdm5ztUEavWyIDN1E3AAfM&e=
>>>>>>> 
>>>>>>> Updated output files:
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=IieWbMjKlQyOjbotwBn4pWyKdVhg6OHEvOZ_92Fxpac&e=
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=OsOtC3a1iG3EgG5MI90EvAiIm5JQfFFZTLCCfOi2FjU&e=
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=5RUZa-
>>>>>> waUbT9MLHL6Uk72KiqqboJpZRPGtNhb1I_XhM&e=
>>>>>>> 
>>>>>>> Diff file showing all changes made during AUTH48:
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=UKF29gl7ddwUQLv3EBUGmwRVHlWi-
>>>>>> Pb4MFMgVeu08GA&e=
>>>>>>> 
>>>>>>> Diff files showing all changes:
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=hyrRs85zhPo4vN4YB01d1PryXreU2Y-
>>>>>> TFs1wADaivqE&e=
>>>>>> 
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=SQiCq6D5pEFep56sVnJKK7eYV2HQh5AOE40pMme0PDg&e=
>>>>>> (side-by-side rfcdiff)
>>>>>>> 
>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-
>>>>>> 2Deditor.org_auth48_rfc9388&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=YlgKeXnxnaQB9jBO1Qvz99OclaLDY4kdfWGy0i_IFEw&e=
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> RFC Editor/rv
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Jun 29, 2023, at 6:28 AM, Nir Sopher <[e-mail]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Thank you Rebecca,
>>>>>>>> See comments below.
>>>>>>>> Many thanks,
>>>>>>>> Nir
>>>>>>>> 
>>>>>>>> ------
>>>>>>>> WRT the abstract. Indeed a "a" or "this is missing. Let's go for
>>>>>> adding a "this", we were also missing the "country" token
>>>>>>>> OLD: Defining subdivision code
>>>>>>>> NEW: Defining this country subdivision code
>>>>>>>> 
>>>>>>>> -------
>>>>>>>> Now, for the additional comments:
>>>>>>>> [rfced] If there are any keywords you think readers might want
>>>>>>>> to
>>>>>> search when they look for documents on this topic, and the words
>>>>>> are not
>>>>>> already in the title, we can add them to our database.
>>>>>>>> [NS/SM] We would add:
>>>>>>>> - Request Routing
>>>>>>>> - Footprint and Capabilities Semantics
>>>>>>>> 
>>>>>>>> -------
>>>>>>>> [rfced] Please review our updates to ensure that this reference
>>>>>>>> now
>>>>>> appears as desired.
>>>>>>>> [NS/SM] Reviewed. Great :)
>>>>>>>> -------
>>>>>>>>> 8) ...[rfced] We made these updates based on
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-
>>>>>> 2Dtools.ietf.org_iddiff-3Furl1-3Ddraft-2Dietf-2Dcdni-2Dadditional-
>>>>>> 2Dfootprint-2Dtypes-2D11-26url2-3Ddraft-2Dietf-2Dcdni-
>>>>>> 2Dadditional-2Dfootprint-2Dtypes-2D12-26difftype-3D-2D-
>>>>>> 2Dhwdiff&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=Z1AcNQijBUwEzbxLmx0zS3S9_ix4Q4-
>>>>>> tcdsIllVGvSc&e=
>>>>>>>> [rfced] We have updated the examples below as suggested.  Please
>>>>>>>> let
>>>>>> us know if any further occurrences of “match” need changes.
>>>>>>>> [NS/SM] Approved
>>>>>>>> 
>>>>>>>> -------
>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_en_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=aNcD_pgXb5qjTllxyCe5MJQgRTzMv518ReluUd8bmm0&e=
>>>>>> ).
>>>>>>>>> -->
>>>>>>>>> [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.
>>>>>>>> 
>>>>>>>> -------
>>>>>>>> [rfced]  You may find more info at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=1M4B3QCqA-
>>>>>> VdOlGvuDQx_ARDiekvCjXUnsFEl3YM6OM&e=
>>>>>> .
>>>>>>>> [NS] I'm not familiar with this concept but do not think we have
>>>>>>>> a
>>>>>> need for such a change.
>>>>>>>> Can you please share an example for a document where it had been
>>>>>>>> in
>>>>>> use?
>>>>>>>> 
>>>>>>>> -------
>>>>>>>>> 12) ...
>>>>>>>> [rfced] Sounds like this issue has been reviewed.
>>>>>>>> [NS/SM] Correct
>>>>>>>> 
>>>>>>>> On Wed, Jun 28, 2023 at 9:56 PM Rebecca VanRheenen <
>>>>>> [e-mail]> wrote:
>>>>>>>> Hi Nir and Sanjay,
>>>>>>>> 
>>>>>>>> Thank you for your replies! We have updated the abstract and
>>>>>>>> Section
>>>>>> 2.2 as suggested by Nir. The updated files are listed below.
>>>>>>>> 
>>>>>>>> We have one question about the abstract: should “Defining
>>>>>>>> subdivision
>>>>>> code” be updated to "Defining a subdivision code” (with “a”),
>>>>>> "Defining
>>>>>> this subdivision code” (with “this”), or something similar?
>>>>>>>> 
>>>>>>>> Current:
>>>>>>>> Defining subdivision code improves granularity as compared to
>>>>>>>> the
>>>>>> ISO3166-1
>>>>>>>> country code footprint type, defined in RFC 8006.
>>>>>>>> 
>>>>>>>> Also, Megan sent the following followup questions/comments on 22
>>>>>>>> June
>>>>>> 2023. (I’ll be the point of contact going forward as Megan is out
>>>>>> of the
>>>>>> office.) Once these and the question above about the abstract are
>>>>>> addressed, we will mark your approvals.
>>>>>>>> 
>>>>>>>> Note that once the sentence in the abstract is finalized, we
>>>>>>>> will ask
>>>>>> Murray to approve the abstract as some text was added (we consider
>>>>>> added
>>>>>> text to be “above editorial”, thus requiring AD approval). In
>>>>>> addition,
>>>>>> some changes were made to the description column in Section 4.1,
>>>>>> which
>>>>>> affects the IANA registry. After we receive all approvals, we will
>>>>>> ask IANA
>>>>>> to update the registry to match the edited document (see details
>>>>>> in the
>>>>>> note on the AUTH48 status page at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_auth48_rfc9388&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=VQjmYPucQGmeTZrxHx4YLSjD_AjjHaAC3RCCHQKTf_g&e=
>>>>>> ).
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that
>>>>>>>>> appear
>>>>>> in the title) for use on
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=H-
>>>>>> DXaaooMlmFo5W3UAuSjRt_Fy-dd-mEaPEILis6hkE&e=
>>>>>> .
>>>>>>>>> org/search. -->
>>>>>>>>> 
>>>>>>>>> [SM/NS]
>>>>>>>>> Can you please clarify?
>>>>>>>> 
>>>>>>>> [rfced] If there are any keywords you think readers might want
>>>>>>>> to
>>>>>> search when they look for documents on this topic, and the words
>>>>>> are not
>>>>>> already in the title, we can add them to our database.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__www.iso.org_obp_ui_-23iso-3Astd-3Aiso-3A3166-3A-2D2-3Aed-2D4-
>>>>>> 3Av1-
>>>>>> 3Aen&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=gGyH0z2JR4_54vqv0BBl6b5AL58HCWllGcPr3Cs9-
>>>>>> 7E&e=
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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
>>>>>>>> 
>>>>>>>> [rfced] We have left both of the above as they were.  Thank you
>>>>>>>> for
>>>>>> providing background on these choices.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__www.svta.org_product_open-2Dcache-2Drequest-
>>>>>> 2D&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=WhHa9lNnA0TysADGsuVn07x3jcJhEwjEINW6NhaL9FY&e=
>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__www.svta.org_product_open-2Dcache-2Drequest-2Drouting-
>>>>>> 2D&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=Fae8JNp_La87atc_-iT7-
>>>>>> guUyp6yGpEQYdMzUNiBcdY&e=
>>>>>>>>> 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.”
>>>>>>>> 
>>>>>>>> [rfced] Please review our updates to ensure that this reference
>>>>>>>> now
>>>>>> appears as desired.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> [rfced] We made these updates based on
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-
>>>>>> 2Dtools.ietf.org_iddiff-3Furl1-3Ddraft-2Dietf-2Dcdni-2Dadditional-
>>>>>> 2Dfootprint-2Dtypes-2D11-26url2-3Ddraft-2Dietf-2Dcdni-
>>>>>> 2Dadditional-2Dfootprint-2Dtypes-2D12-26difftype-3D-2D-
>>>>>> 2Dhwdiff&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=Z1AcNQijBUwEzbxLmx0zS3S9_ix4Q4-
>>>>>> tcdsIllVGvSc&e=
>>>>>> .
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>> 4) "footprintunion" should be used in some cases - we are
>>>>>>>>> trying to
>>>>>> understand where
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> [rfced] We have updated the examples below as suggested.  Please
>>>>>>>> let
>>>>>> us know if any further occurrences of “match” need changes.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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].
>>>>>>>> 
>>>>>>>> [rfced] Thank you for this guidance. Please review other similar
>>>>>> instances throughout the doc and let us know if/how they may be
>>>>>> updated
>>>>>> using old/new text.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_en_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=aNcD_pgXb5qjTllxyCe5MJQgRTzMv518ReluUd8bmm0&e=
>>>>>> ).
>>>>>>>>> -->
>>>>>>>>> [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.
>>>>>>>> 
>>>>>>>> [rfced]  You may find more info at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=1M4B3QCqA-
>>>>>> VdOlGvuDQx_ARDiekvCjXUnsFEl3YM6OM&e=
>>>>>> .
>>>>>>>> 
>>>>>>>> ______________
>>>>>>>> 
>>>>>>>> Updated XML file:
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=rnI8C1TMJM7slUpITW4U5Vdm5ztUEavWyIDN1E3AAfM&e=
>>>>>>>> 
>>>>>>>> Updated output files:
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=IieWbMjKlQyOjbotwBn4pWyKdVhg6OHEvOZ_92Fxpac&e=
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=OsOtC3a1iG3EgG5MI90EvAiIm5JQfFFZTLCCfOi2FjU&e=
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=5RUZa-
>>>>>> waUbT9MLHL6Uk72KiqqboJpZRPGtNhb1I_XhM&e=
>>>>>>>> 
>>>>>>>> Diff file showing all changes made during AUTH48:
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=UKF29gl7ddwUQLv3EBUGmwRVHlWi-
>>>>>> Pb4MFMgVeu08GA&e=
>>>>>>>> 
>>>>>>>> Diff files showing all changes:
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=hyrRs85zhPo4vN4YB01d1PryXreU2Y-
>>>>>> TFs1wADaivqE&e=
>>>>>> 
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=SQiCq6D5pEFep56sVnJKK7eYV2HQh5AOE40pMme0PDg&e=
>>>>>> (side-by-side rfcdiff)
>>>>>>>> 
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-
>>>>>> 2Deditor.org_auth48_rfc9388&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=YlgKeXnxnaQB9jBO1Qvz99OclaLDY4kdfWGy0i_IFEw&e=
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> RFC Editor/rv
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Jun 27, 2023, at 10:48 PM, Nir Sopher <[e-mail]>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Megan,
>>>>>>>>> 
>>>>>>>>> All the changes look great. Thank you.  That said, we do have
>>>>>> two-more changes (sorry).  The first change is the reworded
>>>>>> Abstract. We
>>>>>> feel this will make it easier for the reader to follow the work
>>>>>> done in
>>>>>> this document (the original wording can be hard to follow). You
>>>>>> may find
>>>>>> grammatical nits here but otherwise the abstract is contextually
>>>>>> the same
>>>>>> as the current version.
>>>>>>>>> 
>>>>>>>>> The Second change is a slight correction in paragraph 2.2.
>>>>>>>>> This we
>>>>>> think should be our final changes. Following are the changes
>>>>>> proposed:
>>>>>>>>> 
>>>>>>>>> Abstract:
>>>>>>>>> NEW:
>>>>>>>>> Open Caching architecture is a use case of Content Delivery
>>>>>>>>> Network
>>>>>> Interconnection (CDNI) in which the commercial Content Delivery
>>>>>> Network
>>>>>> (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves
>>>>>> as the
>>>>>> downstream CDN (dCDN). RFC 8006 defines footprint types which are
>>>>>> used for
>>>>>> footprint objects as part of the Metadata interface (MI). The
>>>>>> footprint
>>>>>> types are also used for the Footprint & Capabilities Advertisement
>>>>>> interface (FCI) as defined in RFC 8008. This document defines two
>>>>>> new
>>>>>> footprint types, the first footprint type defined is an ISO3166-2
>>>>>> country
>>>>>> subdivision code. Defining subdivision code improves granularity
>>>>>> as
>>>>>> compared to the ISO3166-1 country code footprint type, defined in
>>>>>> RFC
>>>>>> 8006.  The ISO3166-2 country subdivision code is also added as a
>>>>>> new entity
>>>>>> domain type in the "ALTO Entity Domain Types" subregistry as
>>>>>> defined in
>>>>>> Section 7.4 of RFC 9241. The second footprint type defines a
>>>>>> footprint
>>>>>> union to aggregate footprint objects. This allows for an additive
>>>>>> semantics
>>>>>> over the narrowing semantics defined in Appendix B of RFC 8008.
>>>>>> This
>>>>>> updates RFC 8008. The two new footprint types are based on the
>>>>>> requirements
>>>>>> raised by Open Caching, but are also applicable to CDNI use cases
>>>>>> in
>>>>>> general.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Section 2.2
>>>>>>>>> The second paragraph starts with:
>>>>>>>>> OLD:
>>>>>>>>> Sections 4.3.5 and 4.3.6 of [RFC8006] specify the IPv4 CIDR and
>>>>>>>>> the
>>>>>> IPv6 CIDR footprint types
>>>>>>>>> Where it should be changed to:
>>>>>>>>> NEW:
>>>>>>>>> Sections 4.3.5 and 4.3.6 of [RFC8006] specify the "ipv4cidr"
>>>>>>>>> and the
>>>>>> "ipv6cidr" footprint types
>>>>>>>>> 
>>>>>>>>> After these changes, the document is approved by both of us.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Sanjay & Nir
>>>>>>>>> 
>>>>>>>>> On Fri, Jun 23, 2023 at 7:04 PM Nir Sopher
>>>>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>>>> Thanks for pushing it forward,
>>>>>>>>> Will further review at the beginning of next week.
>>>>>>>>> Have a nice weekend.
>>>>>>>>> Nir
>>>>>>>>> 
>>>>>>>>> On Fri, Jun 23, 2023 at 12:28 AM Megan Ferguson
>>>>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Sanjay and Nir (and *ADs),
>>>>>>>>> 
>>>>>>>>> [*ADs - please review and approve the author-submitted changes
>>>>>>>>> to
>>>>>> our question #1 below.]
>>>>>>>>> 
>>>>>>>>> Thank you for your replies.  We have updated the document based
>>>>>>>>> on
>>>>>> your comments below.
>>>>>>>>> 
>>>>>>>>> Please also note that we have incorporated some responses
>>>>>>>>> marked
>>>>>> with [rfced] in the mail below (items closed out have been
>>>>>> snipped). Please
>>>>>> let us know if we can be of further assistance with any of the
>>>>>> outstanding
>>>>>> issues.
>>>>>>>>> 
>>>>>>>>> The files have been posted here:
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=IieWbMjKlQyOjbotwBn4pWyKdVhg6OHEvOZ_92Fxpac&e=
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=OsOtC3a1iG3EgG5MI90EvAiIm5JQfFFZTLCCfOi2FjU&e=
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=5RUZa-
>>>>>> waUbT9MLHL6Uk72KiqqboJpZRPGtNhb1I_XhM&e=
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=rnI8C1TMJM7slUpITW4U5Vdm5ztUEavWyIDN1E3AAfM&e=
>>>>>>>>> 
>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=hyrRs85zhPo4vN4YB01d1PryXreU2Y-
>>>>>> TFs1wADaivqE&e=
>>>>>> (comprehensive diff)
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=SQiCq6D5pEFep56sVnJKK7eYV2HQh5AOE40pMme0PDg&e=
>>>>>> (comprehensive rfcdiff)
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_authors_rfc9388-
>>>>>> 2Dauth48diff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=UKF29gl7ddwUQLv3EBUGmwRVHlWi-
>>>>>> Pb4MFMgVeu08GA&e=
>>>>>> (AUTH48 changes only)
>>>>>>>>> 
>>>>>>>>> The AUTH48 status page is viewable here:
>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-
>>>>>> 2Deditor.org_auth48_rfc9388&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=YlgKeXnxnaQB9jBO1Qvz99OclaLDY4kdfWGy0i_IFEw&e=
>>>>>>>>> 
>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> RFC Editor/mf
>>>>>>>>> 
>>>>>>>>>> On Jun 16, 2023, at 9:26 AM, Mishra, Sanjay <
>>>>>> [e-mail]> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hello there is a slight update from our last response RE the
>>>>>> [OC-RR].
>>>>>>>>>> 
>>>>>>>>>> The webpage administrator confirms the version is 2.0 (already
>>>>>> confirmed) but that Thomas Edwards name in the webpage was
>>>>>> erroneously
>>>>>> listed as one of the co-authors. The SVTA administrator will
>>>>>> update the
>>>>>> document webpage to reflect the document version as 2.0 and remove
>>>>>> Thomas
>>>>>> Edwards. Yoav Gressel as co-author is listed on the webpage and
>>>>>> also in the
>>>>>> document.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Sanjay and Nir
>>>>>>>>>> 
>>>>>>>>>> On Thu, Jun 15, 2023 at 4:09 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcdni-2Dadditional-
>>>>>> 2Dfootprint-
>>>>>> 2Dtypes_writeup_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=EAl7D2D-
>>>>>> HAbXpNeMnyvElnb0BM62XGZaAoG7mfZEveo&e=
>>>>>> ):
>>>>>>>>>> 
>>>>>>>>>> "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.
>>>>>>>>> 
>>>>>>>>> [rfced] *AD - please confirm that the updates to the text of
>>>>>>>>> the
>>>>>> Abstract are the correct action here.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that
>>>>>> appear in the title) for use on
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=H-
>>>>>> DXaaooMlmFo5W3UAuSjRt_Fy-dd-mEaPEILis6hkE&e=
>>>>>> .
>>>>>>>>>> org/search. -->
>>>>>>>>>> 
>>>>>>>>>> [SM/NS]
>>>>>>>>>> Can you please clarify?
>>>>>>>>> 
>>>>>>>>> [rfced] If there are any keywords you think readers might want
>>>>>>>>> to
>>>>>> search when they look for documents on this topic, and the words
>>>>>> are not
>>>>>> already in the title, we can add them to our database.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__www.iso.org_obp_ui_-23iso-3Astd-3Aiso-3A3166-3A-2D2-3Aed-2D4-
>>>>>> 3Av1-
>>>>>> 3Aen&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=gGyH0z2JR4_54vqv0BBl6b5AL58HCWllGcPr3Cs9-
>>>>>> 7E&e=
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> [rfced] We have left both of the above as they were.  Thank you
>>>>>>>>> for
>>>>>> providing background on these choices.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__www.svta.org_product_open-2Dcache-2Drequest-
>>>>>> 2D&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=WhHa9lNnA0TysADGsuVn07x3jcJhEwjEINW6NhaL9FY&e=
>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__www.svta.org_product_open-2Dcache-2Drequest-2Drouting-
>>>>>> 2D&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=Fae8JNp_La87atc_-iT7-
>>>>>> guUyp6yGpEQYdMzUNiBcdY&e=
>>>>>>>>>> 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.”
>>>>>>>>> [rfced] Please review our updates to ensure that this reference
>>>>>>>>> now
>>>>>> appears as desired.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>> [rfced] We made these updates based on
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__author-
>>>>>> 2Dtools.ietf.org_iddiff-3Furl1-3Ddraft-2Dietf-2Dcdni-2Dadditional-
>>>>>> 2Dfootprint-2Dtypes-2D11-26url2-3Ddraft-2Dietf-2Dcdni-
>>>>>> 2Dadditional-2Dfootprint-2Dtypes-2D12-26difftype-3D-2D-
>>>>>> 2Dhwdiff&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=Z1AcNQijBUwEzbxLmx0zS3S9_ix4Q4-
>>>>>> tcdsIllVGvSc&e=
>>>>>> .
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> 4) "footprintunion" should be used in some cases - we are
>>>>>>>>>> trying
>>>>>> to understand where
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>> [rfced] We have updated the examples below as suggested.
>>>>>>>>> Please let
>>>>>> us know if any further occurrences of “match” need changes.
>>>>>>>>>> 
>>>>>>>>>> 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].
>>>>>>>>> 
>>>>>>>>> [rfced] Thank you for this guidance. Please review other
>>>>>>>>> similar
>>>>>> instances throughout the doc and let us know if/how they may be
>>>>>> updated
>>>>>> using old/new text.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_en_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=aNcD_pgXb5qjTllxyCe5MJQgRTzMv518ReluUd8bmm0&e=
>>>>>> ).
>>>>>>>>>> -->
>>>>>>>>>> [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.
>>>>>>>>> 
>>>>>>>>> [rfced]  You may find more info at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_rfcxml-2Dvocabulary-
>>>>>> 23aside&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=1M4B3QCqA-
>>>>>> VdOlGvuDQx_ARDiekvCjXUnsFEl3YM6OM&e=
>>>>>> .
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 12) <!-- [rfced] Please review the "Inclusive Language"
>>>>>>>>>> portion of
>>>>>> the online
>>>>>>>>>> Style Guide <
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_styleguide_part2_-23inclusive-
>>>>>> 5Flanguage&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=7x1Jn1xJ1hiMoAjgIuWr_Sf8lm2sMn9H7G4w4qDDFHE&e=
>>>>>>> 
>>>>>>>>>> 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.
>>>>>>>>> 
>>>>>>>>> [rfced] Sounds like this issue has been reviewed.
>>>>>>>>>> -->
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>>>> 2Deditor.org_faq_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=7YSpqlsTHjcQ8YAMJVyrVR0YMbLdYc3DdARILwjNU18&e=
>>>>>> ).
>>>>>>>>>> 
>>>>>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__trustee.ietf.org_license-
>>>>>> 2Dinfo_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=FPbPNwV_sBzKZwXzYYsn5P7i_GvEU6TboolWuZe7ucs&e=
>>>>>> ).
>>>>>>>>>> 
>>>>>>>>>> *  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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__authors.ietf.org_rfcxml-
>>>>>> 2Dvocabulary&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=jiL_Sr4EDl2qOhOY6k9Sln40SY7AmjfBtkoI40bIdDM&e=
>>>>>>> .
>>>>>>>>>> 
>>>>>>>>>> *  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://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__mailarchive.ietf.org_arch_msg_ietf-2Dannounce_yb6lpIGh-
>>>>>> 2D4Q9l2USxIAe6P8O4Zc&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=L4yMi5CKgKNJMXGv4Li8mt_atMJqPTgNPvk3h8Q1bVo&e=
>>>>>>>>>> 
>>>>>>>>>> *  The archive itself:
>>>>>>>>>> 
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>>>> 3A__mailarchive.ietf.org_arch_browse_auth48archive_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-
>>>>>> hTVIWCi3T-x6GdHR4ZTgoM&m=vqL67r-dxlTLD00nLimEoRk-
>>>>>> HnqUkkR4Y7TKyggeyJ6irSZTN_vOgS4gSbY0uOL7&s=hYct6pa-
>>>>>> QRA4O44GNKSxOisHQoCUPq2SmCw6pbcY5R4&e=
>>>>>>>>>> 
>>>>>>>>>> *  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
>>>> 
>>> 
>