Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 1 Dec 2007 13:59:26 +0100

Tom Petch wrote:

> a 60 day hold seems rather a good idea.

Indeed, unless somebody transforms John's proposal "6 weeks"
in an ION and/or 2026 update, or whatever red tape cutting
this needs.  If appeals are drafted by a kind of community 
this needs time (e.g. to figure out who read the relevant
"procdoc" RFCs... ;-)

 Frank

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Dec 2007 11:38:22 -0500

> this needs time (e.g. to figure out who read the relevant

Frank, while figuring out what we are doing and documenting it
would certainly be a good idea, my suggestion was carefully
written to be feasible without any action as formal as opening
2026.  The IESG clearly has the authority today (if only because
the RFC Editor believes that they do) to ask for a publication
hold.  All it would take to implement that part of my suggestion
would be an announcement that, while the appeal window remains
at two months, any appeals that intend to ask for a publication
hold must be announced in some substantive way within some much
shorter time.  

Whether or not publication delays are then granted might, as I
suggested, depend on joint IESG/IAB decisions about the level of
possible damage and merit of the appeal.  But, as many others
have pointed out, the cases are few in which significant damage
would be done by publishing and then changing status and/or
posting a follow-up.  I'd even suggest that a document that was
significant enough to achieve IETF consensus as measured by the
IESG --even if that measurement is overturned on appeal-- is a
document that would normally deserve publication as a "path not
traveled" independent or individual submission.

That view argues that, in the rare cases in which a publication
delay might be justified, someone who thinks one is needed
should ask (presumably by posting a notice of intent to appeal
with that request and justification) really quickly, before the
RFC Editor can review, publish, and post _however_ short that
time is.  I'd then expect the IESG to ask that publication be
suspended until they and the IAB can sort out whether a delay
while the appeal is filed and sorted out is appropriate.   But,
again, while an ION to record whatever the plan is would be
appropriate, I don't think we would be doing ourselves a favor
by turning this into a big deal with a lot of formal procedures
and cutoffs.

As I think more about it, harm is more likely to be caused by
IANA registrations specified in a document as requiring IETF or
IESG approval and then needing to undo such registrations after
an appeal than by publication of the document itself.  As far as
I know, we have never insisted on a two month hold for such
registrations: we just assume that we can deprecate them if we
have to.

    john

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 1 Dec 2007 11:12:54 -0800

From: "John C Klensin" <[email-masked]>

> 2026.

The metapoint that John may have assumed (because I know he knows it, 
because he's pointed this out to me many times) is that every time we stick 
very specific stuff in process BCPs, we regret it.

I had the privilege of working on a minor process revision to RFC 3777 
(NomCom process) earlier this year, and that was a dream, because all the 
dates were deadline-driven - we wanted to START earlier, and there was very 
little stopping us from STARTING earlier.

When we get very specific, we find ourselves publishing "what we really 
meant was" BCPs that fix previous BCPs, with nice long publication delays 
while we either run under broken rules or ignore them and hope no one 
appeals.

And THAT is why John is right about not "opening 2026", which is actually a 
codename for "reopening every process discussion we've had since 2027 was 
published". Someday we might "open 2026", but it shouldn't be for this 
reason.

Thanks,

Spencer

---

From: Magnus Westerlund <[email-masked]>
Date: Sat, 01 Dec 2007 20:39:23 +0100

Brian E Carpenter skrev:
> On 2007-12-01 00:45, Harald Alvestrand wrote:
>> Tom.Petch wrote:
>>> I recall a recent occasion when the IESG withdrew its approval, for
>>>  draft-housley-tls-authz-extns
>>> a document that both before and after its approval generated a lot of
>>> heat,
>>> within and without a WG.
>>>
>>> Presumably the expedited process would, or at least could, have seen
>>> that
>>> published as an RFC.
>>>
>>> With that example in mind, a 60 day hold seems rather a good idea.
>>>   
>> In that case, it went into the RFC Editor queue on June 30,, 2006, and
>> was yanked from the queue on February 26, 2007 - 8 months later.
>>
>> According to the "third last call" announcement:
>>
>> On June 27, 2006, the IESG approved "Transport Layer Security (TLS)
>> Authorization Extensions," (draft-housley-tls-authz-extns) as a
>> proposed standard. On November 29, 2006, Redphone Security (with whom
>> Mark Brown, a co-author of the draft is affiliated) filed IETF IPR
>> disclosure 767.
>>
>> it was five months between approval and the IPR disclosure.
>>
>> A two-month hold wouldn't have caught it.
>> (No idea why it was still hanging there long enough for the IPR
>> disclosure to catch up with it...)
> 
> In any case, I would much rather have seen that published and later
> declared Historic than hold up all other RFCs. It isn't as if the
> IETF can control what actually gets implemented and deployed
> in any case - so why on earth does it *matter*? Whereas getting
> the vast majority of RFCs published promptly *does* matter.
> 

I am actually worried with the inter SDO implications of blocking
publication for 2 months. Unless we actually always block publication
for 2 month for approval this doesn't help. So what are we going to say
to other SDO and they ask, can you do your best to get this document
published. And then we have to say, well the document can be made ready
but we can't for formal reasons provide it until 2 months have past. I
think this would be going in the wrong direction on use cooperating with
other SDOs.

However, it clearly solves the issue with appeals and if it is IESG or
IAB discretion whether the document is blocked or not. I actually are
worried that people may use a "appeals always block publication" as way
of forcing removal of ietf protocols from other SDOs specifications. The
reality is that neither IESG or IAB can process appeals extremely
quickly. Unless they are obvious bogus.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 1 Dec 2007 21:22:13 +0100

John C Klensin wrote:
 
> figuring out what we are doing and documenting it would 
> certainly be a good idea, my suggestion was carefully
> written to be feasible without any action as formal as
> opening 2026.

Yes, and you also said that you're not going to do it.
If Brian wants to tackle it he'd likely integrate your
idea in his "appeal" I-D, Harald might prefer an ION to
have it on public record, IMO there are various ways to
"implement" your proposal.

> All it would take to implement that part of my suggestion
> would be an announcement that, while the appeal window
> remains at two months, any appeals that intend to ask for
> a publication hold must be announced in some substantive
> way within some much shorter time.

Okay, but it's not a clean hack.  In both cases where I felt
a sudden urge to appeal (sitefinder-verisign and termination
of MARID) I ended up with speed reading RFCs based on grep
and Google searches, I'd certainly have missed anything more
subtle, e.g. an ION or old IESG announcement buried in a list
archive.  I needed three months to find "3710 to historic" as
a potential "remedy", it wasn't on my CD ROM with RFCs, and
of course three months was anyway far too late.  

BTW, that's a flaw in Brian's proposal to deprecate the STD 1
rule, not everybody reads the RFCs online with access on a 
list of current STDs (etc.) published as rfc-editor.org page.

> Whether or not publication delays are then granted might,
> as I suggested, depend on joint IESG/IAB decisions about
> the level of possible damage and merit of the appeal.

Yes, a cleaner (and faster) procedure would be to start the
appeal chain *above* the level of the appealed decision, in
the case of an RFC approved by the IESG go directly to the
IAB (and maybe vice versa for the rare IAB RFCs).  

> the cases are few in which significant damage would be done
> by publishing and then changing status and/or posting a 
> follow-up.

Let's face it, most folks out there don't get the fine print
of "not every RFC is a standard".  Publishing garbage as RFC
is the worst possible outcome, and no status changes, errata,
updates, or other options can really fix it.  Whatever is in
say 2821bis will be holy scripture for decades (skipping the
many years where folks will still try to cite 2821), any minor
issue in it could cost billions later.  

Just an example - I don't think that your "avoid WGs to get
rid of the trolls" approach posted elsewhere is a good idea:
WGs have real Chairs forced to post real (hat on) decisons,
offering an opportunity for real appeals below the IAB level.
The "design team" approach is risky, maybe you win two years,
but you could also lose five years.  For important RFCs like
SMTP or IDNA "five years" could be too long.  I saw no trolls
on the httpbis list so far (not counting me, YMMV), it's a very
business oriented WG with a reasonable timetable (October 2008).

> I'd even suggest that a document that was significant enough
> to achieve IETF consensus as measured by the IESG --even if
> that measurement is overturned on appeal-- is a document that
> would normally deserve publication as a "path not traveled"
> independent or individual submission.

AFAIK it's not possible to add IESG notes (or anything at all)
to a published RFC.  Maybe it would be a good idea to publish
such decisions when they come after the fact also as "erratum",
folks reading RFCs on the IETF tools server have then a chance
to find it.

> while the appeal is filed and sorted out is appropriate.

Yes, that's what you did back in summer 2005.  For Sender ID it
wasn't necessary because it anyway had a normative reference to
SPF, and one co-author supported the appeal (and could in theory
block the whole set).  For the "real" appeal (not the 1st "IESG
reviewing its own decision" round) it was different, we risked
that the RFC-editor might be faster than the IAB.  But he wasn't
at this time, and besides the IAB rejected the Sender ID appeal,
because experiments are experiments, and free to cause havoc as
they see fit... :-(

> while an ION to record whatever the plan is would be
> appropriate, I don't think we would be doing ourselves a
> favor by turning this into a big deal with a lot of formal 
> procedures and cutoffs.

Well, it's highly disruptive if Redmond decides to "embrace,
extend, and extinguish" an idea, and it's not better if they
decide to use the "democratic framework" of another SDO to get
a standard for their Office product.  Disclaimer, I like Excel
on boxes where it's available, it's a nice product.  But it's
not nice enough to say that 1900-02-29 was day 60 in year 0,
if that's what the 6000 ooXML pages say (I only looked at some
nits in the BSI Wiki, I never read any page of the huge draft).

I've even calculated the cost for an "unfriendly takeover" of
the IETF, and fortunately arrived at a sum that they couldn't
hide (between 10 and 20 million USD).  

> harm is more likely to be caused by IANA registrations
> specified in a document as requiring IETF or IESG approval
> and then needing to undo such registrations after an
> appeal than by publication of the document itself.

Yes, the "experimental" solution for a case discussed here
recently is elegant wrt stable IANA registries.  Admittedly
I wouldn't try to explain this to hit and run posters.  

Maybe we should have a kind of "help" list for procedural
issues, and for new contributors, or a Wiki with a Forum,
or similar.  It's good if the number of folks who know all
rules (and ways to bypass them) is not yet zero, but it
starts to get very confusing if the published rules are
always the old rules, while the real rules are some kind
of elitist "need to know" insider oral history.

Fortunately at least the errata submission works again -
please send pictures if you happen to watch the historic
moment when an A-D figures out what this actually means,
I'd get a screaming fit as victim of this assault... ;-)

> As far as I know, we have never insisted on a two month
> hold for such registrations: we just assume that we can
> deprecate them if we have to.

Depends on the registry, doesn't it ?  

 Frank

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Dec 2007 15:43:35 -0500

> Yes, and you also said that you're not going to do it.

Yes.  I have made a personal decision that spending my time on
Internet technology and protocols is better for the Internet and
better for my mental and physical health than making further
investments in IETF procedures.  That decision has been
reinforced by an assortment of actions in the past, including
IAB, IESG, and Nomcom actions.   I will probably continue to
track issues like this, and IPR ones, etc.   I may even express
opinions about what might be placed in an I-D.   But, if process
I-Ds need to be written, someone else will need to write them,
at least unless someone starts paying me a salary to do so.

> "implement" your proposal.

Of course, although I am in strong agreement with Spencer's
comments that making rigid, BCP-level, procedures for unusual
cases has almost never served us well.   I more or less said
that, but Spencer's note is much more clear and explicit.

> list of current STDs (etc.) published as rfc-editor.org page.

I think you are conflating two issues.  The first is that what I
suggested is not, IMO, a hack.  It is taking advantage of
flexibility and options for applying discretion that are built
into the system (mostly not by accident).   YMMD, of course.
The second is about whether the IETF processes are
straightforward and well-documented enough that someone who is
not already very familiar with them can efficiently navigate the
process.    We are probably in agreement about that state of
affairs.   I would favor fixing it but, based on painful
experience, I would recommend that anyone who wants to try get
IESG signup first and that they not get the effort entangled
with working on the answer to any short-term or isolated
question (of which publication delay issues are certainly an
example).

Your other comments are much more general.  Whether I agree or
disagree, I don't have time to respond adequately this weekend.
I would, however, note that several of the issues you identify
would have been resolved by proposals that were made a few years
ago.  The IESG decided those changes were either unnecessary,
undesirable, or not worth the trouble and the community accepted
those decisions (even if the only concrete way to measure
"accepted" is that no one got recalled and the IESG did not get
fired in toto).    For better or worse, that suggests that the
people who care about these things are a minority and that they
have not been successful in convincing the majority that the
topics are worth significant consideration.    I think those of
us who make up that minority need to accept that face... and I
have.

        john

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 01 Dec 2007 23:54:53 +0000

Russ,

IETF Chair wrote:

>While we figure out what policy we want, I have asked the RFC Editor to
>not publish any IESG approved documents until their appeal timer has
>expired.  I also challenged the RFC Editor to move things along so fast
>that this matters.  I suspect they can.  Which means that the whole IETF
>community needs to help the leadership figure out the appropriate policy
>before the rapid processing of Internet-Draft documents into RFCs becomes
>the norm.
>  
>
I would like to ask a clarifying question: does this mean that RFC 
editors are not going to start editing the document until after 2 months 
since approval of a document, or does it mean that RFC editors start 
editing right away, can issue AUTH48 request, but will delay publication 
until after 2 months?

I think the latter is better, because (a) appeals are not that frequent 
and (b) AUTH48 usually takes way longer than 2 days ;-).

Regards,
Alexey

P.S. I apologize in advance for asking the question before reading the 
whole thread. Maybe it was already asked.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 01 Dec 2007 16:18:49 -0800

> editors are not going to start editing the document until after 2
> months since approval of a document, or does it mean that RFC editors
> start editing right away, can issue AUTH48 request, but will delay
> publication until after 2 months?
>
> I think the latter is better, because (a) appeals are not that
> frequent and (b) AUTH48 usually takes way longer than 2 days ;-).
The latter. There is a handful documents in the wait state.

Jari

---

From: Russ Housley <[email-masked]>
Date: Sat, 01 Dec 2007 20:48:55 -0500

Alexey:

The latter.  If the Auth48 completes before the 60 day appeal timer 
has expired, then the RFC Editor will hold off on publication until 
the 60 days have gone by.

Russ

P.S. A document that I wrote was the first document to get snagged in 
this situation.  I guess it is only fair....  It got published yesterday.

At 06:54 PM 12/1/2007, Alexey Melnikov wrote:
>months since approval of a document, or does it mean that RFC 
>editors start editing right away, can issue AUTH48 request, but will 
>delay publication until after 2 months?
>
>P.S. I apologize in advance for asking the question before reading 
>the whole thread. Maybe it was already asked.
>
>
>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 1 Dec 2007 22:15:14 -0800

Before we head further down this track, do we have any data as to how  
big a problem we are thinking of fixing?

Since the IETF has been producing RFCs, how many have been appealed  
in the 2 months after IESG approval?  I would like to see the actual  
numbers.  Does this happen 10%, 1%, .1%, .01%, .001%, etc. of the time?

Bob

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 02 Dec 2007 14:56:34 +0100

--On 1. desember 2007 22:15 -0800 Bob Hinden <[email-masked]> wrote:

> Before we head further down this track, do we have any data as to how big
> a problem we are thinking of fixing?
>
> Since the IETF has been producing RFCs, how many have been appealed in
> the 2 months after IESG approval?  I would like to see the actual

If we assume the list on <http://www.ietf.org/IESG/Appeals.html> is 
complete, there has been 22 appeals to the IESG since November 2002.

>From visual inspection of the list, I think at least half are unrelated to 
document publication (PR-actions, mailing list suspensions, WG closings).
I don't know how many of the rest would have "stop this document" as part 
of their proposed remedies, but to be conservative, let's assume 10 (it's 
almost certainly less, but that will save me having to read all these 
appeal texts to figure them out).

