[rfc-i] Technical changes after AUTH48
jmpolk at cisco.com
Tue Oct 16 11:10:15 PDT 2012
IMO - this realy shouldn't be a judgement call, as I've viewed many
cases in which protocol states change in AUTH48, as well as values
change (added or subtracted), or normative language gets "adjusted".
This has occurred too often that I'm aware of, I'm sure it happens
many many more times than I track.
Thus, something more formal should exist in this regard (i.e., to
take it back to the WG for short review of what's being proposed).
At 10:57 AM 10/16/2012, Russ Housley 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.
>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
More information about the rfc-interest