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

[Nir Sopher <[e-mail]>]

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://www.rfc-editor.org/authors/rfc9388.txt
>>    https://www.rfc-editor.org/authors/rfc9388.pdf
>>    https://www.rfc-editor.org/authors/rfc9388.html
>>    https://www.rfc-editor.org/authors/rfc9388.xml
>>
>>   The relevant diff files have been posted here:
>>    https://www.rfc-editor.org/authors/rfc9388-diff.html (comprehensive
>> diff)
>>    https://www.rfc-editor.org/authors/rfc9388-rfcdiff.html
>> (comprehensive rfcdiff)
>>    https://www.rfc-editor.org/authors/rfc9388-auth48diff.html (AUTH48
>> changes only)
>>
>>   The AUTH48 status page is viewable here:
>>     http://www.rfc-editor.org/auth48/rfc9388
>>
>> 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://datatracker.ietf.org/doc/draft-ietf-cdni-additional-footprint-types/writeup/
>> ):
>> >
>> > "The document also updates RFC 9241 with relevant ALTO entity
>> > domain types."
>> >
>> > The current header only indicates RFC 8008 as being updated by this
>> document.
>> > Please advise.
>> >
>> > -->
>> > [NS/SM]
>> > We think it would be best to change the wording a bit:
>> > Original:
>> > This document also supplements RFC 9241 with relevant ALTO entity
>> domain types.
>> > Suggested:
>> > Furthermore, this document defines a new entity domain type registered
>> in the ALTO Entity Domain Types Registry, as defined in section 7.4 of RFC
>> 9241.
>>
>> [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://www.rfc-editor.
>> > 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://www.iso.org/obp/ui/#iso:std:iso:3166:-2:ed-4:v1:en
>> >
>> >
>> > b) Is this spacing correct?
>> >
>> > Original:
>> > Characters from A-Z;0-9
>> >
>> > Perhaps:
>> > Characters from A-Z and 0-9
>> >
>> > -->
>> > [SM/NS]
>> >  For the ease of reading we agree with your suggestion.
>> > Yet again, this was copied from the ISO defining the values structure
>>
>> [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://www.svta.org/product/open-cache-request-
>> >               routing-functional-specification/>.
>> > Perhaps:
>> >    [OC-RR]    Finkelman, O., Ed., Zurat, B., Sahar, D., Klein, E.,
>> >               Hofmann, J., Ma, K.J., Stock, M., Mishra, S., Edwards, T.,
>> >               and Y. Yoav, "Open Caching - Request Routing Functional
>> >               Specification", Version 2.0, 15 January 2021,
>> >               <https://www.svta.org/product/open-cache-request-routing-
>> >               functional-specification/>.
>> > -->
>> > [SM/NS]
>> > We will stick to version 2.0
>> > We are working to get the OC-RR webpage updated to reflect version 2.0.
>> > We would also push forward adding Thomas Edwards to the authors list
>> (Yoav is already listed in the document).
>> > Please note that in the proposal Yoav was added as "Y. Yoav" instead of
>> "G. Yoav" or to be consistent "Gressel, Y.”
>> [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://author-tools.ietf.org/iddiff?url1=draft-ietf-cdni-additional-footprint-types-11&url2=draft-ietf-cdni-additional-footprint-types-12&difftype=--hwdiff
>> .
>> >
>> >
>> > 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://authors.ietf.org/en/rfcxml-vocabulary#aside).
>> > -->
>> > [NS] I do not fully understand the point here.
>> > Will try to read more about it, but if you can give more details/an
>> example it would greatly assist me.
>>
>> [rfced]  You may find more info at
>> https://authors.ietf.org/rfcxml-vocabulary#aside.
>> >
>> >
>> > 12) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online
>> > Style Guide <
>> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>> > and let us know if any changes are needed.
>> >
>> > Note that our script did not flag any words in particular, but this
>> should
>> > still be reviewed as a best practice.
>>
>> [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://www.rfc-editor.org/faq/).
>> >
>> > You and you coauthors are responsible for engaging other parties
>> > (e.g., Contributors or Working Group) as necessary before providing
>> > your approval.
>> >
>> > Planning your review
>> > ---------------------
>> >
>> > Please review the following aspects of your document:
>> >
>> > *  RFC Editor questions
>> >
>> >    Please review and resolve any questions raised by the RFC Editor
>> >    that have been included in the XML file as comments marked as
>> >    follows:
>> >
>> >    <!-- [rfced] ... -->
>> >
>> >    These questions will also be sent in a subsequent email.
>> >
>> > *  Changes submitted by coauthors
>> >
>> >    Please ensure that you review any changes submitted by your
>> >    coauthors.  We assume that if you do not speak up that you
>> >    agree to changes submitted by your coauthors.
>> >
>> > *  Content
>> >
>> >    Please review the full content of the document, as this cannot
>> >    change once the RFC is published.  Please pay particular attention
>> to:
>> >    - IANA considerations updates (if applicable)
>> >    - contact information
>> >    - references
>> >
>> > *  Copyright notices and legends
>> >
>> >    Please review the copyright notice and legends as defined in
>> >    RFC 5378 and the Trust Legal Provisions
>> >    (TLP – https://trustee.ietf.org/license-info/).
>> >
>> > *  Semantic markup
>> >
>> >    Please review the markup in the XML file to ensure that elements of
>> >    content are correctly tagged.  For example, ensure that <sourcecode>
>> >    and <artwork> are set correctly.  See details at
>> >    <https://authors.ietf.org/rfcxml-vocabulary>.
>> >
>> > *  Formatted output
>> >
>> >    Please review the PDF, HTML, and TXT files to ensure that the
>> >    formatted output, as generated from the markup in the XML file, is
>> >    reasonable.  Please note that the TXT will have formatting
>> >    limitations compared to the PDF and HTML.
>> >
>> >
>> > Submitting changes
>> > ------------------
>> >
>> > To submit changes, please reply to this email using ‘REPLY ALL’ as all
>> > the parties CCed on this message need to see your changes. The parties
>> > include:
>> >
>> >    *  your coauthors
>> >
>> >    *  [e-mail] (the RPC team)
>> >
>> >    *  other document participants, depending on the stream (e.g.,
>> >       IETF Stream participants are your working group chairs, the
>> >       responsible ADs, and the document shepherd).
>> >
>> >    *  [e-mail], which is a new archival mailing
>> list
>> >       to preserve AUTH48 conversations; it is not an active discussion
>> >       list:
>> >
>> >      *  More info:
>> >
>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>> >
>> >      *  The archive itself:
>> >         https://mailarchive.ietf.org/arch/browse/auth48archive/
>> >
>> >      *  Note: If only absolutely necessary, you may temporarily opt out
>> >         of the archiving of messages (e.g., to discuss a sensitive
>> matter).
>> >         If needed, please add a note at the top of the message that you
>> >         have dropped the address. When the discussion is concluded,
>> >         [e-mail] will be re-added to the CC list
>> and
>> >         its addition will be noted at the top of the message.
>> >
>> > You may submit your changes in one of two ways:
>> >
>> > An update to the provided XML file
>> >  — OR —
>> > An explicit list of changes in this format
>> >
>> > Section # (or indicate Global)
>> >
>> > OLD:
>> > old text
>> >
>> > NEW:
>> > new text
>> >
>> > You do not need to reply with both an updated XML file and an explicit
>> > list of changes, as either form is sufficient.
>> >
>> > We will ask a stream manager to review and approve any changes that seem
>> > beyond editorial in nature, e.g., addition of new text, deletion of
>> text,
>> > and technical changes.  Information about stream managers can be found
>> in
>> > the FAQ.  Editorial changes do not require approval from a stream
>> manager.
>> >
>> >
>> > Approving for publication
>> > --------------------------
>> >
>> > To approve your RFC for publication, please reply to this email stating
>> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>> > as all the parties CCed on this message need to see your approval.
>> >
>> >
>> > Files
>> > -----
>> >
>> > The files are available here:
>> >    https://www.rfc-editor.org/authors/rfc9388.xml
>> >    https://www.rfc-editor.org/authors/rfc9388.html
>> >    https://www.rfc-editor.org/authors/rfc9388.pdf
>> >    https://www.rfc-editor.org/authors/rfc9388.txt
>> >
>> > Diff file of the text:
>> >    https://www.rfc-editor.org/authors/rfc9388-diff.html
>> >    https://www.rfc-editor.org/authors/rfc9388-rfcdiff.html (side by
>> side)
>> >
>> > Diff of the XML:
>> >    https://www.rfc-editor.org/authors/rfc9388-xmldiff1.html
>> >
>> > The following files are provided to facilitate creation of your own
>> > diff files of the XML.
>> >
>> > Initial XMLv3 created using XMLv2 as input:
>> >    https://www.rfc-editor.org/authors/rfc9388.original.v2v3.xml
>> >
>> > XMLv3 file that is a best effort to capture v3-related format updates
>> > only:
>> >    https://www.rfc-editor.org/authors/rfc9388.form.xml
>> >
>> >
>> > Tracking progress
>> > -----------------
>> >
>> > The details of the AUTH48 status of your document are here:
>> >    https://www.rfc-editor.org/auth48/rfc9388
>> >
>> > Please let us know if you have any questions.
>> >
>> > Thank you for your cooperation,
>> >
>> > RFC Editor
>> >
>> > --------------------------------------
>> > RFC9388 (draft-ietf-cdni-additional-footprint-types-11)
>> >
>> > Title            : Content Delivery Network Interconnection (CDNI)
>> Footprint Types: Subdivision Code and Footprint Union
>> > Author(s)        : N. Sopher, S. Mishra
>> > WG Chair(s)      : Kevin J. Ma, Sanjay Mishra
>> > Area Director(s) : Murray Kucherawy, Francesca Palombini
>> >
>> >
>>
>>
>>