In November 2002, RFC 3323 was published; we're now at RFC 5092 - more than 
1700 RFCs later.

Based on the past record, we're talking about something that happens 0.58% 
of the time, or less.

Of course, predicting the future from the past is iffy; there have been 10 
appeals in 2006 and only one (not document related) in 2007, so "it varies".

                      Harald

---

From: John C Klensin <[email-masked]>
Date: Sun, 02 Dec 2007 11:13:28 -0500

--On Sunday, 02 December, 2007 14:56 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> Based on the past record, we're talking about something that
> happens 0.58% of the time, or less.
> 
> Of course, predicting the future from the past is iffy; there
> have been 10 appeals in 2006 and only one (not document
> related) in 2007, so "it varies".

But, at least for me, trying to make very specific rules for
something that occurs less than 5 or 10% of the time and, even
then, involves case by case idiosyncrasies, is just a bad idea.
And, if you are seeing circa 6 tenths of a percent, I believe
that the order of magnitude difference  between that and my
quite subjective criterion is more than enough to account for
variability.

If nothing else, if we have that little percentage experience,
there is little with which to evaluate the effect of any
possible rules.

Of course, YMMD and, in particular, you might consider this
potential problem to be important enough to have other criteria.

     john

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 2 Dec 2007 18:49:22 +0100

