Personal tools
You are here: Home → communicationRecord → rfc2188Publication → Now: Improving the Informational RFCs Publication Process both in Theory
Navigation
Log in


Forgot your password?
 

Now: Improving the Informational RFCs Publication Process both in Theory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Now: Improving the Informational RFCs Publication Process both in Theory and in Practice -- Was: Re:Unexpected and Unreasonable delays in processing of Informational



>>>>> On Wed, 6 Aug 1997 15:08:21 -0400 (EDT), Scott Bradner <sob@harvard.edu> said:

  >>> I believe that you have already seen my email explaining how
  >>> irresponsibly and negligently the IESG and the RFC Editor have treated
  >>> the publication of this document. I can email you a copy if you have
  >>> not seen that.

  Scott> the RFC editor was following the direction of the IESG as rfc 2026
  Scott> tells it to do - so no abuse should be directed to them.

I intended no abuse towards the RFC Editor. No abuse was directed to
them. What "abuse" are you talking about?

I hold a high degree of admiration and respect for those who have put
in place and practice the open and fair RFC publication process.

In general based on what I have seen and know, the RFC Editors are
doing a great job of publishing information for the Internet technical
community. Our thanks and keep up the good work. Kudos!

However, in the specific case of our document, a lot has gone wrong
and based on my reading of RFC 2026 part of the responsibility for
what has gone wrong is the RFC Editor's. Later in this message, I will
explicitly say what "irresponsibly and negligently" referred to.

  Scott> As I said  things slipped through the cracks and
  Scott> I am sorry that happened.

Apology accepted, of course.


Let's turn all of this into something positive by focusing on the
following explicit objectives.

 1- Making sure our document gets published without any further delay.

 2- Finding out what exactly went wrong in the case of this document.

 3- Finding out how we can improve the process and procedures so a
    problem like this will not happen again.

On the first point, I am glad that Scott has accepted the
responsibility for overseeing the publication of ESRO without any
further delay and that we are now back on track. I have made clear our
sense of urgency in seeing this document published as an RFC.

Scott, if you don't agree with any of the above paragraph, please let
me know right away.


On the second point, I think there is a lot more to this than "things
slipped through the cracks". As a user of the RFC publication service
I can provide you some feed-back which I had hoped you would find
useful.

On Jan 15, after we submitted our request for publication to the RFC
Editor I expected that the RFC Editor will take on the responsibility
of overseeing its progress towards publication in a timely manner.

My email of April 3 1997 appears to have been totally ignored by the
RFC Editor and the IESG.

In that message I asked:

 Mohsen> Can you please let us know generally what the reason for the delay is?

 Mohsen> Can you tell us who the IESG contact person is for this Informational
 Mohsen> RFC?

 Mohsen> Based on my understanding of the process of Informational RFC
 Mohsen> publication (RFC-2026 Sections 4.2.2 & 4.2.3), IESG's review relates
 Mohsen> to conflicts of the domain of the document with work that is being
 Mohsen> done or is expected to be done, within the IETF community. Is there a
 Mohsen> conflict?

At that time our only contact point was the RFC Editor.
The Editor neglected to reply to that message.
Those questions remain unanswered even today.

Had the RFC Editor responded to that message in April, we would have
save a lot of time. 

The above instance alone justifies my fair use of the word
"negligently". There is no abuse there.

My previous messages clearly shows how on several occasions the IESG
neglected to respond to our inquiries.

In my opinion the heart of the problem in this case is that the
RFC-Editor seems to have been reduced to a puppet. Rather than
managing the RFC publication process the RFC-Editor seems to be
functioning as an inefficient messenger for the IESG. This is clearly
in conflict with with the spirit of RFC-2026 Sections 4.2.2 & 4.2.3.


On the third point, there are a number of ways that I can help out in
addressing the above mentioned problems. I'll be happy to work with
Scott on the next revision of RFC-2026 to make the text of 4.2.{2,3}
more tight and clear. I'll also be happy to make the case that in
practice the RFC-Editor needs to have a stronger and more independent
role.

We are all on the same side. 
Let's work together.

...Mohsen.


P.S.
  I have been CCing Jon Postel on most of this thread and
  would love to know what he thinks of all of this.
Replies
Re: Unexpected and Unreasonable delays in processing of Informational, Scott Bradner
Re: Unexpected and Unreasonable delays in processing of Informational, Scott Bradner
Main Index | Thread Index
Document Actions