Subject: [yam] Referencing 1652bis and update to RFC 5321/5322

From: Alexey Melnikov <[email-masked]>
Date: Sun, 27 Jun 2010 11:20:10 +0100

[Moving this discussion to YAM and changing the subject.]

SM wrote:

> At 16:17 26-06-10, John C Klensin wrote:

 [...]

>> For these and others, let's make sure we remember (the Nits
>> checker will presumably do that for us, but not actually make
>> changes until it is absolutely, 100%, clear that 1652bis will be
>> published.  In particular note that, while it is in the RFC
>> Editor queue, it is stuck in MISSREF waiting on 5321bis and
>> 5322bis, for neither of which there is even an active I-D yet (I
>> expect that will be cured for one or both before IETF 78, but
>> one should not count on that until it happens).  Also note that
>> if the IESG, in its wisdom, approves
>> draft-housley-two-maturity-levels in the next month or two, the
>> YAM WG enters the "overtaken by events" stage and 5321bis and
>> 5322bis (and probably even the supposedly-approved 1652bis)
>> become more effort than they are worth to finish.  Having the
>> distinction of being the last full standards approved by the
>> IETF under a set of rules that are being phased out does not
>> seem to me to be likely to be treated by the responsible editors
>> as worth the trouble.  That is, of course, just my opinion.
>
> I don't know what will happen to the maturity levels.  The MISSREF 
> could be cleared.

Yes, this particular MISREF can be cleared at any time by asking the RFC 
Editor to use published RFCs.

I have a more fundamental question for this WG: are people still going 
to be interested in updating various email specs if 3 muturity levels 
are replaced with 1 or 2?
(I understand that that would mean rechartering, but that is a 
relatively minor point.)

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 27 Jun 2010 11:48:21 +0100

On 6/27/2010 11:20 AM, Alexey Melnikov wrote:
>                        are people still going

That will probably depend upon wht the 2 levels re.

If the proposal being promoted by Russ is chosen, then there's nothing for this 
wg to do:  everything that is a candidate for the wg should automatically 
already be at the final level.  No?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 27 Jun 2010 11:52:16 +0100

Dave CROCKER wrote:

> If the proposal being promoted by Russ is chosen, then there's nothing 
> for this wg to do:  everything that is a candidate for the wg should 
> automatically already be at the final level.  No?

Dave,
This is not the question I've asked ;-). "Are people interested in 
updating documents" and "are people interested in moving from Draft to 
Full" are not quite the same.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 27 Jun 2010 11:57:14 +0100

>>> are replaced with 1 or 2?
...
>> automatically already be at the final level. No?
...
> Full" are not quite the same.

Well...

Strictly speaking, the task of this working group, as I understand it, is to 
move docs from Draft to Full.  The editing is in the service of that goal rather 
than being a goal of its own.

So in practical terms, I didn't/don't see the two different wordings as having 
different import for the wg...

d/

-- 

   Dave Crocker

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 27 Jun 2010 19:31:41 +0200

On 27/Jun/10 12:57, Dave CROCKER wrote:
> Strictly speaking, the task of this working group, as I understand it,
> is to move docs from Draft to Full. The editing is in the service of
> that goal rather than being a goal of its own.

Although that's correct, some documents really deserve a revision.  I, 
for one, would be interested in completing the work defined by the 
existing issues.

Documents that need no editing need no advancement, /if/ that proposal 
passes.  For those cases, it is possible that the IESG has to actually 
work more than the WG in order to produce an advancement, so the 
decision could be left with them...

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Jun 2010 13:41:05 -0400

--On Sunday, June 27, 2010 11:20 AM +0100 Alexey Melnikov
<[email-masked]> wrote:

>>> changes until it is absolutely, 100%, clear that 1652bis
>>> will be published.  In particular note that, while it is in
>>> the RFC Editor queue, it is stuck in MISSREF waiting on
>>> 5321bis and 5322bis, for neither of which there is even an
>>> active I-D yet (I expect that will be cured for one or both
>>> before IETF 78, but one should not count on that until it
>>> happens).  Also note that if the IESG, in its wisdom,
>>> approves
>>> draft-housley-two-maturity-levels in the next month or two,
>>> the YAM WG enters the "overtaken by events" stage and
>>> 5321bis and 5322bis (and probably even the
>>> supposedly-approved 1652bis) become more effort than they
>>> are worth to finish.  Having the distinction of being the
>>> last full standards approved by the IETF under a set of
>>> rules that are being phased out does not seem to me to be
>>> likely to be treated by the responsible editors as worth the
>>> trouble.  That is, of course, just my opinion.
>> 
>> I don't know what will happen to the maturity levels.  The
>> MISSREF  could be cleared.
> 
> Yes, this particular MISREF can be cleared at any time by
> asking the RFC Editor to use published RFCs.
> 
> I have a more fundamental question for this WG: are people
> still going to be interested in updating various email specs
> if 3 muturity levels are replaced with 1 or 2?

