[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-fax-esmtp-conneg-10.txt
Ted,
TH> I am more than happy to be cc'ed on individual responses, I will rely
TH> on the chairs to indicate their call of the rough consensus.
Unfortunately, working group consensus cannot deal with the question
of satisfying an AD's veto.
Let me explain:
I'm one of the people who has been producing the text for the document
you want changed. Yes, some of what you want I simply disagree with.
The rough consensus process is useful for resolving such
disagreements.
However other parts of what you want I simply do not understand. I
have usually labeled such parts with text along the lines of "I do not
understand" or "please explain." For the most part, you have not
supplied such clarifications.
This is exactly the sort of IESG response that promotes working group
frustration and publication delays. It leaves IESG requirements fuzzy
and open-ended, with a good likelihood of taking a random walk,
changing the requirements further and repeatedly. Indeed, this latest
note from you shows exactly those signs.
So _you_ well might think all this is easy to resolve with working
group rough consensus, but it leaves the question of who will be able
to produce text that satisfies you.
I said "able", Ted. I did not say "willing".
Perhaps another working group participant is entirely clear about the
text that will satisfy you. I, too, hope they come forward. Anything
that gets this effort to closure would be constructive.
TH> And as I noted, you were meant to be given a pointer to that venue
TH> as the place to continue this discussion; I've already apologized that
TH> it did not happen, and I am glad now to see your concerns voiced
I'm not overly interested in expressing my concerns, and indeed that
has not been the point behind my postings to you and Scott.
My interest is in getting the document published.
Since, in fact, _you_ are the one with concerns, you should be eager
to explain them well enough for a document editor to understand them,
so that the document editor can write text that will satisfy them.
>>I think that incorporating the analytic _concerns_ of the OPES work is
>>useful, not the addition of a citation to OPES. We incorporated the
>>concerns long ago. In fact I believe there is no significant utility to
>>the citation, but it does not hurt anything to add it. It does, however,
>>hurt things to have our interactions misunderstood.
TH> Very well; does the rest of the working group concur that the analytic
TH> concerns of the OPES working group have been incorporated?
Uh oh.
Now you are saying they weren't?
You have not expressed that view before, even after several iterations
following your initial comments.
In fact your asking this question, now, is a good example of
why I am concerned about the vagueness of your feedback: You have
just altered the list of what needs to be considered, after several
rounds of discussion. This does not bode well for convergence.
Or else you have rejected my response on the matter. If the latter, I
wish you had said that sooner.
In particular, if there are OPES concepts or details that you feel the
ESMTP Conneg specification has missed, do you not think it appropriate
to cite what they are?
TH> Does the rest of the working group concur that a citation does no harm?
And here you begin a lengthy sequence of very strange questions to the
working group.
At the least, there does not appear to be any controversy that
warrants burdening the working group with a round of consensus
questions.
>>TH> but does not see the need for any text elucidating the mechanisms in this
>>TH> light.
>>
>>The specification has an obligation to be clear. It does not have an
>>obligation to include a tutorial on a general topic. In fact such
>>material is more likely to distract the implementor.
TH> And we obviously differ on exactly how much text it would take to
TH> be clear.
In fact, since you have never specified anything concrete about what
you want, here, I have no basis for knowing how much text it would
take to satisfy you.
It is encouraging to hear that you believe it is a small amount of
text. However it is not encouraging to still find no way for the rest
of us to know this.
TH> The community has expressed concern about this topic,
Huh? We went through community concerns on our spec a very long time
ago. (This document has been sitting in the AD/IESG queue since the
beginning of the year.)
What we have now is pushback from the IESG. So if there "community
concern" about this specification, please point me at it. I've tried
to be diligent in responding to such feedback.
TH> and we have a published RFC which goes to significant lengths to
TH> describe the issues.
And we went to significant lengths to review that document and to make
sure the specification dealt with the issues it raised.
And if you feel that that was not done sufficiently, Ted, you need to
explain what is missing.
Your own concerns on this are not something working group consensus
can resolve.
TH> To make a parallel: the community decided a long time ago that
TH> congestion control was a concern for any protocol that was deployed
TH> on the Internet.
TH> If you wrote an IETF specification for a protocol
TH> without such congestion control, text explaining why congestion
TH> control was not required would be expected.
Thank you for such a solid demonstration of the problem with your
comments on the specification: As you have stated them, your
assertions, above, are factually wrong.
We do not have "text explaining why congestion control was not
required" for IP, SMTP, HTTP, and so on.
And in case you think I'm being silly, then please note the similarity
in the generality and vaguess, with your above assertions, and the
ones that supposedly provide guidance to this working group.
TH> This is not tutorial
TH> (and I have no idea why you think of tutorial as a pejorative)
Given that I said tutorial are fine things, I have no idea why you
think I think of them as pejorative.
What I said was that they are not part of a specification.
TH> ; it is communication with your colleagues about the applicability
TH> and characteristics of the protocol you've specified.
The current specification already contains the usual types of material
that explain the purpose it is intended to serve.
So, again, how is one to know enough to improve that, so as to satisfy your
concerns?
Working group consensus cannot answer that question, Ted.
>>TH> The "copy of a copy" problem I mentioned above might be
>>TH> better called "transform of a transform". ...
>>TH> I did not see a way around that problem with the
>>TH> mechanisms provided nor did I see a description of it for those who might
>>TH> deploy this mechanism.
>>
>>That's why I said that adding a generic reference to the issue is
>>reasonable.
TH> Okay. Does the rest of the working group concur that including
TH> such a generic reference to the issue is reasonable?
Versus what?
>>TH> The last issue is that the document does not describe how the
>>TH> SMTP service gets CONNEG data in the first place (even at the example
>>TH> level),
...
TH> It is not clear from the above whether you object to the inclusion of
TH> the problem in the specification,
Since the document already contains:
2.2. Returning Capabilities
A target recipient device or system communicates its
content form capabilities to the SMTP service through a
means outside the scope of this specification.
The real question is what your own problem with that statement is?
Since it is common for specifications to constrain their scope
explicitly in this manner, you have not yet explained why you think it
is important to include some unknown amount of additional text,
covering material that involves a separate mechanism.
Simply posing arbitrary questions to the working group does not help
anyone to know how to resolve your current veto of the document. Your
failure to respond to my questions and comments on this suggests a
different, and more serious problem.
TH> so I'll pose the question in a slightly
TH> different way: does the working group as a whole concur that
TH> including a statement of this problem in the text is acceptable?
We seem to be heading down a path where you ask the working group
about each sentence in the existing specification, along with some
lengthy set of additional questions about things _not_ in the
specification.
It is difficult to know where this ends. It is certainly difficult to
understand how it could possibly be constructive.
You see, Ted, the working group already did its work. Quite a lot of
it, and over quite a long time. It went through all the usual and
appropriate and sufficient rough consensus steps.
At any rate, you are the one with concerns, now.
Yet none of them appear to identify any deficiencies in the technical
specification.
TH> I assume you are not proposing an independent effort to specify
TH> the rest of the system.
Again, that's not at all what I said.
However what is most interesting and problematic is that _you_ appear
to be proposing an effort to include it in _this_ specification.
TH> If the problem is clear and the working
TH> group chooses to say that the solution is not stated,
You mean, like the text that is already in the draft?
TH> I think
TH> the spec will be clear;
This means that you think it is not clear now.
Again I ask: what is not clear about the existing text?
>>Intermediaries can (and do) already mess things up.
TH> You could argue that the existence of the monkey in the middle
TH> attack obviated the need for any specification of intermediary
TH> behavior, ...
Now we are on increasingly familiar ground: I simply having no idea
what you are talking about.
TH> If we don't understand how this is expected to work on the
TH> Internet, we should say so to the community in some fashion.
Ted, no one said "we don't understand how this is expected to work".
TH> I am at a loss to understand this view of an applicability statement.
That is because applicability statements in the IETF have a long and
dubious history. Your own desire for one, here, underscores the
vagueness that usually accompanies the requirement for one. There are
exceptions, of course, but it does not look like the current situation
will be one.
TH> Does the working group as a whole concur that the inclusion of such
TH> an applicability statement would be harmful?
Harmful? where did _that_ come from?
TH> Since we have now traded some hundreds of lines of email on this
TH> topic, Dave, I think it would be fairer to say it as an effort at
TH> communication.
TH> Sorry you don't see it that way.
How can I?
You assert a desire -- which, given your veto, is really a requirement
-- and I ask you to provide detail. You don't respond with any detail.
This is not what "communication" usually includes.
TH> The working group does not decide whether to include an IESG note.
It is -- or at least used to be -- quite common for ADs with concerns
to write text that would satisfy them and then have the working group
choose to include them. Nothing requires waiting for a formal IESG
"mandate" to include text from ADs.
TH> If I wrote one (and I hope it does not come to that), it would include
TH> the fact that the working group decided not take other actions. Until
TH> the working group decides to take no action, I will not write one.
I apologize. I thought you were talking about constructive text that
would actually resolve the applicability, pedagogy, etc. concerns you
have about the specifications.
I did not realize that your text would, instead, be designed to
undermine the credibility of the specification.
>>If there is anyone else on the IESG who share your specific concerns,
>>they have not voiced them.
TH> Several agreed with these points during the call, but felt that I
TH> should hold the
TH> DISCUSS. If you would like me to ask them to put in their own
TH> DISCUSSes, I'll talk to Scott about it.
Forgive me, but I thought the new world of IESG transparency assured
us of getting clear IESG statements that are clearly labeled as to AD
source.
In fact, I thought we had gotten such feedback. As I said, I've been
trying to satisfy the concerns expressed by those comments and have
suggested a number of text segments for that purpose. If those text
changes are not satisfactory, no one has yet said so.
Your own comments have been the only exception that I am aware of, and
that is because your comments did not provide enough basis for knowing
what would satisfy your concerns.
>>I offered text intended to respond to the concerns documented from other
>>ADs and have not yet been told that those formulations are unacceptable.
>>
TH> I assume you mean Steve and Alex; perhaps Scott can help you work
TH> with them (and Joel, whom Alex had review the doc) on those issues.
You seem to think he has not already been doing that.
However, Scott is an extremely diligent guy and has already shown a VERY
consistent pattern of trying to facilitate working group process.
It's been quite refreshing, in fact.
So thanks for your concern about the processing of other AD's
comments, but you need not have worried.
d/
--
Dave Crocker <mailto:dcrocker@xxxxxxxxxxxxxxx>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>