Subject: [EAI] State of the core documents

From: John C Klensin <[email-masked]>
Date: Mon, 24 Oct 2011 15:22:03 -0400

Hi.   

We have some problems/ issues with the documents.  The co-chairs
and editor team have developed a strategy that Pete is ok with
if the WG is.  The strategy is outlined below; this is your
chance to object if you have serious problems with it.  However,
most of the issues are procedural; as far as I can tell, only
one of them has any effect on the protocols at all and it is
very narrow (and one that neither the WG nor the IESG caught).

Joseph is out of pocket due to the ICANN meeting so I'm taking
the liberty of asking the questions.   If anyone has strong
opinions, we will wait for him to evaluate the consensus.  I
will, however, take even a couple of days of silence as an
indication that we should go ahead as outlined below.

Note that the recently-posted version of 5335bis and a version
of 5336bis that is now in the pipeline are consistent with this
strategy.

As many of you know, the IESG has raised many issues with the
three core documents (5335bis, 5336bis, and 5337bis).   While
many of these have been comments, rather than (blocking) DISCUSS
positions, we need to respond to the comments (like any other
Last Call comments) in some way.   The vast majority of the
comments fall into three categories:

	(1) We failed to properly identify downrefs to
	informational documents.  One of the problem target
	documents (for both 5335bis and 5336bis) is 4952bis
	(framework).  The others vary from one of the new
	documents to the next but all of them are only
	questionably normative or required.  They can be moved
	to informative or standards track documents substituted
	with, at most, a little rewording.  The problem was due
	in part to a communications disconnect between Pete and
	the co-chairs: the shepherd reports identified the
	issues, Pete didn't mention it in the Last Call, and
	Joseph and I didn't catch that immediately.  This would
	be trivial except that unless we do "something else",
	the documents will need to be put through IETF Last Call
	again.  See below for "something else".
	
	(2) We failed to say explicitly that the new documents
	should cause the experimental ones to be reclassified as
	Historic.  Reclassifying them is probably reasonable
	but, given the nature of the experimental specs and the
	care we have taken to make sure that implementations of
	them cannot interfere with the final versions, it really
	doesn't make a lot of difference, at least IMO.
	
	(3) Several IESG members have asked for more detail in
	the documents about changes from the experimental
	documents.  Some want a little more, some want a lot
	more.    Several of us are, to put it mildly, not
	impressed with those requests: it is not that the
	experimental specs are actually widely-deployed
	standards-track specs with implementers and users to
	whom we have to explain differences.    In addition, a
	great deal of the material that has been asked for is
	already in 4952bis.  That is exactly where we decided to
	put it, but the IESG approved 4952bis around 13 months 
   ago and have collectively forgotten it.

In the process of trying to sort things out, I went back and
looked carefully at 4952bis and discovered that it violates a
number of rules that the IESG is now taking very seriously.  In
particular, it contains a good deal of normative requirements
language.    We gave the IESG its choice as to whether to
process it as Informational or Standards Track.  They selected
Informational, which made sense at the time.  In the light of
the new rules (or newly-enforced rules), that was a mistake --
it should have been treated as standards track.   In addition,
as an accident of how the document was published, it contains
normative references to documents that have not yet been
approved yet (the POP/ IMAP/ POP-IMAP-downgrade specs) and
documents that haven't been written yet (various of the things
we've been referring to as "advice" documents).  The RFC Editor
didn't catch those and list them in the queue, probably because
of the way the references were constructed, but I'm quite sure
that, if they start editing, they will find the references and
everything will go into "Missref hold".  That, from my point of
view, would be a disaster.

So I/we propose the following wrt the IESG comments.  This note
is to see if anyone in WG has strong objections.  

-- We fix 5335bis, 5336bis, and 5337bis as required/ suggested
by the IESG comments, including fixing things so that only
references to each other and 4952bis are normative and
explicitly moving their obsolete predecessors to Historic.  We
don't do an in-depth change summary in any of them but instead
point the reader to 4952bis.   That does not require a new Last
Call on any of them if 4952bis is processed as Standards Track.

