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

[Amanda Baber via RT <[e-mail]>]

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
> >>
> >