> potential problem to be important enough to have other criteria.

The "enhanced NOOP" discussion on the SMTP list just reminded me
that we're talking about protecting IANA, RFC editor, and Trust
from legal enforcement.

 Frank

---

From: Bob Hinden <[email-masked]>
Date: Sun, 2 Dec 2007 10:38:08 -0800

Harald,

> Of course, predicting the future from the past is iffy; there have  
> been 10 appeals in 2006 and only one (not document related) in  
> 2007, so "it varies".

Thanks for looking at the data.

It seems to me that we shouldn't be delaying all new RFCs for a  
problem that only occurs .58% of the time.

Bob

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 2 Dec 2007 11:12:28 -0800

> that we're talking about protecting IANA, RFC editor, and Trust

I'm late getting into this discussion, but also have the advantages  
of seeing arguments on all side at once :-)

it seems to me that the final decision on this issue would be a  
tradeoff in a multi-dimension space:
- how much gain vendors/users may get from publishing an RFC at time=T
   vs at (T + 2 months)
   in particular if the publication is tagged with some provisional  
clause.
- how strong is the desire of wanting the published RFCs to be stable
   (i.e. minimizing the chances of reclassification, with an  
understanding
    that we cannot completely eliminate the chance)
- As pointed out above, what may be the legal complication, if there  
is any,
   in handling appeals against a published RFC, and remedy the situation
   when an appeal succeeds.

