Subject: RE: [Fwd: IETF Process discussions - next steps]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 25 Aug 2006 13:47:42 -0700

It is still unclear to me what the proposed course of action is.

The current situation is not acceptable. HTTP is by any rational definition a standard. Yet according to the process document it is merely a draft standard.

I therefore declare the process document to be a silly thing which is clearly at odds with reality and is being ignored.

There are only two paths forward that I consider sustainable

1) The IESG catches up on the backlog of declaring draft standards to be standards.

2) The IESG proposes a process for doing this.

At present the IESG is approving an average of less than one protocol a year as a standard. And of the recent choices only the URI spec is of first rank significance.

At the moment the IESG is simultaneously failing to do its function under the present process and refusing to allow its function to be changed under a new process.

Empirically we have a two stage process. The fact that IP over NetBios is a 'standard' and HTTP 1.1 is not demonstrates the lack of a correlation between the standards status and the deployment status. 

If you look at what is actually accepted as a standard it is quite interesting. Most are protocols that are functionally obsolete such as IP over OSI, or irrelevant (Echo, chargen, quote of the day. FTP, Telnet). FTP and Telnet both lack an acceptable security layer and should be considered HISTORIC.

The obsolete version of SMTP is considered 'standard'.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Friday, August 25, 2006 7:17 AM
> To: IETF discussion list
> Subject: [Fwd: IETF Process discussions - next steps]
> 
> I was quite surprised to discover that this message is not in 
> the mailing list archive, so I am repeating it.
> A copy certainly reached the newtrk WG prior to its closure.
> 
> -------- Original Message --------
> Subject: IETF Process discussions - next steps
> Date: Thu, 10 Aug 2006 11:41:47 +0200
> From: Brian E Carpenter <[email-masked]>
> Organization: IBM
> To: IETF discussion list <[email-masked]>
> 
> Here are my conclusions from the plenary discussion and the 
> General Area open meeting at IETF 66.
> 
> 1. Conclusions from plenary discussion on Newtrk issues
> (draft-carpenter-newtrk-questions-00.txt)
> 
> A clear theme in the plenary discussion in Montreal was 
> "declare victory."
> Unfortunately, in reading the notes and listening to the 
> audio recording, and reading subsequent emails, it is also 
> clear that different speakers meant different things by this 
> phrase - anywhere from clarifying today's standards track, 
> through reducing it to two or one stages, to simply sitting 
> down and shutting up. Although on the order of 40 people out 
> of several hundred in the plenary appeared to believe that 
> formal changes to the standards process should be made, and 
> some people are ready to do work (thanks!) there was no firm 
> consensus for a given direction (as there never has been in 
> the Newtrk WG).
> 
> One useful observation was that there is nothing in present 
> rules and procedures to prevent the writing and publication 
> of overview standards documents ("ISDs" in Newtrk parlance), 
> as long as they fit into RFC 2026 rules as Applicability Statements.
> 
> A need was observed for lightweight documentation of the real 
> world deployment status of individual standards, as concrete 
> feedback from running code. Again, no rule prevents this 
> today, but neither do we have guidelines as to the format, 
> status and indexing of such documents.
> 
> My conclusions are that:
> 
> 1.1. There is insufficient pressure and energy in the 
> community to justify the effort of reaching consensus on 
> formal changes to the standards process at this time.
> 
> 1.2. For complex standards where a normative or informative 
> overview document would be beneficial, nothing in today's 
> rules and procedures prevents interested parties from writing 
> and submitting such documents within the rules set by RFC 
> 2026, and such efforts should be welcomed.
> 
> 1.3. The community should be encouraged to produce 
> documentation of deployment and interoperability of 
> individual IETF standards, even if there is no proposal to 
> advance them on the standards track.
> Such documents should be directed towards efforts to update 
> IETF standards and/or to document errata and operational issues.
> A more systematic framework than today's implementation 
> reports would be beneficial.
> 
> 1.4. The newtrk WG should be closed.
> 
> 2. Conclusion from GenArea mini-BOF on IESG structure and charter.
> 
> It seemed clear in the room that people felt there was not a 
> serious enough problem with RFC 3710 to justify a significant effort.
> There was some support for undertaking at least the first step:
>   * List Tasks that Currently Gate on the IESG in order to 
> document whether there is in fact a problem worth solving.
> 
> My conclusion is to ask John Leslie to lead a small team to 
> carry out this very specific task for the information of the 
> community.
> 
> 3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418)
> 
> It seems there is some feeling that the RFC is beginning to 
> show its age, and would be worth updating.
> 
> My conclusion is that the best first step is to ask Margaret 
> Wasserman to lead a small team to survey participants and 
> build a list of issues that need updating. Of course, any 
> actual update to RFC 2418 would then have to follow normal 
> IETF consensus process.
> 
> 3. Conclusion from GenArea mini-BOF on mailing list 
> management procedures.
> (draft-galvin-maillists-00.txt)
> 
> It seems clear from recent experience with RFC 3683 that 
> something needs to happen in this area and that feelings run 
> deep on this issue.
> However, the energy to work on this in the community is 
> limited despite some support in the mini-BOF for doing so.
> 
> My conclusion is, as experiments under 
> draft-hartman-mailinglist-experiment
> are possible immediately, there is no urgency to start an 
> organized effort right now - but it should be considered over 
> the coming months. Meanhwile I would like to ask Jim Galvin 
> to update his draft according to the discussion, for future reference.
> 
> A suggestion was made during the meeting to rapidly declare 
> RFC 3683 obsolete.
> 
>      Brian Carpenter
>      General Area Director
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 26 Aug 2006 16:22:22 +0200