Speaking for myself only, the changes called for by this group
and the preevaluation documents so far would probably be
time-consuming to get right (and get agreement that they are
right) and would undoubtedly improve the quality of the
documents, they are, in the grand scheme of things, largely
cosmetic.  Specifically, little or no evidence has been offered
that the present text is causing serious implementation or
interpretation problems.   Even if such evidence appeared around
a few points, the problems could be solved with short and
focused documents clarifying those particular points rather than
revising and reissuing the base specifications.

If the community (or the IESG because, based on experience with
the POISSON, NEWTRK, and IPR efforts, I do not expect clear
community consensus about anything) came to the conclusion that
the additional quality improvements that result from moving
documents through the review and approval process three times
were not worth the effort, I'd almost certainly respect that
conclusion.  In other words, without community recognition that
examining and revising documents twice after Proposed was worth
the trouble, I don't see any reason to believe that treating
these documents as a special exception would be a good
investment given other work that could be done with the same
resources.

I also note that several of the items on the preevaluation lists
(or in queue for those lists) were changes that the IESG
insisted upon as a condition for moving to the next level.  If
that level were eliminated, those demands would either become
moot (reducing the incentive for revisions) or would turn into
obviously unjustifiable and arbitrary demands to satisfy
personal preferences (_really_ reducing the incentive to slog
through editing and approval of revisions).

Again, just my opinion.

    john

---

From: Tony Hansen <[email-masked]>
Date: Sun, 27 Jun 2010 20:56:49 -0400

I would call this an excellent agenda item for Maastricht.

Some of the documents are quite needy of a rev, irrespective of Russ' 
document's outcome. Deciding on the set of documents that make up that 
list would be one of the tasks for the WG. One of the interesting thing 
about using the pre-evaluation step is that we've forced people to think 
through the state of the documents and to get buy-in from the WG for 
those changes. None of the pre-eval docs so far have been contentious, 
but future ones may be more so.

     Tony

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Jun 2010 23:22:57 -0400

--On Sunday, June 27, 2010 20:56 -0400 Tony Hansen
<[email-masked]> wrote:

> Some of the documents are quite needy of a rev, irrespective
> of Russ' document's outcome. Deciding on the set of documents
> that make up that list would be one of the tasks for the WG.
> One of the interesting thing about using the pre-evaluation
> step is that we've forced people to think through the state of
> the documents and to get buy-in from the WG for those changes.
> None of the pre-eval docs so far have been contentious, but
> future ones may be more so.

Tony,

Per my earlier note, if the WG is going to go down that path, I
think it is important to distinguish between:

	(1) In need of a rev because of specific issues that
	require clarification.
	
	(2) In need of a rev because the document itself is
	sufficiently defective that it requires a complete
	revision and replacement.

We are treating all documents as if they fall into the second
category because the procedures for advancement to Full Standard
more or less require that.   But, if there were no "advancement"
goal, I think some (or most) of the documents would either not
need revision at all or would fall into the first category.  For
it, it should be possible to issue an RFC whose substance is one
or more statements of the form "Section N.M of RFC nnnn says
"xxxx" but means "yyyy".  And that would be a lot less work for
all involved than revising the documents.

I have to confess to finding myself significantly de-motivated
to spend time on 5321bis until the question of its fate
(advancements or not and to what) is sorted out, especially
since some of the changes that require the most work are in the
queue only because we had to promise them to IESG members for
the Full Standard version in order to get 5321 signed off.  If
the IESG makes "Full Standard version" meaningless, there should
be no need to do that work.

    john

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Jun 2010 03:19:01 -0700

Hi Tony,
>I would call this an excellent agenda item for Maastricht.

Yes.

>Some of the documents are quite needy of a rev, irrespective of 
>Russ' document's outcome. Deciding on the set of documents that make 
>up that list would be one of the tasks for the WG. One of the 
>interesting thing about using the pre-evaluation step is that we've 
>forced people to think through the state of the documents and to get 
>buy-in from the WG for those changes. None of the pre-eval docs so 
>far have been contentious, but future ones may be more so.

Some of the documents could be do with a revision.

It is an effort to do these updates especially for the authors/editors.

>         revision and replacement.