I too first thought that the process ought to be optimized for the  
majority cases.  I now realized that the optimization should be based  
on the weighted percentages:

    (% of no-appeal cases) X (gains from publishing 2-month earlier)

versus

    (% of appeal cases) X (chance of an appeal succeeded)
                        X (cost from any potential legal complications
                           and remedy)
The remedy here may also include the cost to those people who acted  
on a published RFC in its first 2 months.

so the question to me is really: can we quantify the values of those  
weight factors?
(as an academic I dont have a lot clue here)

Lixia

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 2 Dec 2007 22:55:02 +0100

Lixia Zhang wrote:

> - how much gain vendors/users may get from publishing an RFC at 
>   time=T vs at (T + 2 months)

For T = (timestamp of approval) the publication will be at time
(T + x), and (T + x) > (T + 2 months) is by definition irrelevant.

With John's proposal "six weeks" it could be minimally faster,
but as he and others said, it makes no sense to change the rules
for a gain of about three weeks.  Implementors are not forced to
wait for the RFC number, they can start whenever they feel like
it.  

Harald's approximation of 0.6% was already very pessimistic, e.g.
he didn't aggregate the numerous "I really don't like RFC 4646"
appeals, and more important, he didn't count successful appeals
affecting "early" implementors in some way.

> The remedy here may also include the cost to those people who
> acted on a published RFC in its first 2 months.

