Considerations for Cancellation of IETF Meetings
RFC 9137

Received changes through RFC Editor sync (created alias RFC 9137, changed abstract to 'The IETF ordinarily holds three in-person meetings per year to discuss issues and advance the Internet.  However, various events can make a planned in-person meeting infeasible.  This document provides criteria to aid the IETF Administration LLC (IETF LLC), the Internet Engineering Steering Group (IESG), and the Chair of the Internet Research Task Force (IRTF) in deciding to relocate, virtualize, postpone, or cancel an in-person IETF meeting.', changed pages to 7, changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2021-10-12, changed IESG state to RFC Published)

[Ballot comment]
I suggest the shepherd writeup should have been sent back for revision.  It answers the first three questions (What is the status, why is this the right status, is it shown on the front page?) with just "BCP".  Also, "N/A" is not an appropriate answer to question 7.

Given the capitalization in Section 3.1, it appears some terms were also imported from RFC 8718 (e.g., "Facility", which is formally defined there).  We might want to make it explicit that these definitions are imported.

[Ballot comment]
1. A small suggestion for the Abstract:

OLD:
  The IETF holds three in-person meetings per year to discuss and

NEW:
  The IETF ordinarily holds three in-person meetings per year to discuss and


2. I think this may have been raised already, but just in case:

  *  The number of critical support staff and contractors who can be at
      the venue.

Does this adequately capture the need for critical volunteers as well? I'm thinking in particular of the NOC.

3. I reviewed the Github Editor's copy (as of July 13 16:00 EDT or so) and noticed that the text "These remedies are listed in approximate declining order of preference" was added to the end of §4. That directly conflicts with version 5's "presented in no particular order". I like the text in v5 and don't particularly like the proposed edit.

4. Regarding

  The IETF SHOULD NOT reimburse registered attendees for unrecoverable
  travel expenses (airfare, hotel deposits, etc).

