[rfc-i] Technical changes after AUTH48

Phillip Hallam-Baker hallam at gmail.com
Wed Oct 17 10:37:14 PDT 2012


+1

When I think of some of the biggest blunders in specs, a lot of them were
last minute brain farts someone threw in.

The requirement for DER encoding in X.509v3 for example and the particular
choice of encoding. It is pretty obvious that nobody implemented that
before it went in the spec. If they had they would not have used definite
length encoding as the recursion issue becomes immediately apparent.

If a spec needs a major change in semantics during AUTH48 then it is clear
that it has not had sufficient review before AUTH48. Adding a state is not
an editorial change in my view.

Some really minor changes in specs have turned into ongoing blunders. On
one spec I wrote an early draft of but was not an author on the final one,
some people made a change to the spec to make it easier for them to
implement that has a major effect on the security model. They could see the
practical difficulty my approach raised but not the security requirement
that drove it.

Now that was made during the WG but I could easily see someone thinking it
was an acceptable AUTH48 change, it appears to be quite modest if you don't
understand the security implications.


The judgement call in my view would be if this is really an editorial
change rather than whether it was acceptable or not. So for instance if
there was a change that had been made in 6 places in the doc but not 7 then
that is almost certainly editorial, if there was something discussed on the
list, agreed to but fell out of the doc during edits then that is editorial.

Another issue here is that people often start implementing a spec as soon
as it has gone through last call and they quite reasonably assume that
there will be no semantic changes to the spec without discussion on the
mailing list.

Changing the spec semantically is going to screw that up completely.


On Tue, Oct 16, 2012 at 11:57 AM, Russ Housley <housley at vigilsec.com> wrote:

> Publishing a document that has known technical flaws does not seem like
> the right thing to do.
>
> In the past, the sponsoring AD has made a judgement call about the
> changes.  In the past 5+ years, when in doubt, the AD has raised a question
> with the WG or the IETF mail list during AUTH48.  In one case, a new WG
> Last Call and a new IETF Last Call were performed.  Based on the magnitude
> of the changes that you are suggesting here, the amount of discussion that
> has taken place on the WG mail list will help determine the appropriate
> actions.
>
> Russ
>
>
> On Oct 16, 2012, at 10:40 AM, Paul Hoffman wrote:
>
> > Greetings again. While we are waiting for Heather and Nevil to publish
> their updated draft, here is a completely unrelated topic.
> >
> > In an IETF WG, there was a -bis document that took forever to get
> published because technical suggestions trickled in and it was never clear
> when they were done. The trickle continued through IETF LC. They have
> continued *after* IESG approval. The document is now in RFC-EDITOR state.
> >
> > ...and it now has three technical changes that the authors want applied
> during AUTH48. These are not small changes: a protocol state is added, a
> list of states that require an action needs additions, and an appendix that
> had a complicated descriptive figure is removed.
> >
> > Should making these kinds of changes be acceptable? I ask this hoping
> that the answer is "yes" because I care about the particular document and
> am distressed that it has taken so long to get published, but if the RFC
> Editor is going to disallow the changes, the WG should know early so that a
> -ter document can be prepared immediately.
> >
> > --Paul Hoffman
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20121017/0004bcfa/attachment.htm>


More information about the rfc-interest mailing list