Yes, or months earlier, for the case I have in mind more than
two years, millions of users, and a bunch of implementations.
Most happily ignoring the eventual "opt-out" remedy, I guess.

> so the question to me is really: can we quantify the values
> of those weight factors?

The damage can be significant (e.g. commercial implementation
ending up in /dev/null), harmless (e.g. if mail vanishes in
a black hole created by RFC y), or disastrous (same scenario
with an important mail).

 Frank

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 2 Dec 2007 14:36:15 -0800

Sorry for the complete change in subject, but I think it's important  
to avoid confusion here:

On 1 dec 2007, at 12:22, Frank Ellermann wrote:

> Disclaimer, I like Excel

What are you trying to say here?

There never was a februari 29 in 1900 so giving that non-existant day  
a number would be problematic. From your statement, I assume there is  
a standard that does this, but I'm not sure which one and why. Could  
you enlighten us?

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 3 Dec 2007 01:28:47 +0100

Iljitsch van Beijnum wrote:

> Could you enlighten us?

Really, no :-)  You could check what's really going
on, grab a copy of ECMA 376 and tell us what it says.
Maybe try your luck at <http://www.noooxml.org/1900>. 

With Redmond it's as with spammers, the one thing 
that's worse than spammers are the anti-spammers.

 Frank

