Subject: [yam] [Fwd: RFC 5321, Erratum 1543]

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Sep 2009 10:38:24 +0100

John suggested that I forward this to the YAM mailing list.

Subject: RFC 5321, Erratum 1543
From: Alexey Melnikov <[email-masked]>
To: John C Klensin <[email-masked]>
Date: Sun, 06 Sep 2009 19:48:35 +0100

John,
Can you tell me if you think this one is correct?

> Reported By: Brett Watson
> Date Reported: 2008-10-08
>
> Section 3.8 says:
>
>   SMTP clients that experience a connection close, reset, or other
>   communications failure due to circumstances not under their control
>   (in violation of the intent of this specification but sometimes
>   unavoidable) SHOULD, to maintain the robustness of the mail system,
>   treat the mail transaction as if a 451 response had been received and
>   act accordingly.
>
>  
>
> It should say:
>
>   SMTP clients that experience a connection close, reset, or other
>   communications failure due to circumstances not under their control
>   (in violation of the intent of this specification but sometimes
>   unavoidable) SHOULD, to maintain the robustness of the mail system,
>   treat the mail transaction as if a 421 response had been received and
>   act accordingly.
>
>  
>
> Notes:
>
> SMTP clients are told to act as though a 451 response ("Requested 
> action aborted: local error in processing") had been received when 
> context clearly indicates that a 421 response ("Service not available, 
> closing transmission channel") was intended.
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 7 Sep 2009 11:20:26 -0400

>> SMTP clients are told to act as though a 451 response ("Requested action
>> aborted: local error in processing") had been received when context clearly
>> indicates that a 421 response ("Service not available, closing transmission
>> channel") was intended.

I think you can argue either way (we don't know why the problem
occurred), and I think it doesn't matter.  In any case, it's a 4xx
error.

I think we should leave well enough alone and not change it now.

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 Sep 2009 19:44:09 +0200

> occurred), and I think it doesn't matter.  In any case, it's a 4xx

The difference is that a client would expect the connection to be 
still open after a 451 error. Normally, a compliant client should at 
least say QUIT before shutting down the connection, whereas section 
3.8 implies that this is not necessary after a 421 response. The spec 
mandates no specific behavior for 451 replies, hence the generic rules 
for 4yz replies --try again-- should apply. However, both restarting 
the command sequence or issuing QUIT on a closed connection seem 
nonsensical to me, yet that is what would formally be mandated --for 
client compliance-- in case that "451" is left as is.

I think Brett knew what he was doing when he posted that erratum. I CC 
this message to him, at any rate.

> I think we should leave well enough alone and not change it now.

IMHO that would betray the effort of maintaining errata. Isn't this 
the last chance for correcting any errors in RFC 5321?

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Sep 2009 11:02:03 -0700 (PDT)

> I think we should leave well enough alone and not change it now.

I concur. I think this errata is bogus and should be rejected.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Sep 2009 11:25:46 -0700 (PDT)

> still open after a 451 error.

No, that makes no sense at all. The error being responded here is a 
lost connection. it is therefore axiomatic that the client is dealing
with a lost connection and that isn't going to change no matter how
the error is interpreted.

To the extent parsing the details of erorr codes make any sense - it rarely
does but let's suppose there's some reason for doing it here - in the case
where a conneciton was lost it's quite simply wrong to assume that it's because
of a service interruption. The more generic "local error" is a better fit here.

> Normally, a compliant client should at
> 3.8 implies that this is not necessary after a 421 response.

I don't think it's unreasonable to expect specification readers to display at
least a tiny bit of common sense. It should be blindingly obvious that a QUIT
cannot be sent when the connection has been lost.

> The spec

Again, you're putting the cart before the horse. 

> this message to him, at any rate.

And I quite simply disagree.

> the last chance for correcting any errors in RFC 5321?

THat assumes you think this is a legitimate errata. I don't. I think the
current text is correct and the errata is wrong.

				Ned

---

From: SM <[email-masked]>
Date: Mon, 07 Sep 2009 11:48:22 -0700

At 02:38 07-09-2009, Alexey Melnikov wrote:
>>context clearly indicates that a 421 response ("Service not 
>>available, closing transmission channel") was intended.

When I first read that text, the "451" looked like an mistake as the 
behavior is similar to a 421 from the SMTP server side.  Both RFC 
5321 and RFC 2821 has the "as if a 451 response" text. That paragraph 
is not about reply codes.  It is about what action should be taken.

>occurred), and I think it doesn't matter.  In any case, it's a 4xx

Yes.

>the last chance for correcting any errors in RFC 5321?

No, as neither the review of RFC 5321, nor an Internet-Draft have been posted.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Sep 2009 22:20:29 -0700 (PDT)

> I'm looking at it from a client implementation perspective rather than one
> of semantic accuracy.

The two are one and the same. A client that implements according to inaccurate
semantics is precisely the problem that is potentially caused by changing
this text in the fashion you suggest.

> Receipt of any x21 code from the server implies that
> the conversation is over: 221 is a "normal" termination, and 421 is an
> "abnormal" termination. If the connection closes without any response code

If a connection closes without any response code, it is axiomatic that nothing
further can be sent. As such stating this aspect of 421 processing is
belaboring the obvious.

> at all, that's an abnormal termination, and the client should behave as
> though it received a 421.

No it shouldn't, and I have already explained why.

> Or, to put it another way, if an implementer were to obey my "corrected"
> text and behave exactly as though a 421 had been received, would the
> behaviour be correct?

Possibly not, which is why the corrected text is wrong. Again, while cases
where looking at anything but the first digit are pretty rare, they do exist.

One possibility that comes to mind here is error reporting. Reporting an
abnormal connection closure as a service outgage misses the very real
possibility that the problem is in the network and not related to the service
at all.

> If the behaviour is correct, then my "correction" is
> at least reasonable, and probably a slight improvement over the existing
> text, if perhaps not completely necessary. If the behaviour is not correct,
> then correct behaviour is not clear (to me) from the text of the RFC, and
> some sort of clarification is necessary.

This is all contigent on the beahvior according to the current text being
incorrect, which it isn't, and the behavior according to your new text
being correct, which is also isn't.

Againm, I reject the notion that we need explicicly state that that the proper
behavior when a connection is terminated is not to send anything. If
implementors really do need this level of mollycoddling in the specification
we're in very deep glue that no amount of tweaking of this text is going to
fix.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Sep 2009 23:27:03 -0700

>>>> closing transmission channel") was intended.
...
>> The difference is that a client would expect the connection to be still
>> open after a 451 error.
> 
> No, that makes no sense at all. The error being responded here is a lost 
> connection. it is therefore axiomatic that the client is dealing with a lost
> connection and that isn't going to change no matter how the error is
> interpreted.
...
>> The spec mandates no specific behavior for 451 replies, hence the generic
>> rules for 4yz replies --try again-- should apply. 

As with Ned, I like to think that successful implementations rely on intelligent 
implementors.  No spec of anything interesting allows entirely mechanical 
implementation.  So it's not a stretch to rely on the common sense Ned cites.

The actual error is a lost connection.  The implementor knows this, and isn't 
required to forget it when applying the spec's guidance for how to handle it.

Absent an error code that says "the network disappeared", which maps better, 
given the 4xx high bit already meaning temporary problem:  "action aborted" or 
"service unavailable"?

My immediate reaction to "service unavailable" is that it isn't run on the 
remote host.  That's a rather deeper problem than is meant here.

I'd rather play off of an "aborted" interpretation.

And, yeah, as noted, anything this subtle and lacking massive community reports 
of problems, should be left alone.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brett Watson <[email-masked]>
Date: Tue, 8 Sep 2009 12:53:30 +1000

2009/9/8 Ned Freed <[email-masked]>

of semantic accuracy. Receipt of any x21 code from the server implies that

behaviour be correct? If the behaviour is correct, then my "correction" is

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Sep 2009 11:45:53 -0400

--On Monday, September 07, 2009 22:20 -0700 Ned Freed
<[email-masked]> wrote:

> This is all contigent on the beahvior according to the current
> text being incorrect, which it isn't, and the behavior
> according to your new text being correct, which is also isn't.
> 
> Againm, I reject the notion that we need explicicly state that
> that the proper behavior when a connection is terminated is
> not to send anything. If implementors really do need this
> level of mollycoddling in the specification we're in very deep
> glue that no amount of tweaking of this text is going to fix.

While I basically agree with Ned's reasoning, which is also
consistent with my memory of how the text got to be the way it
is, let me add one more observation to this thread...

RFC 5321 makes a very specific provision for 421 codes that
applies _any time_ the connection needs to be shut down.  The
text says:

#   In addition to the codes listed below, any SMTP command
#   can return any of the following codes if the
#   corresponding unusual circumstances are encountered:

#  [...]

#   421 Service shutting down and closing transmission channel

So, if the channel shutdown is actually initiated at the server
end and the server knows that the primary issue, in its opinion,
is the shutdown, it is free to return a 421 instead of a 451.
That turns Brett's argument from "permit 421 where that makes
sense" (which is in the spec now) to somehow prohibiting the use
of 451.  That doesn't work -- not only because of all the
reasons suggested in several notes but because the history of
returning 451 implies that clients will always need to be able
to accept both codes -- the 451 because that is what is
specified and the 421 because "shutting down" is always possible.

    john

---

From: Brett Watson <[email-masked]>
Date: Wed, 9 Sep 2009 01:50:17 +1000

> No it shouldn't, and I have already explained why.

The explanation went over my head, frankly, but if y'all say the original is
right and my version is wrong, then consider my erratum retracted.

And, having no further business here, I bid you all adieu.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 08 Sep 2009 18:05:26 +0200

Ned Freed wrote:
> where a conneciton was lost it's quite simply wrong to assume that it's 
> because of a service interruption. The more generic "local error" is a better 
> fit here.

I cannot understand in what cases a lost connection wouldn't imply a 
service interruption. OTOH, as you've noted downthread yourself, the 
error is not necessary local to the server, as it might have been 
triggered at some intermediate point.

Your response lacks an analysis of the differences between 451 and 421 
from a client perspective. I think "421" is one of the cases where 
parsing the detail of the error code makes sense. AFAICU, after 
receiving 421, a client should close the connection without sending 
any further command, and assume that the operation implied by the last 
command has been aborted. For that reason, an implementation should 
check for 421 after getting a 4yz response to any command; possibly, 
it has a specific function or macro for that. What is the difference 
in treating a mail transaction wrt a 451?

> I don't think it's unreasonable to expect specification readers to 
> display at least a tiny bit of common sense. It should be blindingly 
> obvious that a QUIT cannot be sent when the connection has been lost.

I agree it's blindingly obvious. The spec would be better off saying 
nothing than challenging such an obvious fact. Challenging would be 
implicitly implied if sending that QUIT is the only difference between 
a 421 and a 451. In facts, speaking of obviousness, there is a 
paragraph at the end of section 4.1.1.5 (BTW, shouldn't that be in 
4.1.1.10?) that directs a server to behave as if that QUIT had 
effectively been sent before the connection failed.

> current text is correct and the errata is wrong.

Let me motivate why I assume that: It is more likely that an error 
slips through while editing a huge specification than while reporting 
an erratum. For this particular case, that paragraph is already 
present in 
http://tools.ietf.org/html/draft-ietf-drums-smtpupd-07#section-3.9 of 
May 20, 1998. In that version, however, 451 was the only 4yz code 
mentioned in section 3.9; for example, the server was supposed to 
intentionally close a connection
   o After detecting the need to shutdown the SMTP service and
     returning a message with a 451 response code.  This response
     code can be issued after the server receives any command or, if
     necessary, asynchronously from command receipt (on the
     assumption that the client will receive it after the next
     command is issued).

Later, draft-ietf-drums-smtpupd-08 has had all "451"s in that section 
substituted with "421", _except the last occurrence_. The X.1.8 
appendix in the latter document simply says "Error code presentation 
has been restructured." I've searched the DRUMS mail archive, but 
found no confirmation that such omission had been intentional. Do you 
recall discussions about such 451 vs 421 issue?

IMHO, If it was a typo, it should be corrected. Of course, the WG may 
acknowledge that (i) it has remained unnoticed for ten years, and (ii) 
implementers can easily resolve it using some common sense, and 
conclude that for such reasons it is not worth to correct it.

---

From: Ned Freed <[email-masked]>
Date: Tue, 08 Sep 2009 10:20:59 -0700 (PDT)

> service interruption.

How about pulling out the network plug on the cllient system? The service is
fine, only this one client is disconnected.

> OTOH, as you've noted downthread yourself, the

And the service could still be working. It's also possible for a particular
connection to fail for some reason but for the service to still be available
for subsequent connections. This sort of one time transient failure happens all
the time when firewalls are reset; flagging such cases as service
interruptions, as a 421 code would imply, is bogus.

> parsing the detail of the error code makes sense.

I actually kind of doubt that, but it's precisely such analysis that goes wrong
with the assumed code is 421, not 451.

> AFAICU, after
> command has been aborted.

I just don't get why this is so hard to understand. The connection has failed.
Irrespective of what error code the server assumes this corresponds to for
purposes of dealing with any failed transaction, sureiy it ot obvious to anyone
with even a tenth of a brain that their client should not attempt to send
anything in this case.

Unless you can find some text in RFC 5321 that says clients MUST send a QUIT
before closing a connection unless they recive an effective 421 response, this
is a total nonissue. And if such text exists, that's the text that should be
changed, not this.

> For that reason, an implementation should

I have already given examples of possible  differences.

> a 421 and a 451.

Not only is it not the only difference, absent your finding the text I
described above it is not a difference period.

> In facts, speaking of obviousness, there is a

> conclude that for such reasons it is not worth to correct it.

I could not care less what thie history here is. You need to justify this on
the basis of what the document currently says, not what it did or didn't say at
some point during it's evolution.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 Sep 2009 12:46:40 +0200

Ned Freed wrote:
> How about pulling out the network plug on the cllient system? The 
> service is fine, only this one client is disconnected.

Thus you assume that a 421 interruption to one client implies that any 
other connected clients are being interrupted as well.

> This sort of one time transient failure happens all 

For the sake of this discussion, consider building a dummy client 
whose purpose is monitoring service levels of a given servers. It just 
loiters about, issuing NOOPs or starting some transactions that it 
eventually RSETs, taking care not to exceed timeouts. When it sees a 
421 it closes the connection and starts accounting server's downtime. 
However, when the connection fails abruptly it just tries to 
reconnect, without adding connect time to the count. Would that work 
correctly?

> is a total nonissue. And if such text exists, that's the text that should be 

Hm.. the current wording goes just like you say

           The sender MUST NOT intentionally close the transmission
  channel until it sends a QUIT command, and it SHOULD wait until it
  receives the reply (even if there was an error response to a previous
  command).

(BTW, there is no mention of 421 responses in section 4.1.1.10.)

That text actually implies the client MUST send a QUIT even after the 
connection failed. This may seem unfair in case the client received an 
intentional abrupt TCP-RSET from the server, i.e. the server is 
shutting down the connection without a prior 421 (in violation of the 
intent of the specification but sometimes unavoidable). However, it 
may make sense to recommend that a client attempts to send a QUIT in 
case it is not sure about the connection status.

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Sep 2009 09:17:35 -0400

--On Wednesday, September 09, 2009 12:46 +0200 Alessandro Vesely
<[email-masked]> wrote:

> That text actually implies the client MUST send a QUIT even
> after the connection failed.

I don't think so.  Note that it says "The sender MUST NOT
intentionally close...".   It does not say "The sender MUST
notice a connection close that it does not initiate and then try
to send QUIT" or anything else inherently contradictory -- the
text applies only to sender-initiated connection closing and
requires, again for sender-initiated closes, the sequence:

   C:  QUIT
   S:  221 Ok you can close now
   C:  (close connection)

The cases under discussion all have to do with either a
server-side close or a close by someone or something in the path
other than the client SMTP software.

>   This may seem unfair in case the
> client received an intentional abrupt TCP-RSET from the
> server, i.e. the server is shutting down the connection
> without a prior 421 (in violation of the intent of the
> specification but sometimes unavoidable).

But, again, then you have a server close, not a client close.

> However, it may make
> sense to recommend that a client attempts to send a QUIT in

Well, the client either knows that the connection has been shut
down or it doesn't.   If it does know, then sending a QUIT over
the closed connection is nonsensical.  If it does not know, then
it presumably thinks it is the one doing the shutdown and either:

	Case 1: The client has already issued a command and is
	waiting for a response.  It waits for that response,
	doesn't get it, and either concludes that the connection
	has disappeared or that it really should behave as if
	the command might have gotten lost, i.e., that Case 2
	applies.
	
	Case 2: The client isn't sure that a command was sent
	and that a response is outstanding (or is sure that it
	has not).   Depending on whether it is inclined to give
	up or wants to try to keep the connection going, it
	issues either a QUIT or a NOOP, waits for a response,
	and then, if none is received, assumes that the
	connection went away through no fault of its own.

I don't see anything in  the text you quote, or elsewhere in
5321, that falls outside those two cases (plus non-SMTP
notification of connection failures), at least as far as the
client is concerned.

    john

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Sep 2009 06:57:20 -0700 (PDT)

> other connected clients are being interrupted as well.

LIke it or not, that's how it is often interpreted. And with good reason,
because it often means that in practice.

> reconnect, without adding connect time to the count. Would that work

No, but with a tiny bit of added sophistication it probably would. THe addition
that's needed is to ignore one-off connection problems but to log ones that
persist.

That said, it's an apples to oranges comparison. Such a test client is unlikely
to run into the transient sorts network problems real clients with varied
outputs do.

>   receives the reply (even if there was an error response to a previous

Nope, that's not what it says at all. As was already pointed out earlier in
this discussion, this is talking about a *client*  *intentionallyU closing a
connection. The case we're discussing  is where the connection has been
*unintentionally* closed by something *other* than the client, possibly by the
server, possibly by soome network issue.

It's basic logic. This is saying "A and B implies you must to C'. The case
we're talking about is "(not A) and (not B)'. This text says nothing about 
such a case.

I'll also point out that your "fix" to this non-problem relies on someone
tracking down the special exemption to sending QUIT provided by the 421
response. So on the one hand you're assuming that implementors are so dense and
unfamiliar with network basics they're going to read this as requring them to
perform the totally nonsensical action of sending something to a failed
connection, but on the other hand they are going to clever and dedicated enough
to track down the special meaning conferred by referencing 421 as opposed to
som other three digit number beginning with 451.

You can't have it both ways.

> (BTW, there is no mention of 421 responses in section 4.1.1.10.)

Why would there be? This section is talking about the action of the QUIT
command.

> connection failed.

Read it again. it does no such thing.

> This may seem unfair in case the client received an
> intent of the specification but sometimes unavoidable).

It's not a question of fairness, it's a question of what the specification
says. And it just doesn''t say what you claim it does.

> However, it

No network agent can ever be sure about the status of a given connection - even
if you probe it constantly it could have failed immediately after the last
probe. That said, the way most stacks work is when a network read or write
returns a fatal error the underlying connection is effectively toast.

So I'm not seeing an issue we need to deal with here either.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 Sep 2009 19:52:50 +0200

John C Klensin wrote:
>>            The sender MUST NOT intentionally close the 
>> transmission channel until it sends a QUIT command, and 
>> it SHOULD wait until it receives the reply (even if 
>> there was an error response to a previous command).
>>
> to send QUIT" or anything else inherently contradictory

It is not necessarily contradictory. Depending on the library 
interface at hand, the client may need to close a connection even 
after the server has already done so. (RFC 5321 consistently considers 
the close operation atomic, and I don't think it should dig into lower 
layers.)

> -- the text applies only to sender-initiated connection closing 
> and requires, again for sender-initiated closes, the sequence:
>
>    C:  QUIT

I guess you meant

      S:  (close connection)

The spec never contemplates the case that the sender closes the 
connection, except in the above snippet. (However, in some cases 
"connection is closed" or similar wording might imply that closing 
could have been initiated by either party.)

> the closed connection is nonsensical.

Hence, in this case only, it might act as if it received a 421?

> If it does not know, then it presumably thinks it is the one
> doing the shutdown

Or something in between...

> 	connection went away through no fault of its own.

So, if I've got it correctly, recommending the behavior for case 2 is 
what the spec means by saying that the client should act "as if a 451 
response had been received": If it had said 421 instead, then the 
client would just close the connection also in case 2. Correct? 
Frankly, that does not seem so straightforward to understand.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 Sep 2009 19:55:54 +0200

> because it often means that in practice.

Then it is an implementor's choice. Fine. Although section 7.8 
mentions that it's reasonable for the server to close the connection 
with an attacker, in that case the connection is closed without a 
prior 421 reply code (the spec only mentions 5yz replies for that case.)

> response. So on the one hand you're assuming that implementors are so 
> dense and unfamiliar with network basics they're going to read this as requring 
> them to perform the totally nonsensical action of sending something to a failed 
> connection, but on the other hand they are going to clever and dedicated 
> enough to track down the special meaning conferred by referencing 421 as 
> opposed to som other three digit number beginning with 451.
>

The same spec must still suit both developers, though. I'd point out I 
don't have a defined "fix" for this non-problem. The text would have 
been smoother with a 421 rather than 451 there. As that's not the 
case, I think the spec should explain it better, but I don't know 
myself how such a better explanation should be conceived.

One visible difference between 421 and 451 is that the former is 
explained thoroughly, while the latter is barely mentioned.

> Why would there be? This section is talking about the action of the QUIT 

No, it also goes on to discuss network failures. A complete discussion 
would result in a copy of section 3.8 (which I'm not suggesting.) 
However, a partial discussion might fool hurried readers into thinking 
  that they have got a complete self-contained picture.

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Sep 2009 11:39:52 -0700 (PDT)

> prior 421 reply code (the spec only mentions 5yz replies for that case.)

I fail to see any relevance to the present discussion.

> The same spec must still suit both developers, though.

I quite simply disagree. Paraphrasing Nero Wolfe, attempting to put sense in a
fool's brain is losing proposition and we should not be attempting to do it
here or anywhere else.

> I'd point out I

it is axomatic that text can always be improved. The question is whether it is
worth spending a bunch of time doing so. I don't think it is.

> explained thoroughly, while the latter is barely mentioned.

And I again repeat that for someone sufficiently without clue not to realize
that discussions of server behavior don't apply to clients and who doesn't
better than to send further data down a broken pipe, all the explanations in
the world of the side effects of a particular error code aren't very unlikely
to be useful.

>   that they have got a complete self-contained picture.

I'm still not seeing any reason to make any changes in any of this, and lots of
reasons not to.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Sep 2009 14:04:50 -0400

As I see it, it's clear where the consensus stands on this, and the
discussion has gone into the realm of wasting the working group's time
and effort.  I ask the chairs to declare whether they think there's
consensus on this issue, and, thus, end the discussion, or they think
more discussion is needed in order to reach consensus.

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 11 Sep 2009 08:21:11 +0200

Barry Leiba wrote:
> and effort.

I beg to disagree, because hasty dismissal of items would bring the 
risk of overlooking possible defects. I thank Ned and John for their 
in depth analysis of the issue; I don't think their time an effort 
have been wasted, as that discussion has brought more insight on 
that issue, at least to some people --me for one, but I don't think 
the rest of the public is omniscient.

>  I ask the chairs to declare whether they think there's

I've only continued that discussion until every facet of it has been 
100% clear to me --never making pretentious arguments. I regard 
myself as having any prerequisite to understand the SMTP 
specification, even if I didn't participate in the DRUMS WG, and 
hope that my comprehension of the existing text can provide useful 
feedback for writing a new I-D.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 Sep 2009 01:15:38 -0700

The YAM Working Group is following a process experiment where:

  - A review is posted with a list of proposed changes (stated in 
general terms,
   rather than specific wording)

  - The Working Group consensus is obtained

The review for RFC 5321 has not been posted.  It is not optimal to 
have discussions about the document at this stage.  If any issues are 
raised, they will be logged.  Determining what to do about the issues 
will be done when the Working Group is asked to comment on the review.

Working Group participants are encouraged to ensure that their issues 
fall within the bounds of the YAM Charter.  Given that there are 
different implementations of the specifications and they have been 
widely deployed, it is up to the person raising the issue to show 
that there is a defect.

Participants are kindly requested not to pursue lengthy discussions 
about RFC 5321 as the WGLC is for 
ietf-yam-rfc1652bis-pre-evaluation-00 and not that document.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 11 Sep 2009 06:48:21 -0700

Alessandro Vesely wrote:
> I beg to disagree, 

This is simple.  There has been extensive group discussion.  The chair has 
asserted working group consensus.

Please document the wg support you have gotten which refutes the chair's assessment.

d/
-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 11 Sep 2009 17:44:02 +0200

S Moonesamy wrote:
>  - A review is posted with a list of proposed changes (stated in general
>    terms, rather than specific wording)
>
> The review for RFC 5321 has not been posted.  It is not optimal to have 
> discussions about the document at this stage.  If any issues are raised, 
> they will be logged.  Determining what to do about the issues will be 
> done when the Working Group is asked to comment on the review.
>
> widely deployed, it is up to the person raising the issue to show that 
> there is a defect.

While that looks a sensible request, there may be cases where a 
specification contains questionable statements or omissions that may 
or may not be considered defects. It would seem reasonable in those 
cases to query for the WG's opinion, even if the issue will never 
result in a tracked defect.

> about RFC 5321 as the WGLC is for ietf-yam-rfc1652bis-pre-evaluation-00 
> and not that document.

Does that imply single-tasking, or would the process allow for more 
than one outstanding WGLC at a time?

Dave CROCKER wrote:
> This is simple.  There has been extensive group discussion.  The chair has asserted working group consensus.

I haven't seen a chair's assessment on this subject (yet.)

> Please document the wg support you have gotten which refutes the chair's assessment.

Obviously, I don't know how to fulfill the latter request, nor what 
purpose would the requested documentation serve for. Am I missing 
something?

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 11 Sep 2009 11:38:10 -0700

> I haven't seen a chair's assessment on this subject (yet.)

Yes you have, and you begged to disagree with it.

> purpose would the requested documentation serve for. Am I missing 

Yes.  You appear to be missing the basics of IETF process understanding.

d/

-- 

   Dave Crocker

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 Sep 2009 11:38:39 -0700

Hi Alessandro,
>result in a tracked defect.

The above sounds fine except that it can end up disrupting the work 
of the WG.  There's also unfortunate accidents where long-standing 
IETF participants familiar with the IETF process hand you a rope and 
you end up hanging yourself (don't read this literally).

To avoid all that, I'll stick to the guideline where the person would 
have to demonstrate that the issue is a significant technical or 
documentation defect.

>than one outstanding WGLC at a time?

Some of the WGLCs may overlap.

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Barry Leiba <[email-masked]>
Date: Fri, 11 Sep 2009 16:41:26 -0400

>> Does that imply single-tasking, or would the process allow for more than
>> one outstanding WGLC at a time?
>

I'll add to this with a general statement about how WG mailing list
discussions usually work -- I can't speak for the chairs about how
they want to run this one.

Usually, the group's work is focusing on something in particular at
the time -- it might be one document, it might be two or three -- and
the mailing list also concentrates on discussion about that current
work.

Usually, it's OK to talk about other stuff as well.  But we all have
to keep in mind what the focus is, and make sure the other discussions
don't delay progress on the primary current work.

Usually, that last is not a problem, but sometimes the chairs (or, in
this case, the secretary) will ask that we defer the other discussions
either until the current work is done or until it's specifically time
to work on what others are trying to discuss.  It's a time management
thing, in that case.

In other words, we don't usually single thread... but the chairs may
decide either to switch to single threading or to declare a specific
topic deferred, depending upon what they think will best move things
forward.

Barry

---

From: Tony Hansen <[email-masked]>
Date: Sat, 12 Sep 2009 00:17:56 -0400

I missed seeing most of this thread until today. Sorry -- I *really* 
need to get a better MUA.

The *primary* thing that this working group should be considering right 
now is the template that we are going to be sending to the IESG, and 
with it the pre-evaluation for RFC 1652.

The working group should *not* be looking at errata for 5321. It should 
*not* be looking at errata for 3798. It *should* have been looking at 
1652, whose WGLC just finished and hardly anyone deigned to respond to 
the issues that were outstanding there. (See other message coming out 
shortly.)

I am *not* going to declare any consensus on this issue -- 5321 isn't on 
my radar at this point. RFC 5321 is coming up again soon enough in our 
queue -- this topic can be revisited at that point if there is anything 
left to be revisited.

	Tony Hansen
	your usually-friendly neighborhood co-chair

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 12 Sep 2009 12:04:19 +0200

> Yes you have, and you begged to disagree with it.

Ah, then you must mean 
http://www.ietf.org/mail-archive/web/yam/current/msg00098.html; I 
thought you meant a chair's assessment :-/

>>> Please document the wg support you have gotten which refutes the 

That's simple. SM checked that wording was already in RFC 2821, Ned 
provided a deep analysis of various cases, and John gave an explicit 
description of client behavior. I don't think they would have gone 
into such level of detail if they had thought it was a waste of time 
and effort; hence their conduct supports the worthiness of duly 
clearing the errata, which was the only point I disagreed with.

> You appear to be missing the basics of IETF process understanding.

Yes, my very little IETF experience is essentially limited to 
mailing list discussions, thus your latter point may be correct. 
I've read a fair amount of procedural guides and RFCs, and make a 
good-faith effort to comply with them, though.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 12 Sep 2009 10:26:30 -0700

Alessandro Vesely wrote:
> Yes, my very little IETF experience is essentially limited to mailing 
> list discussions, thus your latter point may be correct. I've read a 
> fair amount of procedural guides and RFCs, and make a good-faith effort 
> to comply with them, though.

Perhaps you should review the repeated focus on "rough consensus".  You've been
persistent in pressing your points.  I haven't noticed your developing support,
but perhaps you have and can document it.  Failing that, yes, you are wasting
the group's time.

As for interpreting counter-postings as indicating that your points are valid or 
worthy, you would be missing the alternative explanation that the postings are 
either tutorial or defensive against /others/ taking the points as worthy.

That is precisely what I am doing with this, and my previous, posting.

I think enough of us have posted more than enough such notes.  Any more 
responses like this would, themselves, merely waste mailing list bandwidth...

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Sep 2009 12:04:31 -0400

--On Saturday, September 12, 2009 12:04 +0200 Alessandro Vesely
<[email-masked]> wrote:

> http://www.ietf.org/mail-archive/web/yam/current/msg00098.html
> ; I thought you meant a chair's assessment :-/
> 
> That's simple. SM checked that wording was already in RFC
> 2821, Ned provided a deep analysis of various cases, and John
> gave an explicit description of client behavior. I don't think
> they would have gone into such level of detail if they had
> thought it was a waste of time and effort; hence their conduct
> supports the worthiness of duly clearing the errata, which was
> the only point I disagreed with.

Oh, come on!  If we hadn't gone into that much detail, you would
be protesting that we didn't take your concerns seriously.  We
did take them seriously, especially since you invoked the errata
process (which I continue to believe was inappropriate).  In
that process, I've been told by the IETF Chair that responding
to you on the errata thread is the IESG's problem, not mine as
editor (or even the WG's), so, if you do submit further errata,
I, for one, will just ignore them.

Having taken your concern seriously, we have told you, in
several different ways and for several different reasons, that
your analysis was incorrect and that no change was justified.
It appears to be that conclusion that you decline to accept, in
spite of having gotten no support for your contrary view from
the WG.

    john