[rfc-i] independent submissions to RFC Editor

[julian.reschke at gmx.de (Julian Reschke)]

Bob Braden wrote:
>   *> 
>   *> So, is the answer to his question "Yes, you should have probably 
>   *> submitted it to the appropriate Area Director"? Given what you said 
>   *> about funding and backlog, should he do so now?
>   *> 
>   *> --Paul Hoffman, Director
>   *> --VPN Consortium
>   *> 
> 
> That depends. If the document is of a quality and subject that is
> appropriate for an IESG member to spend his/her very valuable time,
> and if he can find a willing AD, then go for it.

Hi,

thanks for the feeedback. The document in question does have a related 
WG (webdav) and indeed has been discussed and informally last-called on 
the WG's mailing list, but when I asked didn't find enough support to 
make it a working group work item.

There are other things on the WG's agenda with high priority that I 
don't want to interfere with; but once those are done and in case my 
submission hasn't made any progress by then I'll try to get the 
Applications Area Director to look at it.

 From a procedural point of view it would be nice if ID's that are in 
the RFC Editor's queue would not expire after 6 months (do they right now?).


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]
From braden at ISI.EDU  Wed Jan 12 15:18:01 2005
From: braden at ISI.EDU (Bob Braden)
Date: Wed Jan 12 15:20:14 2005
Subject: [rfc-i] independent submissions to RFC Editor
Message-ID: <[e-mail]>


  *>  From a procedural point of view it would be nice if ID's that are in 
  *> the RFC Editor's queue would not expire after 6 months (do they right now?).
  *> 

The Secretariat is not supposed to expire I-Ds that are in the RFC
Editor queue.  That's the theory... what the practice is, we are
unsure.

Bob Braden

  *> 
  *> Best regards, Julian
  *> 
  *> -- 
  *> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:[phone]
  *> 
From carl at media.org  Wed Jan 12 18:00:04 2005
From: carl at media.org (Carl Malamud)
Date: Wed Jan 12 18:05:40 2005
Subject: [rfc-i] independent submissions to RFC Editor
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>

> 
>   *>  From a procedural point of view it would be nice if ID's that are in 
>   *> the RFC Editor's queue would not expire after 6 months (do they right now?).
>   *> 
> 
> The Secretariat is not supposed to expire I-Ds that are in the RFC
> Editor queue.  That's the theory... what the practice is, we are
> unsure.
> 

Hi Bob -

Of the 166 I-D's in rfc-editor.org/queue.html, 4 are not present in the
http://www.ietf.org/internet-drafts/ directory.

Please don't hesitate to write me if you want help figuring out what
the four are or how to contact the IETF secretariat.

Best regards,

Carl
From mankin at psg.com  Wed Jan 12 18:51:45 2005
From: mankin at psg.com (Allison Mankin)
Date: Wed Jan 12 18:53:45 2005
Subject: [rfc-i] independent submissions to RFC Editor
In-Reply-To: Your message of Wed, 12 Jan 2005 18:00:04 -0800.
	<[e-mail]> 
Message-ID: <[e-mail]>

Folks,

>From the point-of-view of the IETF i-d tracker system (which is
what decides which drafts live longer than six months), RFC Editor
Queue state does not occur until after IESG approval.  States from
Publication Requested, through AD Evaluation, on to RFC Editor Queue
(approved) prevent normal expiration.  The tracker doesn't contain
RFC Editor independent submissions until IESG is asked; then we assign 
them a state in the database, usually AD Evaluation or IESG Evaluation,
which assures non-expiration.  When the IESG completes its review (as
described now in RFC 3932), the draft is placed in the IETF's RFC Editor
Queue state.  This is the approved state in which the draft won't 
expire, where it stays until the RFC is published.

