RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

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

 



John,

Your suggestion would largely address my concerns related to the
timely appeal path.

Best regards,
Pasi

> -----Original Message-----
> From: ext John C Klensin [mailto:john-ietf@xxxxxxx]
> Sent: 02 September, 2009 20:20
> To: Eronen Pasi (Nokia-NRC/Helsinki); jmh@xxxxxxxxxxxxxxx;
> ben@xxxxxxxxxxxx
> Cc: iesg@xxxxxxxx; ietf@xxxxxxxx
> Subject: RE: draft-housley-iesg-rfc3932bis and the optional/mandatory
> nature of IESG notes
> 
> 
> 
> --On Tuesday, September 01, 2009 09:55 +0200
> Pasi.Eronen@xxxxxxxxx wrote:
> 
> > Joel M. Halpern wrote:
> >
> >> If the ISE / RSE is unreasonable, the IAB will slap the
> >> editor and say "stop doing that."  There is no equivalent
> >> process if we reverse the structure.
> >
> > Yes, there is. If the IESG would request/recommend a
> > particularly bad IESG note, this decision can be appealed just
> > like any other IESG decision. The IAB would then determine if
> > the IESG acted appropriately or not.
> >
> > On the other hand, if the ISE/RSE decides to publish a document
> > without an IESG note even if the IESG requested/recommended
> > it, this decision cannot be effectively appealed (since the
> > RFC already came out, and can't be really "recalled").
> >
> > Although I'm not expecting this really to happen very often
> > (if ever), from checks-and-balances viewpoint I would support
> > (b) from Jari's email (in other words: RFC Editor cannot
> > unilaterally ignore a note requested by IESG, but has to take
> > it to the IAB via the usual appeal procedures).
> 
> Pasi,
> 
> A comment and then a suggested middle position.
> 
> I've been watching what we now call the Independent Submission
> Process for far longer than there has been an IETF.   I've seen
> it as an insider for a large fraction of two decades -- as an
> AD, an IAB member and then chair, as an editorial board member,
> and now as an IAB member again.   During that period, I've never
> seen an RFC Editor abuse the process by ignoring legitimate
> input.  Bob Braden may be able to provide an inside view --not
> in his present role of RFC Editor but as the very-long-time IAB
> Exec Director -- of what happened before 1992, but my educated
> guess is that instances of "RFC Editor ignores input" during
> that time were also about zero.
> 
> During the same period, I'd seen behavior I consider abusive
> from ADs or the IESG many times --  attempting to prevent
> publication of documents with which they had personal/ emotional
> disagreements that they were unwilling or unable to explain in
> public, asking for publication holds on documents for multiples
> of years, insisting that the RFC Editor not move forward until
> the IESG responds in some way and then not responding for months
> and months, demanding changes that would significantly weaken
> the document or change its meaning, and so on.  Many of those
> problems have been resolved by negotiation, but some have not.
> RFC 3932, and its limitation on technical review, was a huge
> improvement over its predecessors in that regard, but we've
> heard multiple ADs over the years claim that they can redefine
> any disagreement about a document into either a technical issue
> or a technical one (whichever is needed) if they care enough and
> especially if they can define the boundary (which they also have
> insisted that the IESG has the unilateral right to do).
> 
> In principle, the IAB could appoint a new ISE to take over in
> January who would adopt a policy of abusiveness.  But I think I
> can speak for the ACEF membership and the IAB if I say that we
> don't intend to do that... and that the IAB would expect the RSE
> to move fairly quickly, with the IAB's backing, to correct the
> attitudes involved if it occurred anyway.
> 
> So trying to make IESG notes mandatory on documents originating
> in another stream for the reasons you cite above is solving a
> problem we've never had at the risk of making a problem worse
> that we've had several times.  That strikes me as bad
> engineering at best.
> 
> And insisting that the RFC Editor invoke a formal appeals
> procedure in case of disagreement with the IESG about an
> Independent Submission would, as Olaf points out, largely undo
> the efforts of the last few years to clearly separate the
> different streams.  It would be as sensible to say that IESG
> notes should be sufficiently exceptional that the IESG would
> need to consult the IAB and get permission before sending any
> such note-request to the ISE.  I suspect that such a provision
> would not make either the IESG or the IAB very happy.
> 
> However, if your concern is really to make sure that there is a
> timely appeal path, I have a suggestion that might be acceptable
> to everyone without causing unfortunate side-effects.  We simply
> require that, if the ISE receives input from the IESG requesting
> specific changes to a document ("specific changes" including,
> but not limited to, so-called "IESG Notes") and the ISE and
> authors decide to not incorporate those proposed changes, the
> ISE is required to explain to the IESG, in writing, why not and
> allow a reasonable period of time for the IESG to respond.  If
> it felt it were necessary, the IESG could then open a further
> discussion, ask the RSE to mediate, or launch a formal request
> for IAB review.  Consistent with other provisions in RFC 4846,
> either the IESG or the ISE could, at their discretion, make the
> correspondence (the request and response) public.
> 
> The one restriction I'd impose on this is that "reasonable time"
> not be more than a few weeks... again, there has been abuse in
> that area in the past and re-enabling such abuse would be, well,
> dumb.  If the ISE notifies the IESG and the IESG doesn't
> respond, then the ISE can go ahead and publish without further
> delay.
> 
> Does that work for you?  And, if not and you still think you
> need mandatory notes, why?
> 
> best,
>     john
> 
> 
> 


_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]