Some of the issues are more or less clarifications instead of the 
defects.  There is one issue (#22) listed as an interperability problem.

>be no need to do that work.

There is also an impact on substantial parts of the current 
charter.  If this is turned into document updates to the email 
specifications, it might end up being contentious.

If and only if people are still interested in updating some of the 
documents, what should be the scope of the work?

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Jun 2010 10:24:25 -0400

--On Monday, June 28, 2010 03:19 -0700 S Moonesamy
<[email-masked]> wrote:

>> Per my earlier note, if the WG is going to go down that path,
>> I think it is important to distinguish between:
>> 
> Some of the issues are more or less clarifications instead of
> the defects.  There is one issue (#22) listed as an
> interperability problem.
> 
>> the IESG makes "Full Standard version" meaningless, there
>> should be no need to do that work.
> 
> If and only if people are still interested in updating some of
> the documents, what should be the scope of the work?

Let's turn this around.  One of the attractions of the
"pre-evaluation" model as it has evolved is independent of the
agreement with the IESG.  As an editor, I have a list of changes
the WG wants me to make (or at least that someone in the WG has
proposed to make) and know that I can focus my editing time in
those areas, rather than expecting to go back and forth
(potentially endlessly) about what is supposed to be done.  

If we are now moving in the direction of "no full standards
under the current rules" then the pre-eval documents need to be
reviewed --both within the WG and potentially with the IESG as
to what standing they have.   In particular, if things change to
new definitions of maturity levels (independent of how many of
them there are), the assumptions under which the pre-eval
documents were constructed become more or less irrelevant.  If
those documents are going to continue to have value under those
circumstances, we would presumably need to go back and rethink
them and what they mean.

While I'm happy to have the actual discussion in Maastricht, is
it reasonable to suggest that we simply stop substantive work
until the issue is resolved?  One way to interpret the Housley
draft (and I can't tell whether it has support from within the
IESG or not), is that we are wasting our time.   If so...

regards,
    john

---

From: Ned Freed <[email-masked]>
Date: Mon, 28 Jun 2010 09:15:51 -0700 (PDT)

> > (I understand that that would mean rechartering, but that is a

Speaking for myself, I can no longer justify the effort if this change is made.
As it is I have very few free cycles for standards work, which is why my
contributions to this are so slow in coming. Without the invcentive of an
advancement in grade the cycles I have available would be better spent on other
standards work than this.

> cosmetic.

It's actually even worse than that - we are effectively enjoined by our charter
to only make cosmetic changes. IMO such changes only make the cost-benefit cut
if they provide the added benefit of moving things to stadnard.

> Specifically, little or no evidence has been offered

Bingo. And this is a bit of a cononudrum: If something in a document is causing
interop problems, it is by definition not a cosmetic issue, and exceeds the
purview of this group to address.

There is of course a gray area - stuff that's confusing to implementors but
they ultimately get right. But while such cases undoubtedly exist, we are also
guilty of consistently forgetting that the plural of anecdote is not data. Just
because someone - anyone - has a brain fart and misreads something, and then
complains about lack of clarity, doesn't mean the document is actually unclear. 

I have to say I find fewer and fewer of the suggested changes to have any merit
whatsoever. So, absent a more structured way of determining what is actually
confusing, I don't see the point in continuing.

> investment given other work that could be done with the same

My reading of the tea leaves says that this time may be different. As long as
the propsosal is simple, clear, and crisp - a propertiy most of the past
efforts have not managed to have - I think there's a nonnegligable chance we're
going to be looking at a two step process in the not too distant future.

> through editing and approval of revisions).

Spot on again.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Jun 2010 10:10:17 -0700

Hi John,
>Let's turn this around.  One of the attractions of the

Before I delve into this, I'll remind the working group that Alexey 
asked a fundamental question (see 
http://www.ietf.org/mail-archive/web/yam/current/msg00509.html )

>(potentially endlessly) about what is supposed to be done.

In the (experimental) "pre-evaluation" model, the WG identifies a 
list issues before the actual document is edited.  Using Tony's 
words, this forces people to think.  It also keeps controversies in 
check.  The editor of the document gets an idea of what changes are 
being requested and the editing effort is focused on that.  This 
model has not been fully tested though.

I'll use the two current pre-evaluation I-Ds as examples.  In 
draft-ietf-yam-5321bis-smtp-pre-evaluation-05, there are five items 
listed as non-changes.  We have a rough idea of the outcome for the 
three errata.  There was five issues listed in Appendix B as 
editorial 
changes.  draft-ietf-yam-rfc5322bis-msgfmt-pre-evaluation-00 lists 
four errata, three of them about ABNF and the fourth is an editorial 
change.  The WG can open the actual documents and tell the editor 
what is supposed to be done.  The documents would take less WG time 
and the editors might only have to submit one or two I-Ds.

>circumstances, we would presumably need to go back and rethink

In a "no full standards" scenario, the pre-evaluation documents would 
have to be rewritten.  We could resort to amnesia and keep the 
current "rules".  But it won't have any standing on a Last Call.  The 
work would also have to be completed within the same IESG cycle.  And 
we also have to consider whether it is worth doing when maturity 
levels no longer have the same meaning.

>IESG or not), is that we are wasting our time.   If so...

This effort was started in Dublin in July 2008.  There was 
discussions within the WG and at the plenary at Hiroshima in November 
2009 about the effort.  Each time a non-WG process issue is sorted 
out, another one comes along.  The uncertainty is detrimental to the WG work.

The IESG is well aware of the work being carried out by this WG.  I 
don't know whether draft-housley-two-maturity-levels will gain 
consensus.  If it represents the view of the IESG, I'll take it as 
"don't bother doing this work".  The documents are "good enough".

All this shouldn't have occurred after two years of effort as this WG 
has been making some progress.  A charter is a contract between the 
IETF and the working group which is committing to meet explicit 
milestones and delivering specific "products".  It would be 
unreasonable of me to ask the reviewers and editors of the documents 
to carry substantive work if the contract is revoked in such a 
manner.  I mentioned the facts.  I'll leave it to the WG to determine 
whether it is a waste of time or not.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 29 Jun 2010 09:05:37 +0200

Ned,
On 28/Jun/10 18:15, Ned Freed wrote:
On 27/Jun/10 19:41, John C Klensin wrote:
> if they provide the added benefit of moving things to standard.

Issue #5[1] is even less than "cosmetic", I guess...

May I ask whether RFC 5321 contains text that prevents policy 
specifications?  If not, why both SPF and ADSP wrestle with the issue 
of not mandating recipient's behavior, to the point of avoiding to 
mention what would be expected?  I've heard generic explanations, but 
never really understood why, say, RFC 5617 has to be more obscure than 
the corresponding Wikipedia page[2] on the term "discardable"[3].

> purview of this group to address.

A change spelling how email policies should be worded would be far 
better than cosmetic.  It would be revolutionary, given the current 
state of affairs.  Yet, it would not directly cause interop problems.

> the proposal is simple, clear, and crisp - a property most of the past
> efforts have not managed to have - I think there's a nonnegligible chance we're

+1, unless you think the change above alluded to could be feasible.

-- 
[1] http://trac.tools.ietf.org/wg/yam/trac/ticket/5
[2] http://en.wikipedia.org/wiki/Author_Domain_Signing_Practices
[3] http://mipassoc.org/pipermail/ietf-dkim/2010q2/013746.html
and http://mipassoc.org/pipermail/ietf-dkim/2010q2/013751.html

---

From: Ned Freed <[email-masked]>
Date: Tue, 29 Jun 2010 09:15:01 -0700 (PDT)

> Issue #5[1] is even less than "cosmetic", I guess...

Absent evidence showing this has been a real source of problems - which AFAIK
has not been provided - yes, it's a cosmetic change. A good change to make,
sure, but fixing such a minor matter doesn't even come close to making it worth
the trouble of republishing a core specification.

> specifications?

Not that I know of. The effective block on detailed policy specifications
arises from other sources.

> If not, why both SPF and ADSP wrestle with the issue
> mention what would be expected?

Because there's no consensus on what that mandatory policy should be. Heck, we
cannot even manage to publish a specification that says when it's appropriate
to place blocks on port 25. Such a specification would do more to combat psam
than SPF or DKIM ever will.

Like it or not, the lack of "clarity" in the specifications regarding policy
choices for the players in pretty much every possible role is 100& intentional.
And changing it is certainly not a cosmetic matter. But even if it were - even
if it were in scope for us to mess with - I see no indication that we're any
closer to achieving the necessary consensus to make such a change.

And you certainly cannot fix this through specification clarification. You seem
to believe that the problem is due to misinterpretation of confusing
specifications. It just isn't. Yes, there are those who play
specification-mining games to justify their positions on such matters, but
attempting to address this quickly turns into a game of whack-a-mole. And even
if it were possible to write specifications that made this sort of thing
impossible, it would at most remove one tool from the objector's toolset. It
would not change their minds.

> I've heard generic explanations, but

Because the minute you try and travel down that path, you run into those who
still believe that "every email is sacred" or something along those lines.
Basically, we're dancing around the fact that 90% or more of the email that's
sent today ends up being silently discarded. This is reality, and while it
seems exceptionally foolish to me not to acknowledge it, a nonnegligable number
of people don't approve of specifications that even condone such actions, let
alone actively encourage them.

> state of affairs.  Yet, it would not directly cause interop problems.

What would be revoluationary would be the formation of a real consensus on such
issues.

				Ned