(This note seems to offer a useful point of departure, in this thread, so I
thought I'd resurrect it, for replying. /d)
Jari Arkko wrote:
Dave,
The first assumption is that there is a real problem to solve here.
I think there is a real problem, and that is the need to modernize the
headers and boilerplates so that they are more reasonable for each
stream. This includes things like getting rid of derogatory IESG notes,
which none of us likes.
I, too, think that there is a very useful bit of modification to the RFC title
page that would resolve concerns about reader confusion. The current draft for
headers and boilerplates defines a Source header, to indicate which stream the
document came out of.
<http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08>
<document source> This describes the area where the work originates.
Historically, all RFCs were labeled Network Working Group.
"Network Working Group" refers to the original version of today's
IETF when people from the original set of ARPANET sites and
whomever else was interested -- the meetings were open -- got
together to discuss, design and document proposed protocols
[RFC0003]. Here, we obsolete the term "Network Working Group" in
order to indicate the originating stream.
It currently requires that the reader already know what the possible choice are.
Since most readers won't know, it's not clear to me how much utility this will
have.
So instead of a field that simply lists only the actual source, I suggest a
header that defines its full context, by listing all choices and bracketing the
one that applies.
Hence:
Source: [[ IETF ]] IRTF IAB Independent
versus, for example:
Source: IETF IRTF IAB [[ Independent ]]
If a reader misses the meaning of this header, why would anyone think that they
will better understand any other text that is inserted?
Of course, headers and boilerplates changes need to be accompanied by
the corresponding change in 3932. THAT is the reason for the 3932bis
draft.
Giving the IAB authority to override the RFC Editor's decision is more than
clarity of labeling.
The trouble is, of course the final 3932bis needs to take the
opinions of the community into account (and be acceptable to the
Excellent idea. To justify making a change in the independence of the RFC
Editor, where is the IETF consensus? Absent that community consensus, of
course, the status quo is maintained.
Hmmm. Here's an uncomfortable legal question for us to consider:
Why is IETF consensus sufficient?
Since the RFC Editor has always been independent of the IETF, per se, what
gives the IETF the authority to declare changes to the RFC Editor's operation?
approving bodies). This is why we have discussed all the changes. I do
not see a lot of other options than the compromise position if
completing 3932bis and the rest of the system of changes is the goal.
In a private exchange that Russ was conducting over the last few weeks, I
suggested a mediation model, with the IAB reviewing the RFC Editor's decision,
but only authorized to make a recommendation, rather than mandating the change.
He reported that others he was talking with insisted on the current
"arbitration" model that mandates change.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf