Re: [apps-discuss] Multipart/report, draft-kucherawy-rfc3462bis-01.txt

[Ned Freed <[e-mail]>]

> >> I know you know this; I don't know why you think it's a small deal.
> >
> > Perhaps because it *should* be a small deal. And to the extent it isn't, I'm
> > not sure I see the value in trying to accomodate brokenness.

> At least part of Dave's point, setting aside issues related to
> complaints and over-tweaking and DISCUSS ballots, is that there's a
> *real* cost to getting any document through that involves:

> -- Someone taking on the task of editing the document and making the
> case for it.

> -- A document shepherd and reviewers to make sure it's ready to go.
> -- An AD's time to manage the process.
> -- An IETF-wide last call.
> -- Usually, several directorate reviews; at least GenART and SecDir
> for everything.
> -- IESG review, which requires ballots (and, therefore, presumably,
> review) from at least ten ADs.
> -- Time on a telechat, even if it's only a minute or two.
> -- Review by IANA, and communication with the authors.
> -- RFC Editor processing, which is never insignificant.

> I might have missed something, but I think I got most of it.  Even the
> most lightweight version of all that is more expensive than most of us
> think about.

No, it's exactly as expensive as I assumed it would be.

But given that this is a draft standard and the rules say removing a
restriction means recycle at proposed, what alternative would you suggest?
Creating a new document that removes the restriction, getting that approved at
proposed, then moving that to draft, then revising at  draft is actually more
steps and more work. Or perhaps you would prefer to make a nice big mess by
creating a new subtype like, say,
multipart/report-without-restriction-because-IETF-processes-are-too-heavy-to-fix-stuff?

I'm sorry, but tying ourselves into knots trying to avoid doing the right
thing is expensive in its own right - vastly more expensive IMNSHO than
the process you're trying to avoid.

				Ned