Hi Jay,
We have updated our files based on your feedback (note that "BCP 226" will be
added during the publication process). We have an additional question.
1) Regarding the following text, would option A or B perhaps be better than
using ‘hiring’ or ‘renting’?
Original:
The IASA has responded to this feedback by adopting
a new practice of hiring in hallway seating whenever
that provided by the venue is insufficient.
Perhaps:
A) The IASA has responded to this feedback by adopting
a new practice of supplying in hallway seating whenever
that provided by the venue is insufficient.
or
B) The IASA has responded to this feedback by adopting
a new practice of making in hallway seating available
whenever that provided by the venue is insufficient.
—FILES—
The updated XML file is here:
https://www.rfc-editor.org/authors/rfc9712.xml
The updated output files are here:
https://www.rfc-editor.org/authors/rfc9712.txt
https://www.rfc-editor.org/authors/rfc9712.pdf
https://www.rfc-editor.org/authors/rfc9712.html
This diff file shows all changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9712-auth48diff.html
This diff file shows all changes made to date:
https://www.rfc-editor.org/authors/rfc9712-diff.html
Note that it may be necessary for you to refresh your browser to view the most
recent version. Please review the document carefully to ensure satisfaction as
we do not make changes once it has been published as an RFC.
Please contact us with any further updates or with your approval of the
document in its current form. We will await approvals from each author prior
to moving forward in the publication process.
For the AUTH48 status of this document, please see:
https://www.rfc-editor.org/auth48/rfc9712
Thank you,
RFC Editor/kc
> On Jan 9, 2025, at 3:26 PM, Jay Daley via auth48archive
> <auth48archive@rfc-editor.org> wrote:
>
> Hi Karen
>
> Sorry for the delay. Notes below:
>
>> On 24 Dec 2024, at 15:13, rfc-edi...@rfc-editor.org wrote:
>>
>> Authors,
>>
>> While reviewing this document during AUTH48, please resolve (as necessary)
>> the following questions, which are also in the XML file.
>>
>> 1) <!--[rfced] This document will be assigned a new BCP number. Please
>> let us know if this is not correct (i.e., it should be part of
>> an existing BCP).
>>
>> See the complete list of BCPs here:
>> https://www.rfc-editor.org/bcps
>> -->
>
> I believe this should be part of BCP 226 as this updates two existing
> documents in that BCP.
>
>> 2) <!-- [rfced] FYI: The "sortRefs" and "symRefs" elements
>> were absent in the submitted XML file, so we have
>> added them accordingly.
>> -->
>
> All good.
>
>> 3) <!--[rfced] The short title that spans the top of the PDF file was
>> absent. We were able to fit the full title, so we included it. If
>> any further updates are desired, please let us know.
>>
>> Current (in PDF file):
>> IETF Meeting Venue Requirements Review
>> -->
>
> All good.
>
>>
>>
>> 4) <!-- [rfced] Please insert any keywords (beyond those that appear in
>> the title) for use on https://www.rfc-editor.org/search. -->
>
> IETF region
> Exploratory meeting
>
>>
>>
>> 5) <!--[rfced] Is this document "proposing" or "providing" updates to
>> RFCs 8718 and 8719? May we update the Abstract's lead-in sentence
>> from "this document proposes updates" to "this document was
>> developed to update" as shown below for clarity?
>>
>> Original:
>> Following a review of the IETF meeting venue requirements, this
>> document proposes updates to RFC 8718 "IETF Plenary Meeting Venue
>> Selection Process", clarifies how the IETF Administration Support
>> Activity (IASA) should interpret some elements of RFC 8718, and
>> proposes a replacement exploratory meeting process, thereby updating
>> RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF".
>>
>> Perhaps:
>> Following a review of the IETF meeting venue requirements, this
>> document was developed to update "IETF Plenary Meeting Venue
>> Selection Process" (RFC 8718), clarify how the IETF Administration
>> Support Activity (IASA) should interpret some elements of RFC 8718,
>> and specify a replacement exploratory meeting process, thereby
>> updating "High-Level Guidance for the Meeting Policy of the IETF"
>> (RFC 8719).
>> -->
>
> I prefer more direct text:
>
>> Following a review of the IETF meeting venue requirements, this
>> document updates RFC 8718 "IETF Plenary Meeting Venue
>> Selection Process", clarifies how the IETF Administration Support
>> Activity (IASA) should interpret some elements of RFC 8718, and
>> specifies a replacement exploratory meeting process, thereby updating
>> RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF".
>
>>
>>
>> 6) <!--[rfced] Is "informed" the intended word here or would
>> "communicated" be clearer?
>>
>> Original:
>> The IASA has reviewed the venue selection in light of these
>> developments, primarily informed by the staff who work on venue
>> selection, and has identified a number of issues to be addressed
>> by a combination of updates to those RFCs and clarifications of
>> interpretation.
>>
>> Perhaps:
>> The IASA has reviewed the venue selection in light of these
>> developments, which were primarily communicated by the staff who
>> work on venue selection, and has identified a number of issues
>> to be addressed by a combination of updates to those RFCs and
>> clarifications of interpretation.
>> -->
>
> I prefer to leave as is - "informed by" seems a well known term, but maybe
> I’ve misunderstood the issue?
>
>>
>>
>> 7) <!--[rfced] The text in Section 2 works off of the section title. To
>> avoid this and the use of a colon in the section title, may
>> we insert a lead-in sentence as shown below?
>>
>> Original:
>> 2. Summary of changes to [RFC8718] and [RFC8719]:
>>
>> 1. Updates the Meeting (Rotation) Policy of [RFC8719] with
>> a new process for the selection of exploratory meetings...
>>
>> Perhaps:
>> 2. Summary of Changes to RFCs 8718 and 8719
>>
>> This document makes the following changes to [RFC8718] and [RFC8719]:
>>
>> 1. Updates the Meeting (Rotation) Policy specified in [RFC8719] with
>> a new process for the selection of exploratory meetings...
>> -->
>
> Yes.
>
>>
>>
>> 8) <!-- [rfced] FYI: We updated the quoted text from RFC 8718 to exactly
>> match (i.e., we updated "one-third of the projected attendees" to
>> "one-third or more of projected meeting attendees") as shown
>> below.
>>
>> Original:
>> 3. Updates the room block requirement of [RFC8718] from "one-third of the
>> projected attendees" to a more flexible "sufficient rooms to meet the
>> expected demand".
>>
>> Current:
>> 3. Updates the room block requirement specified in [RFC8718] from
>> "one-third or more of projected meeting attendees" to a more
>> flexible "sufficient rooms to meet the expected demand".
>> -->
>
> All good.
>
>>
>> 9) <!-- [rfced] FYI: We removed repeated text that appeared to be a typo (the
>> text was the same as what appears in the next <blockquote> after "and"):
>>
>> Original:
>> [...] the meeting policy (let's call this the "1-1-1" policy) is that
>> meetings
>> should rotate between North America, Europe, and Asia. the 1-1-1-* meeting
>> policy is a slightly modified version of the aforementioned 1-1-1 meeting
>> policy that allows for additional flexibility in the form of an exploratory
>> meeting (denoted with an "*").
>>
>> Current:
>> [...] the meeting policy (let's call this the "1-1-1" policy) is that
>> meetings
>> should rotate between North America, Europe, and Asia.
>> -->
>
> Agreed,
>
>> 10) <!--[rfced] There are two instances of "to accommodate us". Is it okay
>> to refer to "us", or would it be clearer (or more formal) to say
>> "to accommodate the IETF meeting requirements" as shown below?
>>
>> Original:
>> * There are a limited number of hotels (and therefore cities)
>> with large enough meeting space and sufficient rooms to
>> accommodate us.
>>
>> While a "one-roof" venue is preferred, there are a limited number of
>> hotels (and therefore cities) with large enough meeting space and
>> sufficient rooms to accommodate us.
>>
>> Perhaps:
>> * There are a limited number of hotels (and therefore cities)
>> with large enough meeting space and sufficient rooms to
>> accommodate the IETF meeting requirements.
>>
>> While a "one-roof" venue is preferred, there are a limited number of
>> hotels (and therefore cities) with large enough meeting space and
>> sufficient rooms to accommodate the IETF meeting requirements.
>> -->
>
> First, I think we can just remove the clause "to accommodate us" and leave
> the sentence finishing at "sufficient rooms". Second, the second occurrence
> is an unnecessary word-for-word repetition and so that whole sentence can be
> removed, leaving the paragraph starting with "To meet in cities …"
>
>>
>>
>> 11) <!-- [rfced] FYI: RFC 8718 states "one-third or more of projected
>> meeting attendees" rather than "one-third of the projected
>> attendees", so we have updated the text accordingly.
>>
>> Original:
>> To address this, this document updates Section 3.2.4 of [RFC8718] to
>> replace the requirement for the total room block in the IETF Hotels
>> from "one-third of the projected attendees" to a more flexible
>> "sufficient rooms to meet the expected demand".
>>
>> Current:
>> To address this issue, this document updates Section 3.2.4 of [RFC8718]
>> by replacing the total room block requirement for the IETF Hotels from
>> "one-third or more of projected attendees" to a more flexible
>> "sufficient rooms to meet the expected demand".
>> -->
>
> Agreed.
>
>> 12) <!--[rfced] Can "hiring" be replaced with "renting" or "providing" for
>> clarity as shown below?
>>
>> Original:
>> The IASA has responded to this feedback by adopting
>> a new practice of hiring in hallway seating whenever
>> that provided by the venue is insufficient.
>>
>> Perhaps:
>> The IASA has responded to this feedback by adopting
>> a new practice of renting in-hallway seating whenever
>> that provided by the venue is insufficient.
>> -->
>
> The intent here is to explain that we bring in the in-hallway seating from
> third parties outside of the venue so yes the change works, but if I could
> think of a better word that does not suggest we rent it from the venue, then
> that would be better, But I can’t.
>
>> 13) <!-- [rfced] FYI: We updated the following text to make the sections
>> and RFC being referenced clearer:
>>
>> Original:
>> To address this, is updated as follows: [RFC8718]
>>
>> 1. Section 3.2.2 is updated so that the bullet on ad-hoc meeting
>> space now reads:
>>
>> There are sufficient, easily accessible places within the
>> Facility for people to hold ad hoc conversations and group
>> discussions.
>>
>> 2. Section 3.2.4 is updated so that the bullet on the lounge now
>> reads:
>>
>> There are sufficient places within the Facility suitable for
>> people to work online on their own devices.
>>
>> Current:
>> To address this, [RFC8718] is updated as follows:
>>
>> 1. Section 3.2.2 of [RFC8718] is updated so that the entry on
>> ad hoc meeting space (first bullet) now reads:
>>
>> | There are sufficient, easily accessible places within the
>> | Facility for people to hold ad hoc conversations and group
>> | discussions.
>>
>> 2. Section 3.2.4 of [RFC8718] is updated so that the entry on
>> the lounge (sixth bullet) now reads:
>>
>> | There are sufficient places within the Facility suitable for
>> | people to work online on their own devices.
>> -->
>
> Works for me.
>
>> 14) <!--[rfced] Are these contributors considered coauthors for their
>> contributions, or should the Contributors section perhaps be
>> retitled "Acknowledgements" and the text be updated as shown
>> below? Please let us know your preference.
>>
>> Original:
>> Contributors
>>
>> Thanks to all of the contributors: Laura Nugent, Stephanie McCammon,
>> Alexa Morris, Greg Wood, Lars Eggert Eggert and Jason Livingood.
>>
>> Perhaps:
>> Acknowledgements
>>
>> Thanks to the following people for their contributions to
>> this document: Laura Nugent, Stephanie McCammon, Alexa Morris,
>> Greg Wood, Lars Eggert Eggert, and Jason Livingood.
>> -->
>
> They are not co-authors so if you think Acknowledgements is more in line with
> the series standards then yes I’m happy with that.
>
>>
>>
>> 15) <!-- [rfced] Terminology
>>
>> a) Throughout the text, the following terminology appears to be used
>> inconsistently. Please review these occurrences and let us know if/how they
>> may be made consistent.
>
> Wherever possible, we want to follow the format in RFC 8718/8719, which I
> believe is as follows:
>
>>
>> Lounge vs. lounge
>> (Note: lowercase in RFC 8718)
>
> lounge
>
>>
>> Meeting (Rotation) Policy vs. meeting rotation policy
>> (Note: appears as "meeting policy" in RFC 8719. Perhaps use
>> "meeting (rotation) policy" or "meeting rotation policy"
>> for consistency in Sections 2 and 3.1.)
>
> meeting (rotation) policy.
>
>>
>> One Roof vs. one roof
>> (Note: uppercase in RFC 8718.)
>
> One Roof
>
>>
>> Overflow Hotels vs. overflow hotels
>> (Note: uppercase in RFC 8718.)
>
> Overflow Hotels
>
>>
>> Terminal Room
>> (Note: lowercase in RFC 8718 and other RFCs.)
>
> terminal room
>
>>
>> b) Should one instance of "facility" perhaps be "Facility" in Section 4.1.2?
>>
>> Original:
>> * Group discussions can more naturally move from the facility to
>> the hotel.
>>
>> Perhaps:
>> * Group discussions can move more naturally from the facility to
>> the hotel.
>> -->
>
> Yes.
>
>> 16) <!-- [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.
>> -->
>
> That was considered throughout the authoring process.
>
> Thanks!
>
> Jay
>
>>
>>
>> Thank you.
>>
>> RFC Editor/kc
>>
>>
>> On Dec 23, 2024, at 6:11 PM, rfc-edi...@rfc-editor.org wrote:
>>
>> *****IMPORTANT*****
>>
>> Updated 2024/12/23
>>
>> 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
>>
>> * rfc-edi...@rfc-editor.org (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).
>>
>> * auth48archive@rfc-editor.org, 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,
>> auth48archive@rfc-editor.org 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/rfc9712.xml
>> https://www.rfc-editor.org/authors/rfc9712.html
>> https://www.rfc-editor.org/authors/rfc9712.pdf
>> https://www.rfc-editor.org/authors/rfc9712.txt
>>
>> Diff file of the text:
>> https://www.rfc-editor.org/authors/rfc9712-diff.html
>> https://www.rfc-editor.org/authors/rfc9712-rfcdiff.html (side by side)
>>
>> Diff of the XML:
>> https://www.rfc-editor.org/authors/rfc9712-xmldiff1.html
>>
>>
>> Tracking progress
>> -----------------
>>
>> The details of the AUTH48 status of your document are here:
>> https://www.rfc-editor.org/auth48/rfc9712
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC9712 (draft-daley-gendispatch-venue-requirements-03)
>>
>> Title : IETF Meeting Venue Requirements Review
>> Author(s) : J. Daley, S. Turner
>> WG Chair(s) :
>> Area Director(s) :
>>
>>
>>
>
> --
> Jay Daley
> IETF Executive Director
> exec-direc...@ietf.org
>
> --
> auth48archive mailing list -- auth48archive@rfc-editor.org
> To unsubscribe send an email to auth48archive-le...@rfc-editor.org
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
