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

["Mishra, Sanjay" <[e-mail]>]

Hi Rebecca - Thank you. All the changes look good. Greatly appreciate all
your help.

Murray - Thank you so much for all your time in reviewing the work and
providing us valuable feedback.

Thanks
Nir and Sanjay

On Wed, Jul 12, 2023 at 5: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://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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=F_eolJamGHOS1rhrZrpm5XwDwwKa727qni_ZMF93Jjs&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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=7mX-tLbsC5Jr1cWMdJ644LIHUiOMh754_umFSpD4SJs&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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=axtMZw77sq42m56U1jARr0ZfrFS6bQ0ovH373vuqtBM&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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=Cj3b4gtW_g9Bx0-02qTZ9xao97sDojdZoZWo6lU-6D0&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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=VX6NpmHOpVn2TSHRRYCh8mzP6jZHNOKHUFgUr8TUddk&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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=EmqPogZRydS9AleQlhskmIXukgzgoys1hKZ4-6WknO4&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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=CGNG0WHHiimjjiZThvRNaTUElLw1tClHOaaM1hY_NX8&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=F56GHt_PwCm3PMOcPuXo1pvfKIGlO-HpDDXe6OU18YOTjoZnb2yuFFDr1fXFz_zg&s=FOGQwNkZRqB6-n0wLm6rfouda05wxkmgAVzjl-hDdiY&e=
>
> 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
> >
>
>