Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)

Ned Freed wrote:
>>>> There has been a discussion recently on LTRU as to whether a Terms and
>>>> Definitions section should be introduced within RFCs - much like those
>>>> within ISO Standards.
>>>>
>>>>         
>>> And my response to this suggestion is the same as it was for the "IANA
>>> considerations" or "Internationalization considerations" section suggestions:
>>> By all means have a "terms and definitions" section or whatever in the document
>>> if there's a need for one, but don't make having one mandatory in all
>>> documents.
>>>
>>> We already have more than enough useless (from a technical content
>>> perspective) boilerplate in our documents.
>>>       
>> +1
>>     
>
>   
>> Actually I don't have so much of a problem with having such sections in
>> drafts at review time, but I hate to see them clutter up published
>> RFCs.
>>     
>
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.
>
> What's appropriate to appear in the final RFC is up to the RFC Editor. That's
> what the word "editor" implies. If the RFC Editor deems it appropriate to
> remove null sections that's fine, if they feel they should be retained that's
> fine too. Someone reading an RFC to learn how to implement something has a
> definite goal in mind and isn't going to be (or at least shouldn't be)
> distracted by boilerplate in the same way a reviewer looking for issues - a far
> more nebulous proposition - can be.
>   

Well, I guess we do disagree here to some extent.  For me, every
sentence of a document that doesn't contribute to the technical
knowledge that needs to be conferred, interferes with readability, and
ultimately, interoperability.  That applies to the copyright
boilerplate, that applies to checkoff sections that are just there to
get approval, it applies to information that is needed only by IANA. 
And I wasn't aware that our processes allowed the RFC Editor to delete,
say, a meaningless IANA considerations section.  (I've never checked to
see whether has happened.)

However I don't have a problem with IESG wanting additional supporting
information to help it decide whether to approve documents and to decide
what additional processing is needed.  If the best place to put such
information is in the I-D, fine; if the best place to put that
information is in a separate form, that's also fine with me.  (And I'd
far prefer that we not impose unnecessary burdens on authors of early
I-Ds - the fewer hoops they have to jump through, the better.)

In general, I think that I-Ds and RFCs really serve very different
purposes, and trying to make them be (almost) the same causes us to make
less readable end product.  I'd like to see more use of "NOTEs IN DRAFT"
and similar devices to separate supporting material from material that
belongs in the final publication.  I'm concerned about readability
throughout the document cycle, but am especially concerned about
readability of our published documents - as many more people read them
at this stage and those people have less context to aid them in sorting
through the crap.

Keith

Received on Tuesday, 11 September 2007 20:56:11 UTC