Subject: [Tools-discuss] Different handling of RFC Editor submissions

From: Lisa Dusseault <[email-masked]>
Date: Mon, 9 Mar 2009 14:17:46 -0700

I just had to handle a new RFC Editor submission.  Along with my usual  
confusion about how to do this, I hate that it appears in my list of  
sponsored docs - the whole reason this doc is going to the RFC Editor  
is that we don't have the expertise to review it in APPS.  I don't  
have the expertise.  And I got a question from an unnamed AD who saw  
the doc on the agenda and asked "What's up with that!"  It took us 10  
minutes of explaining to each other why we didn't have the expertise  
to review it before I realized that he didn't realize it was an RFC  
Editor document and thought it was an actual IETF document.

And remember the last time you had to fill in a ballot for one of  
these and were trying to figure out if you were agreeing with the  
inclusion of the IESG statement that this document does not conflict,  
or disagreeing with the inclusion of the IESG statement that it does  
conflict?

For these and similar cases of confusion, I would like to find a way  
to handle RFC Editor submissions that does not involve treating them  
as IETF documents in the Tracker.   It should be a much simpler  
process and not involve possible states like "Last Call Requested",  
"IESG Evaluation", and especially not "Approved" [by IESG] attached to  
the document.

Does anybody with more tools exposure have an idea how to do this?

If it were up to me, I'd propose using the existing ticket system and  
agenda management system that's mostly not handled by ADs.
  - The RFC editor would send an email request to the Secretariat  
ticket system (could be a sub-address, I don't care).
  - The Secretariat would automatically put it onto the next agenda at  
least one week away, but not under the Document Actions header  
(Management Issues would be fine.)   Unless somebody proposed  
otherwise, the default answer would be "does not conflict".
  - An email goes out to the IESG saying there's a new RFC3932  
evaluation needed.  This gives people warning to see if they should  
propose a wording other than "does not conflict".
  - At the scheduled telechat agenda, the IESG votes to approve the  
response "does not conflict" (or another response if somebody prposed  
one).  If the IESG is not ready to decide, the decision can be  
postponed to the mailing list or to the next telechat at the latest.
  - The Secretariat emails the chosen response to the RFC Ed and we're  
done.

--- Scanned by M+ Guardian Messaging Firewall ---
Messaging Architects sponsors The Spamhaus Project.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Mar 2009 14:05:12 +1300

Lisa,

These documents are identified in the tracker, and they appear
in the IESG agenda in "3.3 Independent Submissions Via RFC Editor".
I don't really know how that could be clearer ;-)

Certainly the regular ballot never seemed quite right to me.
I think it should look different, something like:

[No comment] [No Conflict]  [Conflicts]  [Abstain]

I agree that the states and the state diagram should
also be different. However, I wouldn't remove the tracker from
the picture - just make it do the right thing.

Very similar remarks apply to IRTF documents.

   Brian

On 2009-03-10 10:17, Lisa Dusseault wrote:
> sponsored docs - the whole reason this doc is going to the RFC Editor is
> that we don't have the expertise to review it in APPS.  I don't have the
> expertise.  And I got a question from an unnamed AD who saw the doc on
> the agenda and asked "What's up with that!"  It took us 10 minutes of
> explaining to each other why we didn't have the expertise to review it
> before I realized that he didn't realize it was an RFC Editor document
> and thought it was an actual IETF document.
> 
> And remember the last time you had to fill in a ballot for one of these
> and were trying to figure out if you were agreeing with the inclusion of
> the IESG statement that this document does not conflict, or disagreeing
> with the inclusion of the IESG statement that it does conflict?
> 
> For these and similar cases of confusion, I would like to find a way to
> handle RFC Editor submissions that does not involve treating them as
> IETF documents in the Tracker.   It should be a much simpler process and
> not involve possible states like "Last Call Requested", "IESG
> Evaluation", and especially not "Approved" [by IESG] attached to the
> document.
> 
>  - The RFC editor would send an email request to the Secretariat ticket
> system (could be a sub-address, I don't care).
> (Management Issues would be fine.)   Unless somebody proposed otherwise,
> the default answer would be "does not conflict".
>  - An email goes out to the IESG saying there's a new RFC3932 evaluation
> needed.  This gives people warning to see if they should propose a
> wording other than "does not conflict".
> one).  If the IESG is not ready to decide, the decision can be postponed
> to the mailing list or to the next telechat at the latest.
>  - The Secretariat emails the chosen response to the RFC Ed and we're done.
> 
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>