Open Participation Principle regarding Remote Registration Fee
draft-ietf-shmoo-remote-fee-09

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-shmoo-remote-fee and RFC 9501, changed IESG state to RFC Published)

[Ballot comment]
Much thanks to the authors and WG for this document -- I know that it was difficult to get this completed and to this state.

[Ballot comment]
### Section 1, non-sequitur

"This increase can be explained by the ease with which new participants can join a meeting or only attend selected parts of the meeting agenda, and also by a less strongly perceived need to attend every meeting in person, due to either financial reasons or other circumstances."

The "due to" implies a causal connection that doesn't make sense to me; the final clause seems pretty unrelated to the previous parts of the sentence. Financial reasons might well relate to a less strong perceived *ability* to attend -- but "need"? Perhaps something like,

"This increase can be explained by the ease with which new participants can join a meeting or only attend selected parts of the meeting agenda, and also by a less strongly perceived need to attend every meeting in person. Financial reasons may also be a factor."

In my suggested rewrite I dropped "or other circumstances" because it doesn't add anything.

### Section 2, vagueness of restriction of use of personal information

"any personal information that is collected with respect to the use of the free remote participation option must be kept confidential"

Shouldn't it say confidential *from whom*, and what the allowed and disallowed uses are?

(I notice Éric Vyncke had a similar comment.)

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-shmoo-remote-fee-08

This must have been a very difficult to author document... So, congratulations to the authors, shepherd, and the SHMOO WG. The -08 has less hand-waving hence I am now balloting a NO OBJECTION.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Suresh Krishnan for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

Like Paul Wouters, I find that there is some confusions between 'free option' and 'fee waiver', e.g., the I-D could clearly mention that "fee waivers" is just one way to have a "free option".

## Section 2

`must be kept confidential.` is probably underspecified: could it be visible to the IETF secretariat ? to the IETF LLC ?

## Section 3

`If unlimited free remote participation is determined` by who ?

`assessment of eligibility` to what ?

## Authors' Addresses

It seems that Rich's address is missing.

[Ballot comment]
Note I find the document a little confusing about the free option vs the fee waiver. I feel saying “a free option must be available” would have to list it as an equal option in the list of options to select from but it is somewhat hidden behind the fee waiver option. This will at least feel to the participant requiring these that these are “exceptional” and not part of the regular choice process. I know this is a feature but the document text makes it sound like a bug.

[Ballot comment]
Re:

  With the move to fully online meetings in 2020 and 2021, however,
  there was no longer a distinction between remote and on-site
  participants for those meetings.  Since IETF meeting costs and other
  costs still had to be covered, a meeting fee was charged for remote
  participants, eliminating the free remote participation option at
  that time.

Is this factually correct?  Did the IESG/LLC have the option for remote fee waivers at the point that the Vancouver IETF meeting moved online at the last minute (if that is deemed to be an acceptable implementation policy)?  If not, then when was the fee-waiver option introduced for remote participation?

I still think that this document has ended up being longer than it needs to be, e.g., sections 3 and 4 don't feel that helpful, and hence they somewhat read like they are stating they they are not telling the LLC how to do their job and at the same time proscribing how the LLC should do their job.

Regards,
Rob

[Ballot comment]
# Internet AD comments for draft-ietf-shmoo-remote-fee-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3

* "costs considerations" -> "cost considerations"

* "in oder" -> "in order"

[Ballot comment]
Please see https://author-tools.ietf.org/iddiff?url1=draft-ietf-shmoo-remote-fee-05&url2=draft-ietf-shmoo-remote-fee-08&difftype=--html for a diff between this version and -05, which was the one the IESG reviewed previously and which went back to the WG.

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

The IANA Functions Operator had previously reviewed draft-ietf-shmoo-remote-fee-05, and has reviewed draft-ietf-shmoo-remote-fee-08, 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-08-18):

From: The IESG
To: IETF-Announce
CC: draft-ietf-shmoo-remote-fee@ietf.org, lars@eggert.org, manycouches@ietf.org, shmoo-chairs@ietf.org, suresh.krishnan@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Open Participation Principle regarding Remote Registration Fee) to Best Current Practice


