mirjak-patch-26 comments

[gregbo]

draft-ietf-shmoo-remote-fee.md:

Acknowledgments section:

Thanks to everybody involved in the shmoo working group discussion, esepcially Brian Carpenter, Jason Livingood, [...]

s/esepcially/especially/

Considerations on Use and Misuse of a Free Participation Option section:

Since some participants may be self-funded, the first two sentences of the second paragraph could be rewritten as:

It is expected that participants who have (or have access to) the financial means to use the paid regular registration option will do so. Paying a registration fee is a way to support the IETF.

Also, IMO, the third sentence of the second paragraph isn't needed, and could be misconstrued as encouragement of late payments.

CONTRIBUTING.md:

The boilerplate information was never updated.

I can submit a PR if you wish.

[mirjak]

Thanks for your review Greg!

I pushed the typo directly and should be fixed now. Thanks!

Regarding the sentence on financial support. I think the question if self-funded people are expected to pay or not was one of the points that we never fully resolved. I think it very much depends on the exactly circumstances. The current sentence is what we converged to and therefore I would prefer to not touch it again...

Regarding encouraging late registrations: yes, that's fine. Why do you think that is a problem?

I updated the CONTRIBUTING.md (even though it kind of late now). Thanks!

Feel free to submit a PR next time!

[gregbo]

I'm concerned that the third sentence ("For example, a higher late payment charge can be used ...") could be misinterpreted as a justification for late payments (higher-rate payments made after the discount deadlines pass) because they would increase IETF revenues. Does this seem like a reasonable concern?

[mirjak]

And I saying that is not a misinterpretation. If people want to do that, that's only positive for the IETF (as we will have more revenue) and it does impact the IETF negative.

[gregbo]

To clarify, what I mean by misinterpretation is that the reader of the draft may reach an unintended conclusion that the IETF justifies remote fee registration at the highest rate option offered because it would increase revenue. I wasn't suggesting that you or any of the other authors had misinterpreted something. I hope that is more clear.

On the other hand, if it is the intention of the IETF to increase revenues in this manner, to me it seems to go against the spirit (if not the letter) of the first sentence in the second paragraph of the Financial Impact section ("It is not in scope for this document to make suggestions ...").

Anyway, I came up with some additional (editorial) issues that I will submit a PR for when I have more time. Some of them could be corrected by the RFC Editor. However, others may warrant discussion, such as modifying the following sentence in the Principle of Open Participation section:

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

to:

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

because not having the free remote participation option would be in violation of RFC3935.

[mirjak]

I think it is actually not wrong to say that we have multiple registration stages in oder to increase "revenue". however, of course not that we don't do that for increasing our profit but finance the whole org. However, I don't think the document is proposing or specifying this; it just comments on the option to use this path to increase your finical contribution. Thanks for bring this up but I don't see a problem with the current statement.

We decided to not use RFC2119 language in this document. But even without that is "binding". Using normative language doesn't change the content, it only a tool to make requirements more clear which is most useful for protocol specs (can also be useful for other docs but we didn't think it's needed here for this one thing).

[mirjak]

Thanks for your input. I will close this issue now as we are submitting the new (and hopefully final) version.