-- We reopen 4952bis to eliminate the normative dependences on
documents that aren't finished (or written), clean up the change
descriptions a bit, and update references before someone whines
about those.  We then ask Pete to issue a Last Call on the
changes only and to target it for Proposed Standard, eliminating
the problem with the normative language and with references from
the other docs.

The 4952bis revision is ready; I will post it relatively soon
unless people object.  Even if we don't ask the IESG to process
it for Proposed Standard, most of the changes are needed to
permit 5335bis-5337bis and it to be published without waiting
for everyone else, so, unless people are willing to wait
(probably a year or more at the WG's current speed) for
publication, the WG presumably should review it in any event.
Pete and I believe that it will then have to be put out for a
two-week Last Call on the changes whether we try to move it to
Standard Track or not -- it would be hard to justify these
changes as mere editorial tuning of the kind that we might
otherwise apply at AUTH48.

The non-IESG issue is that there is a table of trace field
"WITH" keywords in 5336bis.  It clearly needs correction so its
descriptions point to UTF8SMTPbis, rather than UTF8SMTP.  But
the keywords are the same as those used in 5336.  Alexey
believes we discussed the issue and concluded that we should
retain the keywords unaltered.  I don't remember but assume that
he is correct.  One way or the other, this is your last chance
to object: if you are convinced the WITH keywords should be
changed, speak up.  If you are convinced that they absolutely
should not be changed, explain why.  If there is controversy,
Joseph will have to sort it out (and those who care will have to
take responsibility for the delay).   Otherwise, the keywords in
the document (which have been around for a _long_ time without
objections) will be retained.

Questions or comments welcome, but, if you have any, make them
soon, please.   And, please, in the interest of WG progress,
please do not use this as an excuse to revisit old issues:
Joseph and I hope that the Taipei meeting can concentrate on the
POP, IMAP, and related downgrade specs and on a discussion about
how (or if) we want to proceed on the other documents.  If we
get bogged down now, we will need to put these documents on the
agenda, probably resulting in considerable further delays.

   best,
    john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 25 Oct 2011 15:45:49 +0900

Hello John, others,

For the record, I have read your explanations in detail and agree with 
all the proposals.

Regards,   Martin.

On 2011/10/25 4:22, John C Klensin wrote:
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 25 Oct 2011 11:05:24 +0200

On 24 October 2011 21:22, John C Klensin wrote:

> (2) We failed to say explicitly that the new
> documents should cause the experimental ones to
> be reclassified as Historic.

The IESG ION^D^D^Dhow-to is very new; no one could
foresee that "obsoletes" is not more good enough.
If a PS obsoletes an experiment I'd consider the
experiment as implicitly finished.  If that SHOULD
be now done explicitly it's also fine, but in that
case I'd also like to see this SHOULD in an RFC,
not only in a "how-to".   As it happens I stumbled
over the link in a "daily dose" just this morning,
but missed that it's related to the EAI Last Call.

> given the nature of the experimental specs and the
> care we have taken to make sure that implementations
> of them cannot interfere with the final versions, it
> really doesn't make a lot of difference, at least
> IMO.

If "historic" offers you the opportunity to recycle
the term UTF8SMTP instead of UTF8SMTPBIS I'd like it.

> I'm quite sure that, if they start editing, they
> will find the references and everything will go into
> "Missref hold".  That, from my point of view, would
> be a disaster.

Maybe you could replace the "missrefs" by vague words
in AUTH84, e.g., instead of "<I-D.POP-EAI>" how about
"a successor of <RFC.POP.EAI.experimental>"?

> We reopen 4952bis to eliminate the normative
> dependences on documents that aren't finished (or
> written), clean up the change descriptions a bit,
> and update references before someone whines about
> those.

That sounds slightly more convoluted than my idea...

What's wrong with the (approved) status of 4952bis,
why do you think it needs to be on standards track?