Has any consideration been given to adding some kind of text to the effect that attendees might choose to protect themselves against such losses with appropriate travel insurance? I appreciate that it would represent scope creep (it's not directly germane to "providing criteria for making this judgement") so I'm not bothered if this isn't adopted; however, I can see some benefits to including it.

5. Regarding

  *  Cancellation SHOULD result in a full refund to all participants.
      It MAY be prorated if some portion of the sessions completed
      without incident.

I presume this has been discussed to death, and it's understood this may result in the IETF eating sunk costs? (Similar applies to the rest of the bullets in the list.) I do see there's an escape clause for "extraordinary threats to the solvency of the organization".

6. Regarding

  This document introduces no new concerns for the security of internet

s/internet/Internet/. The NYT style is wrong, wrong, wrong on this one.

7. Is the Acknowledgements section empty deliberately?

[Ballot comment]
Thank you for this document. Some minor comments below.

Francesca

1. -----

  *  An economic crisis could sharply reduce resources available for
      travel.


FP: While the other examples seem clear and somewhat more easy to judge, this looks very vague to me: it might be better to explicitly state something on the sort of "... resource available for travel, leading to a much lower expected low attendance." This is still vague, but in my opinion gives a better idea of what to look for, and should be in line with later text about impact on attendance.

2. -----

Section 3.1

FP: As for the criteria, I was expecting to see something about reachability of the venue, especially because of this sentence:

  The LLC will collect information about the likely impact to in-person
  attendance of national travel advisories, national and corporate
  travel bans, quarantine requirements, etc. and report the results to

(travel ban) - I don't think that's covered by any of the other criteria.

3. -----

Section 4

FP: It seems that the subsection have a specific order - from most preferred to least preferred. It should be spelled out.

[Ballot comment]
Hi Martin,

Thanks for driving this document.

A couple of minor comments:

1. MUST consult with the community on the reason(s)

This is just a nit, but this could be read as having a discussion with the community about why the meeting cannot proceed as scheduled (E.g., analyzing why the hotel failed).  I presume that the intended consultation should be just what the IETF/LLC should do about it.

2. Consulting with the community on the form of the assessment report.

Although I have no objection to the LLC doing this, I don't really see this as something that must be consulted on.  Discussing the content seems fine, but needing to consult on what the report looks like feels like a step too far to me.

Regards,
Rob

[Ballot comment]
Thanks for the efforts put in this document and in the discussions.

I would suggest this - " This document provides criteria to aid the IETF Administration LLC
  (LLC) in deciding to postpone, move, or cancel an in-person IETF
  meeting." to be added in the abstract of this document to make the purpose more clear.
 
Then I agree with Ben's comment that his document seems also helping IESG and IRTF chair in the assessment (see section 3 ) hence wondering if that also should be clear in the purpose statement made in this document.

[Ballot comment]
Thank you to David Mandelberg for the SECDIR review

** Section 3.1.  Editorial. s/Internet Access/Internet access/

** Section 3.1.  Editorial.  Section 2 defined venue to be the facility and IETF hotel, so shouldn’t the text s/Facility and IETF Hotels/venue/?

** Section 4.  Improve readability

OLD
Ensure the available time and resources allow the alternative to
      be adequately prepared.

NEW
Ensure sufficient time and resources to allow an alternative to
      be adequately prepared.

[Ballot comment]
(1) §3.1:

  The LLC SHOULD cancel a meeting if it judges a meeting to be
  logistically impossible or inconsistent with its fiduciary
  responsibilities.

s/LLC SHOULD cancel a meeting/LLC SHOULD cancel an in-person meeting and explore potential remedies

Given the possible remedies, it seems that logistic issues (for example) may be addressed by virtualizing or postponement.  IOW, the in-person part of the meeting may be canceled.  I feel that I may be missing some additional context...


(2) §3.2: The first paragraph mentions both the IESG and IRTF Chair, but the others only mention the IESG.  Is this an oversight (or maybe shorthand), or an indication that the assessment is driven only by the feasibility of an IETF meeting?


(3) §3.2: It seems to me that (similar to §3.1), there should be text indicating when the IESG should cancel the in-person meeting.  Something like this:

  The IESG SHOULD cancel the in-person meeting if the assessment
  indicates that attendance won't be high enough to be of benefit.


(4) If the meeting is virtualized, then no one really is remote -- everyone is online/virtual. 

§4.2: s/fully remote/fully online 

§4.4: s/even attend remotely/even attend online

§5: s/meeting becomes remote/meeting is virtualized

§5: s/for a remote meeting/for an online meeting

§5: s/attend a remote meeting/attend an online meeting


(5) §4.3: Is there a reason to not use normative language in this sentence:

  The new end date of a meeting must be at least 30 days before the
  beginning of the following IETF meeting, and a meeting must begin
  no earlier than 1 month after the postponement announcement.

[Ballot comment]
Thank you, Martin, for the work put into this document.

Please find below some non-blocking COMMENT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
"to discuss and understand issues." this looks not very positive for the IETF if the community is only about "issues" and not about "advancing the Internet"...

-- Section 3 --
"if the projected attendance is sufficient" while attendance is a big part of the decision, it is probably not the only one (I can imagine other conditions to have a real "live" meeting)

-- Section 3.2 --
I was about to DISCUSS the point about "projected attendance is high enough" because it is not only about sheer number of attendees but also about diversity, e.g., IETF-112 with only EU attendees will not be very fruitful.

-- Section 5 --
The last bullet uses "nation" but there may be more granular level at the attendee's residency (state, province, ...).

[Ballot comment]
I made a pull request with a few editorial suggestions at
https://github.com/martinduke/draft-ietf-shmoo-cancel-meeting/pull/7

It is perhaps interesting to note that we allow corporate travel
bans/restrictions to be used as a factor in cancelling a meeting (if
only by virtue of assessing how will be able to be present physically)
but specifically do not allow using them as a factor in who to offer
refunds to.  This doesn't seem inherently problematic, but is the type
of "edge case" that a security reviewer gravitates towards...

Section 1

  This document provides criteria to aid the IETF Administration LLC
  (LLC) in deciding to postpone, move, or cancel an in-person IETF
  meeting.

It seems like there is also some guidance to the IESG and IRTF chair in
here (and the authority to cancel may not lie solely with the LLC, as
well).

Section 3.1

  In non-emergency situations, if the LLC determines the scheduled
  meeting clearly cannot proceed (e.g., the venue has permanently
  closed), then it MUST consult with the community on the reason(s) and
  its proposed remedy.  [...]

Just to confirm: these are the reason(s) why the meeting "clearly cannot
proceed"?  I would hope that the need for cancellation is sufficiently
clear that nothing comes out of such a consultation, but don't object to
the requirement.

  The LLC will collect information about the likely impact to in-person
  attendance of national travel advisories, national and corporate
  travel bans, quarantine requirements, etc. and report the results to
  the IESG.

The shepherd writeup notes that there was some controversy about the
inclusion in earlier versions of the document regarding the use of
governmental travel advisories as a cancellation criterion.  Since this
usage is just as part of determining likely attendance, it seems like it
should not suffer from the same controversy, but I just wanted to
confirm that that is the case.

  In the event of considerations this document does not foresee, the
  LLC should protect the health and safety of attendees and staff, as
  well as the fiscal health of the organization, with approval from the
  IESG and a plan to seek a later update of this document.

That almost sounds like the LLC would be driving the document update,
which does not match with my understanding of the LLC's remit.

Section 4.1

  In particular, the LLC SHOULD strive to meet the criteria in
  [RFC8718] and [RFC8719].

"strive to" is already hedging language, so the weakness of "SHOULD" may
not be needed.

Section 5

  *  When a meeting becomes remote, the LLC MUST refund registered
      attendees the difference between their paid registration fee and
      the equivalent fee for a remote meeting.  [...]

[just noting that this is a "MUST refund", not the "offer a refund [that
does not have to be accepted]" phrasing we use elsewhere.  This seems
fine to me, but the inconsistency seemed worth confirming.]

