Re: Question regarding RFC 7725

[Patrick McManus <[e-mail]>]

hi Curt,

On a material level, I disagree with your comment. The obvious use case is
for a client that desires to still access the resource - as the text says.
This is an important consideration for understanding 451 whether or not you
are trying to circumvent it.

I hope I can help with some of the process mystery here:

>From the Tao of the IETF:  Once an RFC is published it is never revised. If
the specification described changes, the standard will be republished in
another RFC that obsoletes the first.

In practice this means if you would like to materially change an existing
RFC you need to write a new document. You would start with an
Internet-Draft. Anybody can write and publish an Internet Draft without
consensus or permission. You don't even have to start from scratch, you can
simply say "this document modifies 7725 in the following way.. blah blah
blah" and mark it "updates 7725".

That's the easy part :) The harder part is that you need to find a forum
for the consideration of your work. That could be an existing WG, it could
be a new WG created for just this purpose (a practice that is becoming more
popular) or it could even be sponsored by an AD directly without a WG if it
were not controversial at all. (I would not expect your suggestion would be
AD sponsored, but hey - I'm not an AD, what do I know?)

At that point you give up change control of your draft. The WG changes it
until it reaches rough consensus (or abandons it if that can't be reached)
and the IESG makes the final determination on whether or not it should be
published.

That's the schoolhouse rock version of how a comment becomes an RFC - its
necessarily incomplete but I hope it helps you understand what steps would
lie ahead. The first step is an individual internet draft. Thanks for
coming to the IETF.

-Patrick






On Fri, Oct 5, 2018 at 5:45 PM Curt Self <[e-mail]> wrote:

> I wanted to provide some feedback about the wording in this RFC. I
> submitted an Errata, but was told that the change I suggested was Material
> - not Editorial. I have never worked with the RFC platform, so I apologize
> for going about it incorrectly. I also realize that the RFC has been
> reviewed and voted on already. Regardless, here is my feedback.
>
> In Section 3, the last sentence (below) should be removed.
> Note that in many cases clients can still access the denied resource
> by using technical countermeasures such as a VPN or the Tor network.
>
> I understand that the status code itself is kind of a joke (Fahrenheit
> 451), but the sentence above seems to have no place in a technical
> document. It provides no insight into use cases for either a client or
> implementing software. When reading other RFCs I have not come across
> sentences like that one, and it really stands out.
>
> I hope that feedback on Material change is welcome.
>
> Thank you,
> Curt Self
>
>
>