Just in case, I'm not against a status change, but I
don't see the purpose yet, it sounds like more work
than necessary.  (((If I could pick a -bis where you
spend your time it would start with 5..., not 4...)))

> And, please, in the interest of WG progress, please
> do not use this as an excuse to revisit old issues:

Apropos, I liked the "duck or grouse" in the shepherd
summary.  And (ab)used it as an excuse for posting no
additional comment about said "old issues" in the LC.

-Frank

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Oct 2011 10:50:12 -0400

--On Tuesday, October 25, 2011 11:05 +0200 Frank Ellermann
<[email-masked]> wrote:

>...

Tell it to the IESG, preferably after these documents are all in
the RFC Editor queue.  Put differently, we could fight this, but
I'd much prefer to get these documents signed off and published
so the WG (and implementations) can move forward.

> the term UTF8SMTP instead of UTF8SMTPBIS I'd like it.

It does not.  The reason for changing the keyword was to
eliminate the risk of experimental implementations, or
anticipatory implementations, causing interoperability problems.
If we change the extension keyword, we more or less guarantee
that anything advertising it (and implemented in good faith)
will be using it to describe the final protocol.

Without the keyword change, the IESG would be entirely justified
in insisting that we do an interoperability and risk analysis on
the difference between the experimental and standards-track
protocols.  If I were on the IESG, I certainly would insist.
We don't want to go there, if only because it would be a huge
waste of time and energy.

> "a successor of <RFC.POP.EAI.experimental>"?

Race condition.  The RFC Editor won't generally start editing
until missing references are cleared and certainly won't
announce AUTH48 until that is done.  So one cannot get to AUTH48
to make the change you suggest for AUTH48, even if the ADs and
RFC Editor would consider that a legitimate AUTH48 change.
(yes, the idea did occur to me, but...)

> That sounds slightly more convoluted than my idea...

But it works.
See above.

> why do you think it needs to be on standards track?

I thought this was clear from my earlier note, but let me try
again.

If it is Informational, all normative references in it to I-Ds
have to be eliminated.   Because of the race condition, that
isn't possible without reissuing the draft.  While a variation
on your suggestion would work for the "Advice" documents (and
-11 does that), the POP/IMAP ones pretty much need to be
discussed, even if only with a "work in progress" designation
(still requiring that they be non-normative).  I don't see any
way to reissue the draft, even with only changes to muddy over
the references, without going through another Last Call.  If we
go through another Last Call, some IESG member is certain to
spot the normative language and want to debate it, wasting more
time.   _And_ we would still have to put 5335bis-5337bis back
through another Last Call to get approval for referencing the
Informational 4952bis normatively (no way to avoid that without
transferring a lot of text to 5335bis and 5336bis -- text that
doesn't belong in them).

If we take advantage of having to go through another Last Call
on 4952bis anyway to fix a couple of extra things and then move
it toward standards track, we eliminate the need to do another
Last Call on 5335bis-5337bis, lower the risk of "another pass
means we have to find something else" problems, and generally
move things forward.

> spend your time it would start with 5..., not 4...)))

Understood.  But, for better or worse, they went through WG LC
recently with substantially no comment.  And the IESG is ready
to let them move forward, so I think we move them along.
 
> additional comment about said "old issues" in the LC.

thanks.
   john

---

From: SM <[email-masked]>
Date: Tue, 25 Oct 2011 10:11:43 -0700

Hi John,
>         again.  See below for "something else".

I would consider a second Last Call if the IESG considers the downref 
to be a serious issue instead of having a tedious workaround.

>         doesn't make a lot of difference, at least IMO.

The short answer is that it is not worth arguing about this one.  The 
documents will still need a second Last-Call.  If you do not want to 
change the documents, you can defer this as the Last Call for such a 
reclassification can be done separately.

>Call on any of them if 4952bis is processed as Standards Track.

See above.  I am Ok with any path the WG Chairs pick.

>objections) will be retained.

Alexey performed an AD review in November 2010 and asked about the 
"WITH" keyword.  As mentioned above, the correction is to the trace 
field table.

Regards,
-sm