The IESG has received a request from the Stay Home Meet Occasionally Online
WG (shmoo) to consider the following document: - 'Open Participation
Principle regarding Remote Registration Fee'
  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 2023-08-18. 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


  This document outlines a principle for open participation that
  extends the open process principle defined in RFC3935 by stating that
  there must be a free option for online participation to IETF meetings
  and, if possible, related IETF-hosted events over the Internet.




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



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The consensus on this draft reflects broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was some controversy about earlier versions of the draft that provided
meeting fee guidance for fully online meetings as well as meetings with physical
presence. The consensus on this part was particularly rough.

Update July 2023: The draft went through IESG evaluation and had several changes
based on feedback from the IESG members and the IETF LLC. The draft went through
another Working Group Last Call regarding these changes and there were no concerns
brought up.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not applicable. This document is connected to participation in IETF meetings and
does not define any protocols.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Not applicable.

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

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. Based on my review of the latest version of the document it is my opinion
that this draft is needed, clearly written, and ready to be progressed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Best Current Practice. The original intent of the working group was to publish
an informational guidance document. There were discussions of the document in
the WG which led to the current version which provides BCP level guidance. The
WG was rechartered to reflect this change in intended status of this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. I have confirmed with the authors that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78 and
BCP 79 have already been filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is an I-D nits warning about non-ASCII characters in the draft and lines
being too long. I have verified that this is because one of the authors has a
name that contains an umlaut.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA allocations required.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The consensus on this draft reflects broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was some controversy about earlier versions of the draft that provided
meeting fee guidance for fully online meetings as well as meetings with physical
presence. The consensus on this part was particularly rough.

Update July 2023: The draft went through IESG evaluation and had several changes
based on feedback from the IESG members and the IETF LLC. The draft went through
another Working Group Last Call regarding these changes and there were no concerns
brought up.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not applicable. This document is connected to participation in IETF meetings and
does not define any protocols.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Not applicable.

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

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. Based on my review of the latest version of the document it is my opinion
that this draft is needed, clearly written, and ready to be progressed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Best Current Practice. The original intent of the working group was to publish
an informational guidance document. There were discussions of the document in
the WG which led to the current version which provides BCP level guidance. The
WG was rechartered to reflect this change in intended status of this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. I have confirmed with the authors that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78 and
BCP 79 have already been filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is an I-D nits warning about non-ASCII characters in the draft and lines
being too long. I have verified that this is because one of the authors has a
name that contains an umlaut.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA allocations required.

[Ballot comment]
The proposed v2 text changes address my concern, so I'm changing this from Abstain to Yes.

I'd like to *sincerely* thank the authors and WG for all of their hard work on this document and topic; it's an important one.

Sending this back to the WG. The IESG ballot still doesn’t allow moving it forward, and the continued volume of discussion of this I-D leaves me unconvinced that the contents (still) have IETF consensus.

[Ballot comment]
Thank you for the work on this document. Many thanks to John Klensin for his in depth review: https://mailarchive.ietf.org/arch/msg/art/9Nv4gQqKizP8yIJH8qb07nTxQd4/.

Thank you for addressing my DISCUSS comments in v-06 - as I said, the line is hard to draw, but I think the additional text did help in removing ambiguity.

-- previous DISCUSS for archival (2023-02-02 for -05) ----

Thank you for the work on this document. Many thanks to John Klensin for his in depth review: https://mailarchive.ietf.org/arch/msg/art/9Nv4gQqKizP8yIJH8qb07nTxQd4/, and to the authors and others for replying to it.

I believe that there is value in publishing a high level principle document as a direction to LLC, even though I also understand that there is some intrinsic ambiguity with writing such a document. The line is hard to draw. I'm balloting DISCUSS to go over the points below, which I really believe are worth addressing. I tried to be as actionable as possible.

* The reference to "Observer" as is in the document does not add much, and rather makes it unclear as the role of "observer" is not explicitly defined (neither in this document nor on RFC 3935). I would have liked this document to also specify the observer role and that the free observer option should also be supported as much as possible, however I seem to understand it out of scope for this document (a shame really, since it is so close to the topic). I suggest to just remove "(in contrast to an "observer")" and hope that someone will find the energy to pick up the topic and bring it to shmoo.

