Subject: [spfbis] Bloating the RFC

From: Arthur Thisell <[email-masked]>
Date: Fri, 31 Aug 2012 09:48:28 -0700 (PDT)

OK, I've mentioned this once before, but the size of RFC4408bis is bothering me.

draft-mengwong going into MARID:    36 pages, about 9 months of writing
coming out of MARID:                46 pages, about 4 months of writing
RFC4408:                            46 pages, about 9 months of writing
                                    (IESG appeals delayed publication)
RFC4408bis (excluding appendix C):  63 pages, about 3 months of writing

We have bloated the spec by over 35% so far.  What value have we gotten for all that?   Every page is more stuff people have to wade through to find the important stuff.

For comparison:

RFC5322 has only 55 pages.
RFC5321 has 94 pages, but it defines all of SMTP

RFC6376 has 75 pages to define DKIM!
RFC5451 has 43 pages to define a single header field!

Ugh.   If the quality of a standard was measured in pages, OSI would have crushed the IETF.  I thought it was a bad sign that SPF needed 46 pages, just to add an extension to SMTP.

Do we *really* need a long intruduction, with a protocol status and history subsections?   The protocol status was important when SPF has been beaten around for years, but now it is on the standard track.  

Do we really need the section on wildcards?   Yeah, RFC4408 was drafted around the time that the DNS folks were doing a lot of stuff with wildcard records and there was a lot of concern about them, but could we cut it down and and make a few mentions in other sections?   

Do we really need section 9 (implications) to be 9 pages long

Do the macro examples (8.2) need 2 pages?

I haven't put serious thought into eliminating those sections, so don't open tickets for them, but this WG seems to be all too willing to add stuff, and not willing to cut anything out.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 10:08:57 -0700

> RFC5451 has 43 pages to define a single header field!

I would love to know what you think might reasonably have been
excluded from either of those, especially when reviewing their
respective paths through the formal evaluation processes.

There's a lot of context the transition from RFC4408 carries with it
to this document.  Also, this document will undergo actual IESG review
where RFC4408 did not.

> Ugh.   If the quality of a standard was measured in pages, OSI would have crushed the IETF.  I thought it was a bad sign that SPF needed 46 pages, just to add an extension to SMTP.

I think 46 pages is pretty typical these days for what SPF tries to
accomplish.  So I'm not sure I agree that page count is a useful
metric for document quality.

Looking at the diff you cited earlier between RFC4408 and this draft,
the bulk of the added text is in Section 9 and Appendix C.  The
remainder is largely rewording or an added sentence here or there.  It
doesn't really look like 17 pages were added.  I wonder if a lot of
this is just related to cumulative formatting changes since xml2rfc
came along.

But I don't feel that adding text that documents six years of
experience (which includes describing some deep philosophical divides)
and the advice based on same can be considered unwarranted bloat.
Mail is a funny space, unlike most others; local policy and subjective
interpretation of data often need to be discussed, something through
which other protocol layers don't generally need to suffer.  And
security protocols often come with a lot of pedagogy.

-MSK