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

[Nir Sopher <[e-mail]>]

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