Hi Job, Thanks for your review. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9697>. We will wait to hear from your coauthor before continuing with the publication process.
Thank you, RFC Editor/sg > On Dec 3, 2024, at 3:11 AM, Job Snijders <[email protected]> wrote: > > Dear Sandy, > > I approve publication. > > Thank you so much for your work! The document became much better. > > Kind regards, > > Job > > On Mon, Dec 02, 2024 at 02:58:34PM -0800, Sandy Ginoza wrote: >> Hi Job, >> >> We have updated the document as described below. In addition, we updated >> the XML to include a closing quote after 1772 as follows: >> >> <delta serial="1772 uri="https://rrdp.example.net/1772/delta.xml” >> >> >> The current files are available here: >> https://www.rfc-editor.org/authors/rfc9697.xml >> https://www.rfc-editor.org/authors/rfc9697.txt >> https://www.rfc-editor.org/authors/rfc9697.pdf >> https://www.rfc-editor.org/authors/rfc9697.html >> >> AUTH48 diff (currently shows the most recent updates only): >> https://www.rfc-editor.org/authors/rfc9697-auth48diff.html >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9697-diff.html >> https://www.rfc-editor.org/authors/rfc9697-rfcdiff.html >> >> Please review and let us know if any additional updates are needed or if you >> approve the RFC for publication. >> >> Thank you, >> RFC Editor/sg >> >> >>> On Nov 27, 2024, at 3:36 AM, Job Snijders <[email protected]> >>> wrote: >>> >>> Dear RFC Editor, >>> >>> On Tue, Nov 26, 2024 at 07:00:09PM -0800, [email protected] wrote: >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> >>>> 1) <!-- [rfced] We are having trouble parsing this text. We see this text >>>> appears in RFC 7115: >>>> >>>> Like the DNS, the global RPKI presents only a loosely consistent >>>> view, depending on timing, updating, fetching, etc. >>>> >>>> When combined in the new sentence, it is unclear how "depending on >>>> timing..." relates to the rest of the sentence. Perhaps the sentence >>>> should be broken into two? Please clarify. >>>> >>>> Original: >>>> While the global RPKI is understood to present a loosely consistent >>>> view, depending on timing, updating, fetching (see Section 6 of >>>> [RFC7115]), different caches having different data for the same RRDP >>>> session at the same serial violates the principle of least >>>> astonishment. >>>> --> >>> >>> PERHAPS: >>> Even though the global RPKI is understood to present a loosely >>> consistent view which depends on the cache's timing of updates (see >>> Section 6 of [RFC7115]), different caches having different data for >>> the same RRDP session at the same serial violates the principle of >>> least astonishment. >>> >>>> 2) <!-- [rfced] May the word 'protocol' be removed from the following >>>> (as shown below) because it's redundant with the expansion of RRDP? >>>> >>>> Original: >>>> ... is an absolute requirement for the RRDP protocol to work well. >>>> >>>> Perhaps: >>>> ... is an absolute requirement for RRDP to work well. >>>> --> >>> >>> Yes, "... is an absolute requirement for RRDP to work well." is OK. >>> >>>> 3) <!-- [rfced] We have added a closing quote to the last line of figure 1 >>>> so it's well formed. Please review and let us know if corrections are >>>> needed. >>>> >>>> Original: >>>> <delta serial="1772" >>>> hash="d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939" >>>> uri="https://rrdp.example.net/1772/delta.xml /> >>>> >>>> Current: >>>> <delta serial="1772" >>>> hash="d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939" >>>> uri="https://rrdp.example.net/1772/delta.xml"; /> >>> >>> Ah, good catch, thank you! >>> >>>> We updated figure 3 similarly. Please review. >>>> >>>> Original: >>>> <delta serial="1775" >>>> >>>> >>>> hash="d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc" >>>> >>>> uri="https://rrdp.example.net/1775/delta.xml /> >>>> >>>> Current: >>>> <delta serial="1775" >>>> >>>> hash="d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc" >>>> uri="https://rrdp.example.net/1775/delta.xml"; /> >>>> --> >>> >>> Good catch, thank you! >>> >>>> 4) <!-- [rfced] As this text would be added to RFC 8182, it would be odd >>>> to refer to itself. We updated the text to indicate "Section 3.4.3", >>>> where 3.4.3 links to Section 3.4.3 in RFC 8182. Please review and let us >>>> know if you have any concerns. (Note that the .txt will show as below, >>>> without a link.) >>>> >>>> Original: >>>> | ... The Relying Party >>>> | SHOULD then download and process the Snapshot File specified in >>>> | the downloaded Update Notification File as described in >>>> | Section 3.4.3 of [RFC8182] >>>> >>>> Current: >>>> | ... The Relying Party SHOULD >>>> | then download and process the Snapshot File specified in the >>>> | downloaded Update Notification File as described in Section 3.4.3. >>>> --> >>> >>> Yup, perfect. >>> >>>> 5) <!-- [rfced] Please review the sourcecode in Figures 1 and 3 as there >>>> are a >>>> few lines that exceed the 69-character limit and let us know how we may >>>> add line breaks. >>> >>> Figure 1 can be as follows: >>> >>> <sourcecode type="xml"> >>> <![CDATA[ >>> <notification xmlns="http://www.ripe.net/rpki/rrdp"; version="1" >>> session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec" serial="1774"> >>> <snapshot uri="https://rrdp.example.net/1774/snapshot.xml"; >>> hash= >>> "4b5f27b099737b8bf288a33796bfe825fb2014a69fd6aa99080380299952f2e2" >>> /> >>> <delta serial="1774" uri="https://rrdp.example.net/1774/delta.xml"; >>> hash= >>> "effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00" >>> /> >>> <delta serial="1773" uri="https://rrdp.example.net/1773/delta.xml"; >>> hash= >>> "731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a" >>> /> >>> <delta serial="1772 uri="https://rrdp.example.net/1772/delta.xml"; >>> hash= >>> "d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939" >>> /> >>> </notification> >>> ]]> >>> </sourcecode> >>> >>> Figure 3 can be as follows: >>> >>> <sourcecode type="xml"> >>> <![CDATA[ >>> <notification xmlns="http://www.ripe.net/rpki/rrdp"; version="1" >>> session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec" serial="1775"> >>> <snapshot uri="https://rrdp.example.net/1775/snapshot.xml"; >>> hash= >>> "cd430c386deacb04bda55301c2aa49f192b529989b739f412aea01c9a77e5389" >>> /> >>> <delta serial="1775" uri="https://rrdp.example.net/1775/delta.xml"; >>> hash= >>> "d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc" >>> /> >>> <delta serial="1774" uri="https://rrdp.example.net/1774/delta.xml"; >>> hash= >>> "10ca28480a584105a059f95df5ca8369142fd7c8069380f84ebe613b8b89f0d3" >>> /> >>> <delta serial="1773" uri="https://rrdp.example.net/1773/delta.xml"; >>> hash= >>> "731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a" >>> /> >>> </notification> >>> ]]> >>> </sourcecode> >>> >>>> Additionally, please consider whether the "type" attribute of any >>>> sourcecode >>>> element should be set. Note that it is also acceptable to leave the "type" >>>> attribute not set. >>>> >>>> The current list of preferred values for "type" is available at >>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >>>> If the current list does not contain an applicable type, feel free to >>>> suggest additions for consideration. >>>> --> >>> >>> The type "xml" can be set for both source code sections. >>> >>>> 6) <!-- [rfced] In the html and pdf outputs, the text enclosed in <em> >>>> is output in italics. In the txt output, the text enclosed in <em> >>>> appears with an underscore before and after. >>>> >>>> Please review carefully and let us know if the output is acceptable or >>>> if any updates are needed. <em> is used as follows (1x each): >>>> >>>> <em>differences</em> >>>> <em>can</em> >>>> <em>failed fetch</em> >>>> --> >>> >>> Yes, all good. >>> >>>> 7) <!-- [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. Updates of this nature >>>> typically >>>> result in more precise language, which is helpful for readers. >>>> >>>> Note that our script did not flag any words in particular, but this should >>>> still be reviewed as a best practice. >>>> --> >>> >>> Upon re-reading the document, I did not see any instances of potentially >>> problematic language. >>> >>>> Thank you. >>> >>> Thank you!!! >>> >>> Kind regards, >>> >>> Job >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