Hallam-Baker, Phillip wrote:

> HTTP is by any rational definition a standard.

It's the only RFC I've heard of with outsourced errata.
It needs fixing to be published as full standard.
 
> The obsolete version of SMTP is considered 'standard'.

For the state of the actual SMTP look into your inbox.
It also has a lot of errata, some only collected in an
unpublished draft at the moment.

Procedural improvements could start with the "errata"
procedure, it's a bit slow.  Obvious typos submitted by
an original author shouldn't take two years.

Or another "decruft" experiment, that worked well.  One
of the submitted pending errata mentioned several RFCs
which could now be moved to "historic", because they
depend on RFCs cleaned up in the first "decruft" round.

A minor point could be to sort BCPs in "technical" and
"admin".  The "ION" experiment is promising.

Brian's proposal to extract the "appeal" stuff from 2026
was also good.

Frank

---

From: Eliot Lear <[email-masked]>
Date: Sat, 26 Aug 2006 16:41:08 +0200

Frank,
> It needs fixing to be published as full standard.

I don't know what this means and I would be curious as to what needs
"fixing" before it becomes a full standard, because, as you say for SMTP
below, look in your browser.  It's what's there and it clearly works for
a vast number of applications, as opposed to SNMPv3, which has barely
been deployed compared to v1, and yet it is a full standard.

> unpublished draft at the moment.

I would also be curious as to what the errata here are.  Long hard work
went into 2821 to correct known problems.  Not saying that something
wasn't missed, but I'd be curious as to what it is.
> depend on RFCs cleaned up in the first "decruft" round.

Define "depend", please.

Eliot

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Aug 2006 06:58:30 +0200

Eliot Lear wrote:

> I would be curious as to what needs "fixing" before it
> becomes a full standard

The issues you find when you enter "2616" in the form at
http://www.rfc-editor.org/errata.html  That sends you to
the outsourced http://purl.org/NET/http-errata

> as you say for SMTP below, look in your browser

My browser is much older than 2004 (the date of the last
addition to these errata).  Today we'd replace 2396 by
3986 (a tricky issue, because appendix D.2 in 3986 is a
dark corner wrt "non-uric", but that's precisely the point
needed elsewhere incl. the 2616 errata).

Updating 2616 to state of the art 3986 is more difficult
than 2396, but of course we'd now want 3986.

