![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Use of any identifier outside the example space may cause real harm to the owner, where that harm may range from serious harm (technical and/or financial) to mild embarrassment. If anyone wants to use an identifier outside the example space, then to protect both the owner of the identifier and the IETF, the author really needs to provide the IETF with evidence of written authorization to use it for this purpose. In the case of this draft, have the owners of the identifiers been contacted by the author, and do they agree to this use?You are aware that the same examples have been in a published RFC for over seven years?
Because this point keeps getting overlooked, it's worth saying "... a published STANDARDS-TRACK RFC ...".
But, whatever. My suggestion is to stop posting in this thread and let the IESG do what they need to do, now that they have an appeal in hand. We're just distracting them and inflaming the community at this point.
They are actively discussing the topic, not just the appeal. From the most recent IESG telechat minutes:
6.2 IESG Statement on BCP 32 (Russ Housley) The management issue was discussed. Action Item: Magnus Westerlund to draft an IESG Statement on BCP 32. (taken from https://datatracker.ietf.org/iesg/telechat/391/)Jari has split off a new thread on "Measuring IETF and IESG trends" - obviously, that's not the kind of "posting in this thread" I'm hoping to discourage.
Thanks,Spencer
_______________________________________________ IETF mailing list IETF at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.