---

From: Norbert Bollow <[email-masked]>
Date: Mon, 3 Dec 2007 12:19:07 +0100 (CET)

> a standard that does this, but I'm not sure which one and why. Could  

I'm not sure how much enlightenment is possible with regard to such
a silly issue, but having participated in the discussion of this issue
in the concerned "standardization committee" of the Swiss Association
for Standardization, I'm able to provide a bit of background
information:

First of all, I wouldn't call the OOXML specification a "standard"
("Ecma-glorified documentation" would be a more fitting description of
what it really is, IMO), but it is true that the OOXML spec requires
the famous one-off bug in the "common day and time representation" for
weekdays and day numbers for all days before March 1, 1900 which can
be represented at all in that "common day and time representation"
(days before January 1, 1900 are not allowed at all).

The justification which Microsoft gives for this quirk is that they
don't want to fix this bug because they consider it unacceptable to
break "Excel" macros which rely on the buggy behavior.

Also, Microsoft points out that besides the "1900 base date system"
which has this bug, the OOXML spec provides an alternative, called
the "1904 base date system" which avoids the bug, at the cost of
disallowing all dates before January 1, 1904.

Of course, if the goal had been to produce a reasonable standard, they
could simply have re-used an existing standard date representation
format, or they could have defined a new one which is able to express
all valid dates of the Gregorian calendar without such a one-off bug,
and they could have introduced a "legacy behavior compatibility mode"
for macro execution which reproduces the buggy behavior.

The one-off bug in the first two months of the year 1900 may not be
a big problem for most of Microsoft's customers, but it becomes a
serious issue when someone who considers OOXML to be a standard wants
to represent earlier dates in a way which is compatible.

In the discussions in the Swiss Association for Standardization,
Microsoft expressed willingness to agree to a reasonable comprimise
regarding this point, namely to deprecate that "1900 date base system"
which has that bug, and to recommend for general use the modification
of the "1904 base date system" that is obtained from the system
described in the OOXML spec by dropping the restriction that the day
number must be positive.

By the way, there is another serious issue with OOXML's "common day
and time representation" format: Regardless of the base date, that
day and time representation is fundamentally broken on all days which
are 23 hours or 25 hours long rather than the usual 24 hours.  (In
many countries that occurs twice per year, due to switching to DST or
back.)  Regarding that issue Microsoft did not express any willingness
to compromise.

Shortly after the meeting in which these discussions were held, a very
large number of Microsoft "certified gold partners" joined that
"standardization committee", admittedly encouraged to do that by
Microsoft corporation, all of them voting for the viewpoint that the
OOXML spec is fine as-is for approval as an international standard,
without any need for discussion or fixing of the various technical and
other issues that had been raised about OOXML.  So many of them joined
that they reached 3/4 majority, thereby rendering the previous
technical discussion essentially irrelevant.

Greetings,
Norbert.

-- 
Norbert Bollow <[email-masked]>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org

---

From: "Tom.Petch" <[email-masked]>
Date: Mon, 3 Dec 2007 10:09:30 +0100

----- Original Message -----
From: "Lixia Zhang" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, December 02, 2007 8:12 PM
Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?

<snip>
> on a published RFC in its first 2 months.
I agree completely.  When I am involved in risk analysis, the really nasty cases
are 'probability low, impact high' - will the first nuclear bomb set off a chain
reaction which destroys the world? unlikely but somewhat devastating if so.  I
see the withdrawal of approval by the IESG as risk analysis; whether it happens
10% or 0.1% of the time, whether it happens on account of an appeal or because
of some other reason is immaterial if the potential adverse impact is high
enough.

At the same time, I see the benefits of having the RFC now rather than in
February as minimal; early adopters adopt early and are proud to announce in
their marketing material that their product conforms to I-D
draft-ietf-wg-enhanced-protocol.  The date of the arrival of an RFC is irelevant
to them.