NITS

Section 1

  Various major events may affect the suitability of a scheduled in-
  person IETF meeting, though for some this may not be immediately
  obvious.  For example:

Some [of these] events or some people?

Section 3.1

  These criteria, some of which are derived from Section 3 of
  [RFC8718], apply to venues that are re-evaluated due to an emergency:

The items that follow don't seem to all have a consistent grammatical
structure, so the list overall is a bit jarring.  E.g., the first one
seems like something that can be tested ("do the local guidelines allow
this") but the second is a straight-up requirement ("MUST be possible").
We might want to tweak some of the items' phrasing and/or add some
introductory text about how the criteria are to be applied.

Section 4.3

  Although it is more disruptive to the schedules of participants, the
  next best option is to delay a meeting until a specific date, at the
  same venue, at which conditions are expected to improve.  The new end
  date of a meeting must be at least 30 days before the beginning of
  the following IETF meeting, and a meeting must begin no earlier than
  1 month after the postponement announcement.

Is the distinction between 30 days and 1 month so critical that we need
to use different units in the same sentence?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-shmoo-cancel-meeting-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-24):

From: The IESG
To: IETF-Announce
CC: amelia@centr.org, draft-ietf-shmoo-cancel-meeting@ietf.org, lars@eggert.org, manycouches@ietf.org, shmoo-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Considerations for Cancellation of IETF Meetings) to Best Current Practice


The IESG has received a request from the Stay Home Meet Only Online WG
(shmoo) to consider the following document: - 'Considerations for
Cancellation of IETF Meetings'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The IETF holds three in-person meetings per year to discuss and
  understand issues.  However, various emergencies can make a planned
  in-person meeting infeasible.  This document provides criteria for
  making this judgment.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-shmoo-cancel-meeting/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  The IETF holds three in-person meetings per year to discuss and understand issues.  However, various emergencies can make a planned
  in-person meeting infeasible.  The document contains recommendations for the LLC to apply when cancelling or postponing meetings under different conditions.

Working Group Summary:

Early in the process, the inclusion of governmental travel advisories generated some controversy but they were later removed from the text.

Document Quality:

The document has been thoroughly reviewed by several participants in the working group and has been discussed multiple times in the virtual meetings.

Personnel:

Amelia Andersdotter is Document Shepherd. Lars Eggert is Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The latest version of the document has been reviewed with respect to e-mailing list comments and WGLC nits and comments from the drafting process.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

It would be if "IETF Administration LLC (LLC)" in section 3 should read as "Internet Engineering Task Force Administration Limited Liability Company (LLC)". In the same paragraph, IRTF is also not expanded.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  The IETF holds three in-person meetings per year to discuss and understand issues.  However, various emergencies can make a planned
  in-person meeting infeasible.  The document contains recommendations for the LLC to apply when cancelling or postponing meetings under different conditions.

Working Group Summary:

Early in the process, the inclusion of governmental travel advisories generated some controversy but they were later removed from the text.

Document Quality:

The document has been thoroughly reviewed by several participants in the working group and has been discussed multiple times in the virtual meetings.

Personnel:

Amelia Andersdotter is Document Shepherd. Lars Eggert is Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The latest version of the document has been reviewed with respect to e-mailing list comments and WGLC nits and comments from the drafting process.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

It would be if "IETF Administration LLC (LLC)" in section 3 should read as "Internet Engineering Task Force Administration Limited Liability Company (LLC)". In the same paragraph, IRTF is also not expanded.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The document contains recommendations for the LLC to apply when cancelling or postponing meetings under different conditions.

Working Group Summary:

Early in the process, governmental travel advisories were controversial but were later removed from the text.

Document Quality:

It may be expected that the LLC and IESG sticks to recommendations on time-lines, relocation planning, etc. contained in the document.

Personnel:

Amelia Andersdotter is Document Shepherd. Lars Eggert is Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The latest version of the document has been reviewed with respect to e-mailing list comments and WGLC nits and comments from the drafting process.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

N/A.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

N/A.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

It would be if "IETF Administration LLC (LLC)" in section 3 should read as "Internet Engineering Task Force Administration Limited Liability Company (LLC)". In the same paragraph, IRTF is also not expanded.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.