(Of course, the system breaks sometimes :(, so Carl's 4 drafts could be
ones that should not have expired - we tell authors to watch out...)

Bottom line though:  the database/state table for the i-d expiry system is
on the IETF side, and we have a bit of mismatch when it comes to RFC Editor
Queue for the RFC Editor independent submissions.

Allison

P.S. Carl, are your 4 totally missing, versus version changes?  

> > 
> >   *>  From a procedural point of view it would be nice if ID's that are in 
> >   *> the RFC Editor's queue would not expire after 6 months (do they right now?).
> >   *> 
> > 
> > The Secretariat is not supposed to expire I-Ds that are in the RFC
> > Editor queue.  That's the theory... what the practice is, we are
> > unsure.
> > 
> 
> Hi Bob -
> 
> Of the 166 I-D's in rfc-editor.org/queue.html, 4 are not present in the
> http://www.ietf.org/internet-drafts/ directory.
> 
> Please don't hesitate to write me if you want help figuring out what
> the four are or how to contact the IETF secretariat.
> 
> Best regards,
> 
> Carl
> 
From carl at media.org  Wed Jan 12 19:20:36 2005
From: carl at media.org (Carl Malamud)
Date: Wed Jan 12 19:40:11 2005
Subject: [rfc-i] independent submissions to RFC Editor
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>

Hi Allison -

That was very helpful!

> P.S. Carl, are your 4 totally missing, versus version changes?

Here are the four I show:

http://www.ietf.org/internet-drafts/draft-ietf-ipo-impairments-04.txt
new revision available:
   http://www.ietf.org/internet-drafts/draft-ietf-ipo-impairments-05.txt

http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-10.txt
new revision available:
   http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-11.txt

http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-06.txt
new revision available:
  http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt

http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-22.txt
new revision available:
   http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-23.txt

So, to answer the original query:

> > > 
> > >   *>  From a procedural point of view it would be nice if ID's that are in 
> > >   *> the RFC Editor's queue would not expire after 6 months (do they right now?).

"No, they don't expire after 6 months, though there are a few minor
differences between the two queues."

And, to answer Bob Braden's query:

> > > The Secretariat is not supposed to expire I-Ds that are in the RFC
> > > Editor queue.  That's the theory... what the practice is, we are
> > > unsure.

"Bob, the practice and the theory appear to mesh fairly well."

May I add a query?

"Why does it appear the RFC Editor does not know this information or, it might appear
to an uninformed outsider, does not care what the answer is?"

Best Regards,

Carl
From john+rfc at jck.com  Wed Jan 12 20:05:48 2005
From: john+rfc at jck.com (John C Klensin)
Date: Wed Jan 12 20:07:44 2005
Subject: [rfc-i] Re:  request to deprecate numeric citations in
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>

Hi.

Although I've used numeric citations, I favor this change.
However, I would encourage folks to think through two
potentially unintended consequences:

(1) What converted me to numeric citations was the realization
that there was no way to alphabetize mnemonic/text references if
the references section itself was divided into two parts.    The
style manuals I use seem to think that asking the reader to flip
through two separate "references" sections in order to find a
given reference is not a good idea.  With numeric references,
one can at least number straight through and have 

    Normative references
    [1] ...
    [2] ...
    Informative references
    [3]...

Now, one might use
    Normative references
    [N.Bozo95] ...
    [N.Clar97] ...
    Informative references
    [I.Rudo04]...
but I don't think I've ever seen it in an RFC and the XML2RFC
model doesn't make it easy to generate, to put it mildly.

(2) More generally, the names that are needed to make public
entities unique are fairly nasty for symbolic references.
[RFC9999] is fine, but [I-D.ietf-bozo-foo-bar-content] is fairly
unpleasant.  It is pretty late in the game to think about this,
but I wonder whether we should have had those external library
entries structured so that they did not contain the <reference>
tags themselves.  That would have permitted

   <reference anchor="Bozo05">
      &foobarcontent;
   </reference>

or, given the above issue,
   <reference anchor="N.Bozo95".
      &foobarcontent;
   </reference>

But I don't know how to get there now unless we permit
<reference> to have <reference> elements.  I'd like that for
compound references, but I gather I'm in the minority for
wanting those at all.

    john