The 1766 reference has to be fixed to state of the art
3066 (or rather 3066bis when that got its number, but
the 2016-ABNF bug isn't affected by this transition).

> it clearly works for a vast number of applications

It "should" break for some registered 3066 language tags
like de-CH-1996, because 1996 is not 8*ALPHA, as noted
in these errata.

Of course a minor point, and most 2821 errata are also
rather harmless (once you know where they are).  Maybe
it's only me, I thought it's the purpose of the three-
stage procedure to fix such issues.  Because getting
it right immediately is an exception, and getting it
right in three steps is already optimistic.

> Long hard work went into 2821 to correct known problems.

Try the URL mentioned above and enter 2821.  Some issues
fixed in the 2821bis draft, some missing, others are not
formally listed as errata, but you could find them in the
SMTP list archive (some weeks in 2005).

You've to read 2821 very often to find the most important
point between the lines, not mentioned clearly:  _Never_
accept mail unless you're sure that you can deliver it or
bounce it to the originator (which is today rarely related
to anything you see in the MAIL FROM).

Otherwise, following the official 2821 rules, what you do
would be net abuse by design:  Either you drop accepted
mail silently, or you bounce it to innocent bystanders.

Unlike the old 821 SMTP, where it still worked as designed.
Of course 2821 couldn't fix 1123 5.3.6(a) anymore, but at
least 2821bis has to document it very clearly.

Between the lines, "let's assume the MAIL FROM is related
to the originator", won't fly, that's not true anymore for
several years now.

We could as well "assume" that sending passwords as plain
text is no problem, because eavesdropping is cheating and
out of scope for Internet standards.

>> One of the submitted pending errata mentioned several
>> RFCs which could now be moved to "historic", because
>> they depend on RFCs cleaned up in the first "decruft"
>> round.

> Define "depend", please.

For new RFCs I'd define it as "normative reference", but I
can't tell what the submitter had in mind, you find his mail
(among dozens from the same contributor) in the pending
errata archive:

ftp://ftp.rfc-editor.org/in-notes/pending-errata/pending-errata.msgs

After I saw that he sent a CC: to the decruft-authors I did
not check his details.  Possibly his definition of "depend"
won't match your or my definition.

Frank

---

From: Eliot Lear <[email-masked]>
Date: Sun, 27 Aug 2006 09:56:36 +0200

> the outsourced http://purl.org/NET/http-errata

I now understand what you mean by outsourced.  Most of these comments
are truly editorial in nature, but that happens with FULL standards as
well.  See, for instance, 3414.

> SMTP list archive (some weeks in 2005).

All of those are typos that people can work around without great

> to the originator", won't fly, that's not true anymore for

There are many instances when an MTA can and should accept mail when it
is not known to be deliverable.  The most obvious example is when it is
acting as an MSA.  And I do not understand why you believe that it is
rarely if ever related to the originator.  It is certainly the case for
nearly every mail I send or receive.  The only question is who is the
originator in the case of mailing lists, and that is well covered. 
Mailing lists SHOULD modify the mail from because the originator in
those cases may have no responsibility for having sent the mail to the
address that caused the error.

Are you saying that RFC 2821 inadvertently perturbs this behavior?

Eliot

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 27 Aug 2006 13:13:49 +0200

Eliot Lear wrote:

> I now understand what you mean by outsourced.

Sorry if that was unclear, I meant "errata not maintained by
the RFC editor".

> Most of these comments are truly editorial in nature, but
> that happens with FULL standards as well.

Agree, but while it's no full standard it would be integrated,
the differences between 4409 and 2476 (or 4234 and 2234) are
also mainly editorial.

For 4422 they stayed at PS, maybe they considered the changes
as too substantial.  2396 and 3986 on the other hand were
promoted on standards track, although the ABNF was rewritten
from scratch twice.  Maybe ABNF changes are considered as
irrelevant.  One obscure <toplablel> killed, good riddance.

 [2821]
> All of those are typos that people can work around without
> great difficulty.

Yes, but at some point in time I hope we nail this <toplabel>
issue.  To some degree 3696 already does this, but it's "only"
prose, it doesn't offer "updates 1123 2.1 and 1034", and it
should be a BCP or on standards track.

> There are many instances when an MTA can and should accept
> mail when it is not known to be deliverable.  The most
> obvious example is when it is acting as an MSA.

ACK, when it knows that MAIL FROM and originator are related,
e.g. an MSA implementing 4409 6.1, it can accept the mail for
forward or delivery.

> It is certainly the case for nearly every mail I send or
> receive.

For the latter you're apparently behind a good spam filter and
never see the 84% spam.  Insert your favourite number, I don't
insist on 84%.  I also don't insist on 11% misdirected bounces.

My personal inbox statistics would be more like 98 +1 +1%, but
that's skewed by several factors, almost no mailing lists, no
identified worms, most phishes only arriving as "we've deleted
something" info, and SPF.

Details for the SMTP list, 2821 can't be promoted on standards
track as is.  We've got a full standard working in theory, but
not more used as designed, a PS not working as designed, but
used almost everywhere, and an experiment fixing it for those
who want it (in essence the least common denominator of the
STD and the PS, offering hints when accepting mail from unknown
strangers should work as in the "good old times" before spam).

> Mailing lists SHOULD modify the mail from

Yes, 1123 5.3.6(b) and other 5.3.x are fine, only 5.3.6(a)
doesn't work as expected without source routes.  Apparently
the spammers needed some years to figure this out, it wasn't
as bad as today when 2821 was published.  But the whole spam
problem isn't as old as RFC 1123, when did this plague start,
199x in Usenet ?

Frank