* The document should give guidance to the LLC keep the identities of those who have have applied for fee waivers and any information that may be disclosed by those applications confidential. Mirja said "However, my assumption is that individual registration data (except the name in the participants list) is treated as confidential anyway" so then why not just state it in this document and make it explicit. In practice, I like John's suggestion of the following text or something of the sort be added:

    > "if someone applies for a fee waiver, the LLC is expected to collect the absolutely minimum amount of information required to allow..." (whatever it is they decide they need to allow) "and the community will be told what information is to be collected so that potential applicants can
made informed decisions"

* I understand that it was a conscious choice and that the sentence was discussed quite a bit, however I also think the following sentence in section 3 does not give any guidance to the LLC, and is in general just unclear:

      > If unlimited free remote participation is determined to adversely affect the number of paying participants or the cost of free participation emerges to be a signification factor, the LLC might implement additional measures to manage these costs.

I believe some clarification is sorely needed as to what additional measures are envisioned (I believe this was also one of Roman's points). Somewhere in the discussion, Mirja said: "But we didn’t want to rule out anything because if it’s a problem for the financial viability of the IETF, it really goes beyond the scope of this document to give explicit guidance."
It is strange to make a guidance document not give any guidance at all here...

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-shmoo-remote-fee-06
CC @jgscudder

## COMMENT

I'm never going to love this document, short of the adoption of Jason's suggestion, https://mailarchive.ietf.org/arch/msg/manycouches/sK9iGilqUdE7ZlkHZxQn4BOHPJQ which doesn't seem to be in the cards. However I'm not going to withhold a needed ballot to advance it on that basis, and the parts I found most problematic have been somewhat addressed in the latest revision, so I'm moving to NOOBJ. I do have some remaining comments, below. Some are new with 06 and some date back to 05.

### Section 2, vagueness of restriction of use of personal information (new)

"any personal information that is collected with respect to the use of the free remote participation option must be held confidential"

If it's necessary to provide this level of micromanagement at all (I would be happy for the sentence to be struck, and rely on the discretion of the LLC to do the right thing, as we do with other PII they collect), then shouldn't it say confidential *from whom*, and what the allowed and disallowed uses are? For example, may information be used to generate aggregate statistics, e.g. "X% of free participants were first-time, Y% were students"? There is a hint in Section 4 that some uses are OK, "Aggregated data on the number and percentage of free registrations used should be published, as this will permit analysis of the use and change in use over time of the free registration option without revealing personal information", but a maximalist reading of the Section 2 text would lead one to think that only the greatest amount of aggregation is permissible, i.e. only "X% of our registrations were free", nothing more.

(Also, nit, not "held confidential". Should be "kept confidential" or "held in confidence".)

### Section 3, reference to Padlipsky, "Perspective on the ARPANET reference model" (new)

"As defined in the RFC871".

That isn't the right reference. Probably you wanted RFC 8711? Mistaken ref recurs later in the paragraph.

### Section 4, wording (longstanding)

                                                              The fee
  payment structure is set the by the IETF LLC such that the viability
  of the IETF and the need of IETF participants to work productively
  within the IETF can be warranted.

I don’t think “warranted” is the word wanted here? In this context it means “justified”. Probably you meant something more like “supported” or “ensured”? Come to think of it, “viability” and “need” seem not to quite work together right either. Would it be right to also change “need” to “ability”, making it “... such that the viability of the IETF and the ability of IETF participants to work productively within the IETF can be ensured”?

(Also, nit: "set the by the" -> "set by the")

So, NEW:
                                                              The fee
  payment structure is set the by the IETF LLC such that the viability
  of the IETF and the ability of IETF participants to work productively
  within the IETF can be ensured.

## NITS

"signification factor" --> "significant factor" (unless you really did intend to use it as technical jargon, but if you did you probably need to go into much more detail to make clear your meaning)

Some other nits noted with related comments.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
(Revised to again ABSTAIN per the telechat discussion on Feb 2, 2023.  The document author said there was consensus to provide no clarifying guidance to the LLC beyond the current text, and that the principle needs to be framed as a “must”)

Robust remote participation mechanisms helped the IETF weather COVID; and had the additional benefit of bringing new participants to the IETF.  It should be ensured that this additional engagement is nurtured and sustained.

I have reservations on how this document is providing guidance and the framing the key principle.

==[ previous DISCUSS ]==
** Section 3.  This document is constraining the behavior of the LLC without explaining the latitude in which they can implement a solution.  Specifically, this text is ambiguous:

  If unlimited free remote participation is
  determined to adversely affect the number of paying participants or
  the cost of free participation emerges to be a signification factor,
  the LLC might implement additional measures to manage these costs.

What are the limits of these “additional measures” to contain costs?  Could it be up to reducing the free participation espoused in Section 2?
==[ end DISCUSS ]==

** Section 2.
  The principle this document states is simple: there must always be an
  option for free remote participation in any IETF meeting, regardless
  of whether the meeting has a physical presence. 

I concur with Rob Wilton’s assessment that this text would be better framed as “there _should_ always be an option …”.  My interest is in providing maximum operating flexibility in unusual circumstances.

** Section 3.  This section doesn’t appear to be actionable or introduction any new principles beyond stating a corollary of the principle in Section 2 which is that enabling free remote participation in the current business model is partially subsidized by other participants paying.

** Section 4.  Editorial clarity.
  This document does not provide specific requirements on when to use
  or not use the free option. 

This text creates some ambiguity.  It would benefit from being clearer on what “use” means.  Maybe:

This document does not provide specific requirements on when it is appropriate for an IETF community member to use or not use the free option to remotely attend a meeting.

[Ballot discuss]
** Section 3.  This document is providing additional requirements to the LLC without explaining the latitude in which they can implement a solution.  Specifically, this text is ambiguous:

  If unlimited free remote participation is
  determined to adversely affect the number of paying participants or
  the cost of free participation emerges to be a signification factor,
  the LLC might implement additional measures to manage these costs.

What are the limits of these “additional measures” to contain costs?  Could it be up to reducing the free participation espoused in Section 2?

[Ballot comment]
(Revised from ABSTAIN to DISCUSS; and adding support for the newly filed DISCUSS positions)

I support the DISCUSS positions of Robert Wilton and Francesca Palombini.

Robust remote participation mechanisms helped the IETF weather COVID; and had the additional benefit of bringing new participants to the IETF.  It should be ensured that this additional engagement is nurtured and sustained.

I have reservations on how this document is providing guidance and the framing the key principle.

** Section 2.
  The principle this document states is simple: there must always be an
  option for free remote participation in any IETF meeting, regardless
  of whether the meeting has a physical presence. 

I concur with Rob Wilton’s assessment that this text would be better framed as “there _should_ always be an option …”.  My interest is in providing maximum operating flexibility in unusual circumstances.

** Section 3.  This section doesn’t appear to be actionable or introduction any new principles beyond stating a corollary of the principle in Section 2 which is that enabling free remote participation in the current business model is partially subsidized by other participants paying.

** Section 4.  Editorial clarity.
  This document does not provide specific requirements on when to use
  or not use the free option. 

This text creates some ambiguity.  It would benefit from being clearer on what “use” means.  Maybe:

This document does not provide specific requirements on when it is appropriate for an IETF community member to use or not use the free option to remotely attend a meeting.

[Ballot discuss]
Thank you for the work on this document. Many thanks to John Klensin for his in depth review: https://mailarchive.ietf.org/arch/msg/art/9Nv4gQqKizP8yIJH8qb07nTxQd4/, and to the authors and others for replying to it.

I believe that there is value in publishing a high level principle document as a direction to LLC, even though I also understand that there is some intrinsic ambiguity with writing such a document. The line is hard to draw. I'm balloting DISCUSS to go over the points below, which I really believe are worth addressing. I tried to be as actionable as possible.

* The reference to "Observer" as is in the document does not add much, and rather makes it unclear as the role of "observer" is not explicitly defined (neither in this document nor on RFC 3935). I would have liked this document to also specify the observer role and that the free observer option should also be supported as much as possible, however I seem to understand it out of scope for this document (a shame really, since it is so close to the topic). I suggest to just remove "(in contrast to an "observer")" and hope that someone will find the energy to pick up the topic and bring it to shmoo.

* The document should give guidance to the LLC keep the identities of those who have have applied for fee waivers and any information that may be disclosed by those applications confidential. Mirja said "However, my assumption is that individual registration data (except the name in the participants list) is treated as confidential anyway" so then why not just state it in this document and make it explicit. In practice, I like John's suggestion of the following text or something of the sort be added:

    > "if someone applies for a fee waiver, the LLC is expected to collect the absolutely minimum amount of information required to allow..." (whatever it is they decide they need to allow) "and the community will be told what information is to be collected so that potential applicants can
made informed decisions"

* I understand that it was a conscious choice and that the sentence was discussed quite a bit, however I also think the following sentence in section 3 does not give any guidance to the LLC, and is in general just unclear:

      > If unlimited free remote participation is determined to adversely affect the number of paying participants or the cost of free participation emerges to be a signification factor, the LLC might implement additional measures to manage these costs.

I believe some clarification is sorely needed as to what additional measures are envisioned (I believe this was also one of Roman's points). Somewhere in the discussion, Mirja said: "But we didn’t want to rule out anything because if it’s a problem for the financial viability of the IETF, it really goes beyond the scope of this document to give explicit guidance."
It is strange to make a guidance document not give any guidance at all here...

[Ballot discuss]
Moving to discuss (rather than abstain) because I think that a discussion is probably needed anyway.

Fundamentally, I think that this document would be better to specify lower minimum requirements of what free access *must* be provided, and set out aspirational goals of what is desirable, but leave room for the LLC/IESG at the time to determine how those are best implemented based on current circumstances.  Specifically,

I entirely agree that anyone should be able to participate in the standards process without paying any fees.  I.e., I fully support this text:

  The principle this document states is simple: there must always be an
  option for free remote participation in any IETF meeting, regardless
  of whether the meeting has a physical presence.

Aspirationally, I agree that we should aim for remote participants to have the same remote access experience as for paid remote attendee, i.e., I am supportive of the current fee-waver process that we have today.  However, I don't agree with following text using must, because I just see it as constraining the IESG/LLC in a way that could be detrimental to the financial health of the IETF.

  Further, in order to fully remove barriers to participation, any free
  registration option must offer the same degree of interactivity and
  functionality available to paid remote attendees.

[Ballot comment]
Previous comment:

Perhaps a bit like Eric, I'm somewhat ambivalent on this draft.  I agree with the aspiration of always having free remote access, but I'm not sure whether we really need a RFC to mandate this (as opposed to a webpage documenting the current policy).

(1) p 3, sec 2.  Principle of Open Participation

  Further, in order to fully remove barriers to participation, any free
  registration option must offer the same degree of interactivity and
  functionality available to paid remote attendees.

I would strongly prefer that this is a 'should' rather than a 'must'.  Although, I don't perceive it as being that likely, is it not conceivable that the LLC might want to offer some extra enhanced remote service that they need to charge for (e.g., a slightly strawman example could be a telepresence robot), or perhaps paid live voice transcription services, where the cost of providing the service is shared between those participants making use of the service.

Regards,
Rob

[Ballot comment]
Firstly, thanks for the document, I imagine this could not have been easy to write and frame.

I've gone through the abstain ballots from other IESG members, and while I believe I understand the positions taken in those ballots, I take a slightly different view.  By in effect codifying the fact that there will be a guaranteed free remote participation option, this can actually encourage participation.  One of the questions I have been asked by individuals who have decided to use the remote participation fee waivers is - will this continue, because if not, whats the point of using it now, and suddenly finding myself in a position where I can't afford to attend in future.  While we can say we have no plans to remove those fee waivers, that's different from saying its codified.

It's on that basis that I fully support this - and yes, I am cognizant of the potential issues this creates with the finances, but as the document notes and as has been noted elsewhere, the incremental cost of remote participation has proven to be relatively inconsequential.

[Ballot comment]
At this point I’m not comfortable with the position the document stakes out, or doesn’t stake out. Probably this is clear from the email exchange. I think this could likely be addressed, but as the conversation has unfolded it seems we’re diverging rather than converging, so maybe it’s best for me to abstain.

[Ballot comment]
Robust remote participation mechanisms helped the IETF weather COVID; and had the additional benefit of bringing new participants to the IETF.  It should be ensured that this additional engagement is nurtured and sustained.

I have reservations on how this document is providing guidance and the framing the key principle.  My position roughly combines what Warren and Éric have also noted in their ABSTAIN ballots.  More specifically:

** Section 2.
  The principle this document states is simple: there must always be an
  option for free remote participation in any IETF meeting, regardless
  of whether the meeting has a physical presence. 

I concur with Rob Wilton’s assessment that this text would be better framed as “there _should_ always be an option …”.  My interest is in providing maximum operating flexibility in unusual circumstances.

** Section 3.  This section doesn’t appear to be actionable or introduction any new principles beyond stating a corollary of the principle in Section 2 which is that enabling free remote participation in the current business model is partially subsidized by other participants paying.  As an example of this ambiguity:

  If unlimited free remote participation is
  determined to adversely affect the number of paying participants or
  the cost of free participation emerges to be a signification factor,
  the LLC might implement additional measures to manage these costs.

What are the limits of these “additional measures” to contain costs?  Could it be up to reducing the free participation espoused in Section 2?

** Section 4.  Editorial clarity.
  This document does not provide specific requirements on when to use
  or not use the free option. 

This text creates some ambiguity.  It would benefit from being clearer on what “use” means.  Maybe:

This document does not provide specific requirements on when it is appropriate for an IETF community member to use or not use the free option to remotely attend a meeting.

[Ballot comment]
Like Eric, I am abstaining.

I believe that *all* IETF participation should be free - but then again I also believe that cookies should be larger, taxes should be abolished, cancer should be eradicated, everyone should have a fluffy kitten and those annoying blister packs that batteries come in should be required to have a pull tab.

Unfortunately I'm not in a position to make these decisions - apparently some of them are technically infeasible, some have funding issues, some of them have been delegated to other groups (like governments), and most worryingly of all, some people claim to prefer puppies.

We already have a principle that the IETF should be open to participation from all, and we already have an LLC and Executive Director to whom we've delegated annoying things like making sure that we can actually pay the bills. I believe that we should trust these groups to do their jobs, and that it is not appropriate for me to try teach them to suck eggs (https://en.wikipedia.org/wiki/Teaching_grandmother_to_suck_eggs)

Now, if y'all want to discuss the whole kitten and blister pack topics...

[Ballot comment]
Perhaps a bit like Eric, I'm somewhat ambivalent on this draft.  I agree with the aspiration of always having free remote access, but I'm not sure whether we really need a RFC to mandate this (as opposed to a webpage documenting the current policy).

(1) p 3, sec 2.  Principle of Open Participation

  Further, in order to fully remove barriers to participation, any free
  registration option must offer the same degree of interactivity and
  functionality available to paid remote attendees.

I would strongly prefer that this is a 'should' rather than a 'must'.  Although, I don't perceive it as being that likely, is it not conceivable that the LLC might want to offer some extra enhanced remote service that they need to charge for (e.g., a slightly strawman example could be a telepresence robot), or perhaps paid live voice transcription services, where the cost of providing the service is shared between those participants making use of the service.

Regards,
Rob

[Ballot comment]
This must have been a very difficult to author document... So, congratulations to the authors, shepherd, and the SHMOO WG.

But, I am ambivalent on this document: it is of course good will to offer a free access, but it is also a little 'hand waving' to the IETF LLC that must both avoid loss and offer free access. Hence my ABSTAIN ballot.

I am also puzzled by the first paragraph of section 2 ending with `about the registration fee structure for fully online meetings` while the document appears to be for hybrid and fully online meetings.

Regards

-éric

[Ballot comment]
Given the relationship with rfc3935, is the intent for this document to be part of BCP 95?  Please clearly indicate that intent.

[Ballot comment]
- Thanks for the discussion about my earlier DISCUSS point; as I noted in email I think the document would benefit from being made more explicit that the right to free access is not an unqualified one, but a (strong) aspiration.

- “The fee payment structure is set the by the IETF LLC such that the viability of the IETF and the need of IETF participants to work productively within the IETF can be warranted.”

I don’t think “warranted” is the word wanted here? In this context it means “justified”. Probably you meant something more like “supported” or “ensured”? Come to think of it, “viability” and “need” seem not to quite work together right either. Would it be right to also change “need” to “ability”, making it “... such that the viability of the IETF and the ability of IETF participants to work productively within the IETF can be ensured”?

[Ballot comment]
“The fee payment structure is set the by the IETF LLC such that the viability of the IETF and the need of IETF participants to work productively within the IETF can be warranted.”

I don’t think “warranted” is the word wanted here? In this context it means “justified”. Probably you meant something more like “supported” or “ensured”? Come to think of it, “viability” and “need” seem not to quite work together right either. Would it be right to also change “need” to “ability”, making it “... such that the viability of the IETF and the ability of IETF participants to work productively within the IETF can be ensured”?

[Ballot discuss]
There are several hints in the document that the authors intend that access to free registration should be unlimited, both in the sense of there being no limit to the number of such registrations, and in the sense of there being no qualification (such as means testing) required in order to register for free. However, the document is not explicit about this, and indeed there are also some hints in the opposite direction, like where section 3 mentions “applying for a fee waiver”. (Normally an application process implies an approval step, which implies criteria.)

If no-limits free is the intent, I think it’s important to be absolutely explicit about that, even to the point where it may feel redundant.

[Ballot comment]
“The fee payment structure is set the by the IETF LLC such that the viability of the IETF and the need of IETF participants to work productively within the IETF can be warranted.”

I don’t think “warranted” is the word wanted here? In this context it means “justified”. Probably you meant something more like “supported” or “ensured”?

[Ballot comment]
# Internet AD comments for draft-ietf-shmoo-remote-fee-05
CC @ekline

## Nits

### S1

* "impact on both," -> "impact on both" or even just "impact on" seeing
  as how the next sentence also starts with referencing "both"...

### S2

* "f they" -> "if they"

### S3

* "signification factor" -> "significant factor"?

### S4

* "simply lost of" -> "simply loss of"

Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: John Klensin. Sent review to list. Submission of review completed at an earlier date.

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

The IANA Functions Operator has reviewed draft-ietf-shmoo-remote-fee-05, 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-01-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-shmoo-remote-fee@ietf.org, lars@eggert.org, manycouches@ietf.org, shmoo-chairs@ietf.org, suresh.krishnan@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Open Participation Principle regarding Remote Registration Fee) to Best Current Practice


The IESG has received a request from the Stay Home Meet Occasionally Online
WG (shmoo) to consider the following document: - 'Open Participation
Principle regarding Remote Registration Fee'
  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 2023-01-23. 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


  This document outlines a principle for open participation that
  extends the open process principle defined in RFC3935 by stating that
  there must always be a free option for online participation to IETF
  meetings and, if possible, related IETF-hosted events over the
  Internet.




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



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The consensus on this draft reflects broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was some controversy about earlier versions of the draft that provided
meeting fee guidance for fully online meetings as well as meetings with physical
presence. The consensus on this part was particularly rough.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not applicable. This document is connected to participation in IETF meetings and
does not define any protocols.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Not applicable.

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

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. Based on my review of the latest version of the document it is my opinion
that this draft is needed, clearly written, and ready to be progressed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Best Current Practice. The original intent of the working group was to publish
an informational guidance document. There were discussions of the document in
the WG which led to the current version which provides BCP level guidance. The
WG was rechartered to reflect this change in intended status of this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. I have confirmed with the authors that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78 and
BCP 79 have already been filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is an I-D nits warning about non-ASCII characters in the draft and lines
being too long. I have verified that this is because one of the authors has a
name that contains an umlaut.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA allocations required.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The consensus on this draft reflects broad agreement from the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was some controversy about earlier versions of the draft that provided
meeting fee guidance for fully online meetings as well as meetings with physical
presence. The consensus on this part was particularly rough.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not applicable. This document is connected to participation in IETF meetings and
does not define any protocols.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Not applicable.

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

Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. Based on my review of the latest version of the document it is my opinion
that this draft is needed, clearly written, and ready to be progressed.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Not applicable.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Best Current Practice. The original intent of the working group was to publish
an informational guidance document. There were discussions of the document in
the WG which led to the current version which provides BCP level guidance. The
WG was rechartered to reflect this change in intended status of this document.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. I have confirmed with the authors that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78 and
BCP 79 have already been filed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is an I-D nits warning about non-ASCII characters in the draft and lines
being too long. I have verified that this is because one of the authors has a
name that contains an umlaut.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA allocations required.