The I-Ds that concern me most are those that may have had little exposure, for
which that lack of exposure means that potentially show-stopping issues have yet
to emerge.  So one compromise would be to allow quicker publication of those
I-Ds that have had wide exposure, that have been discussed on an IETF mailing
list, so that at IETF Last Call it is feasible to look at the mailing list
archive to see what has arison, but keep the 60 day delay for individual
submissions, or for I-Ds that do not get an IETF Last Call.

Tom Petch

> (as an academic I dont have a lot clue here)
ps No, in my experience of risk analysis - each participant uses their gut
feeling and the chair declares rough consensus.

---

From: "Daniel Brown" <[email-masked]>
Date: Mon, 3 Dec 2007 10:28:12 -0500

> Most happily ignoring the eventual "opt-out" remedy, I guess.

    Conversely, why not allow a Draft to be published as an RFC in
that six-week period if there are no arguments or appeals, whereas an
appeal could potentially (a) restart the six-week clock, or (b) extend
the period from 42 to the full sixty days?

    Though again, it would be changing the rule for less than a 50%
gain in minimum time to publication.  I just thought I'd toss the idea
out there.

-- 
Daniel P. Brown
[office] (570-) 587-7080 Ext. 272
[mobile] (570-) 766-8107

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 03 Dec 2007 19:40:59 -0800

--On 3. desember 2007 10:09 +0100 "Tom.Petch" <[email-masked]> 
wrote:

> February as minimal; early adopters adopt early and are proud to announce
> in their marketing material that their product conforms to I-D
> draft-ietf-wg-enhanced-protocol.  The date of the arrival of an RFC is
> irelevant to them.

The people who actually care about whether something is an I-D or an RFC 
are the people who write specifications (other bodies' standards, RFPs, 
government mandates.... wherever they need a stable identifier).

For the implementors, an I-D + the fact of approval is sufficient. For 
those who write other documents, it's not - they need the RFC number.

              Harald

---

From: "Tobias Gondrom" <[email-masked]>
Date: Wed, 5 Dec 2007 01:13:05 +0100

Comment: For some implementors only peripherally involved with IETF
standards and process but looking at the new RFCs as "news" on standards
it is well a difference whether its an RFC at the time they look or not.
They just wouldn't know about an informal status as "being approved to
be released shortly". 

However, I want to say that I find it excellent that the RFC Editors did
make their job so good that we actually have the chance to have this
"problem discussion". 

Maybe a quite pragmatic approach:
Yes, RFC Editor should hold back until end of formal period for appeals,
but how about just shortening that period to about 45 days instead of
60?

Tobias

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: Monday, December 03, 2007 7:41 PM
> To: Tom.Petch; Lixia Zhang
> Cc: [email-masked]
> > At the same time, I see the benefits of having the RFC now rather
than
> in

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 5 Dec 2007 03:23:57 +0100

Tobias Gondrom wrote:

> They just wouldn't know about an informal status as "being
> approved to be released shortly". 

That's a feature, "approved" isn't necessarily related to
"be released shortly", it can take years (or forever) to
resolve all normative references to not yet approved I-Ds.

> how about just shortening that period to about 45 days 
> instead of 60?

That's what John proposed (well, he said 42 days), but it
would be a huge effort to change the rules only for this
minimal effect.  Doing it together with something that's
worthwhile like Brian's deconstruction of RFC 2026 could
make sense.

 Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 05 Dec 2007 13:37:05 -0800

On 2007-12-02 10:38 Bob Hinden said the following:
...
> problem that only occurs .58% of the time.

+1

	Henrik

---

From: Loa Andersson <[email-masked]>
Date: Wed, 05 Dec 2007 22:54:37 +0100

hmmm...

>> problem that only occurs .58% of the time.

so if we are talking about "all" documents; what is the percentage
that is (could be) actually published before 60 days and how many
days before day 60 is that (typically)

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

---

From: JP Vasseur <[email-masked]>
Date: Wed, 05 Dec 2007 19:22:09 -0800

+1

> From: Henrik Levkowetz <[email-masked]>
> Date: Wed, 05 Dec 2007 13:37:05 -0800
> To: <[email-masked]>
> Cc: <[email-masked]>, ietf <[email-masked]>, iesg <[email-masked]>