Subject: Turning to issue tracking on the USEPRO document

From: Harald Alvestrand <[email-masked]>
Date: Wed, 03 Jan 2007 12:12:23 +0100

We believe that we have now reached the stage where it's useful to issue 
the next revision of draft-allbery-usefor-usepro-00 as 
draft-ietf-usefor-usepro-07, and start tracking issues in the issue 
tracker again.

As soon as the draft is out, please switch to the logic of raising 
issues by writing a message to the mailing list saying "ISSUE: USEPRO 
<section>: <subject>".

The chairs will enter an issue in the tracker if one or more of the 
following things is true:
- the chairs agree it is an issue that needs discussion
- one or more persons apart from the person raising the issue agrees 
that it is an issue, and says so on the mailing list ("+1" can be used, 
but be clear on what you're responding to - +1 on a refutation is not 
the same as +1 on the original issue!)

The chairs will not enter an issue in the tracker if:
- they don't think it is an issue
- the editor responds with "yes, that's an error, fixed in my copy" or 
equivalent before the issue can be tracked, and nobody else disasgrees 
with that statement.

Hoping to get this nailed down in less than one year....

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 3 Jan 2007 19:46:40 GMT

>draft-ietf-usefor-usepro-07, and start tracking issues in the issue 

In that case I suggest we refer to my present USEPRO as "CHASPRO" whenever
we have need to refer to it.

>Hoping to get this nailed down in less than one year....

We still have a long way to go, I fear.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 04 Jan 2007 10:10:05 +0100

> we have need to refer to it.

usepro-06 should be quite sufficient.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 04 Jan 2007 17:05:09 -0500

> draft-ietf-usefor-usepro-07, and start tracking issues in the issue 

Note that there are 3 existing USEPRO tickets open in the tracker.  I 
assume that these issues are specific to -06 and earlier, but someone 
more familiar with them should double check.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 06 Jan 2007 15:07:14 +0100

Harald Alvestrand wrote:

>> I suggest we refer to my present USEPRO as "CHASPRO"
>> whenever we have need to refer to it.
 
> usepro-06 should be quite sufficient.

A pair of converging drafts could be also interesting 
if Charles is willing to go to that trouble.

Frank

---

From: Russ Allbery <[email-masked]>
Date: Sun, 07 Jan 2007 16:44:02 -0800

Here's a rundown of the current three open issues concerning USEPRO in the
WG tracker:

> #1051: USEPRO general: Document changes from RFC 1036
> 
>   Section 3.1 of USEPRO -03 should be updated to only list protocol
>   related changes.

This has now been moved to appendix A, and I believe it only lists
protocol-related changes now.  My recommendation would be to close this
issue, and if anyone has any specific protocol-related changes that they
think are missing from that appendix (or that are present when they
shouldn't be), raise those issues on the working group, probably as "Minor
change" since that appendix isn't normative.

> #1083: USEPRO 7.5: Rules for Generating message-ID

A question about where we should document rules for generating message IDs
and the <cancel. $alz convention.  I think the context here concerned
cancel messages, so the new section affected by this issue is 5.3.

The $alz convention is really weird.  I'd said earlier that administrative
cancels were generally in compliance with the protocol without special
exceptions, but that's in the absence of this convention (which I wasn't
thinking about at the time).  If they use the $alz convention, that is a
special exception to all the message ID construction rules, since the
entire point of that convention is to ensure that multiple cancel messages
for the same message *will* collide, thus violating a basic principle of
Netnews in exchange for additional efficiency.  They violate not only our
uniqueness rules but the uniqueness rules inherited from RFC 2822.

If we document an exception for $alz-convention cancels, we're overriding
the uniqueness constraints defined in 3.6.4 of RFC 2822, which we inherit
via USEFOR.  I'm not sure if we want to do this or not.  It makes me very
uncomfortable; it's quite difficult to describe when this is okay and when
it isn't.

One possibility is that we don't document this at all and leave the
constraints in RFC 2822 intact, which would mean that $alz-convention
cancels would be an intentional protocol violation.  Given how much spam
cancelling has dropped off and given that it is, at its basis, an
intentional violation of the protocol done by people who know exactly what
they're doing to achieve a specific effect, I'm not sure that's a bad
idea.

Other than the $alz-convention weirdness, I'm happy with what 3.6.4 of RFC
2822 says about message ID construction and uniqueness and don't think we
need to further elaborate.

Regardless, this should probably stay open as an issue and be discussed
again now that we're working on USEPRO.  I don't see a really happy
solution.

> #1093: USEPRO 2.3: Supported email addresses

The conclusion here was:

>   The USEPRO document will not say MUST or SHOULD about any of the
>   addresses "abuse@identity", "usefor@identity" or "news@identity".

Note, however, that I also dropped any NOTE about the addresses as well,
which at least Charles has said he doesn't agree with, so perhaps this
should become an issue about that.  If so, the relevant section is now
3.2.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 8 Jan 2007 20:37:05 GMT

>This has now been moved to appendix A,

Yes, that is OK, apart from a few niggles I have noted to bring up.

There is also the matter of the transitional arrangements, but that can
also wait until we have resolved exactly which transitions are to survive.

>cancels would be an intentional protocol violation.

I agree. A useful hack best left to those who understand it.

>need to further elaborate.

Again OK. There is a draft on the group's website written in the very early
days which it might be useful to revive someday. But no need to say
anything now (I don't recall having discussed this in USEPRO-06 either).

>should become an issue about that.  If so, the relevant section is now

I would like to see some mention. RFC 2142 is a standards track RFC which
purports to affect Netnews (it should have been infomational, but wasn't).
So a mention is certainly in order (however disdainful), USEAGE is the
place for any serious discussion, though.

However, I think the first thing we need to do is to resolve whether to
accept the idea that <path-identities> in the form of FQDNs that are not
in the DNS are to be allowed, as Harald suggested. When we know that, then
we can review the wording of the rest of that section in a proper context.

Personally, I do not like the idea at all, and would rather put a SHOULD
NOT do it (which still leaves the door slightly ajar for those who have
some overriding need for it.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 8 Jan 2007 20:21:04 GMT

>if Charles is willing to go to that trouble.

Probably not a good idea, unless things go completely off the rails :-( .

But there is a lot in USEPRO-06 that I shall be pressing to include in the
new USEPRO in due course (but we have quite enough on our agenda to keep
us busy at the moment, so they can wait awhile).

---

From: Ken Murchison <[email-masked]>
Date: Tue, 09 Jan 2007 08:14:31 -0500

Russ Allbery wrote:
> issue,

Closed.

> cancels would be an intentional protocol violation.

+1.  I'm not familiar with the $alz convention but it seems too scary to 
put in a standard track document.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 09 Jan 2007 16:31:34 +0100

> Probably not a good idea, unless things go completely 

Your list of at the moment 42 differences is also a way
to tackle this, converted into "issues" later, and then
resolve them one after the other.

About the security considerations, apparently RussH liked
the style of your version so much that USEFOR now gets a
normative reference to USEPRO.  Therefore it could be a
good idea to keep this part as is, even if it's not the
way how RussA would say ths same things - but there are
no serious substantial differences I'm aware of, it's 
only a matter of the style.  I also liked your wording.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 09 Jan 2007 16:46:44 +0100

> place for any serious discussion, though.

We can do an "updates 2142" as needed.  In a recent CfV about a status
change to moderated for a German newsgroup the proponents mentioned news@,
it's clearly needed and useful.  Less so if there's a choice of news@ and
usenet@.  The address SHOULD exist.  Not like postmaster@, but still.

Frank

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 9 Jan 2007 13:27:48 -0500 (EST)

> uncomfortable; it's quite difficult to describe when this is okay and when

Isn't that precisely what SHOULD is for?  "Don't do this, it can break
stuff, unless you really understand what you're doing and want stuff
to break in that specific way."

Seth

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 10 Jan 2007 16:21:30 GMT

>usenet@.  The address SHOULD exist.  Not like postmaster@, but still.

I think the consensus, as recorded in the issue after we had discussed it,
was that we did not want to take any normative action either for or
against RFC 2142. It is so badly written as to be meaningless anyway.

I agree that having "[email-masked]" and "[email-masked]" is a
good idea, but not slavishly following 2142. Therefore it is for USEAGE,
but it still needs a _mention_ in USEPRO, with a pointer to USEAGE.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 10 Jan 2007 20:02:50 +0100

> against RFC 2142. It is so badly written as to be meaningless anyway.

That's a good reason or at least an opportunity to do an "updates 2142".
 
> I agree that having "[email-masked]" and "[email-masked]" is
> a good idea

Then we actually disagree because I think it's completely confusing to 
have two defaults where one (news@) is good enough. 

> Therefore it is for USEAGE, but it still needs a _mention_ in USEPRO,
> with a pointer to USEAGE.

Server admins and implementors might not read USEAGE, it's for users 
and UAs.  But admins need to know that they're expected to install a
news@ address as default for obscure problems (in my CfV example for
potential issues with the possible status change of an existing group).

And I really don't want a normative reference to USEAGE, waiting for 
USEPRO is already very bad.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 10 Jan 2007 20:17:00 +0100

Seth Breidbart wrote:

>> defined in 3.6.4 of RFC 2822, which we inherit via USEFOR
[...]
> to break in that specific way."

Yes, but it's not "our" MUSTard, it's in 2822.  For the protocol here we
can ignore these intentional collisions, they're working as designed if
the spam cancellers use the same "old" variant of the $alz convention.

The "new" variant with its need-to-know algorithm is anyway too obscure,
and a preemptive cancel against a $alz cancel should be obvious for
those who really understand what they're doing.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 11 Jan 2007 12:28:35 GMT

>That's a good reason or at least an opportunity to do an "updates 2142".

But you cannot "update 2142" unless you provide some normative text to
replace it. And our earlier consensus was to NOT write any such normative
text. By all means petition the chairs to reopen that issue if you want.

>have two defaults where one (news@) is good enough. 

Yes, but RFC 2142 was merely reflecting the existing confusion as to which
of those addresses was correct/preferable. That confusion still persists
(some people use one, some the other; my own system recognizes both, and
aliases both to me).

>USEPRO is already very bad.

Any mention of 2142 in USEPRO would be informative only, just to point out
that it existed and encourage implementors to go look at it. It could well
be in a NOTE.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 12 Jan 2007 01:48:41 +0100

Charles Lindsey wrote:
 
> you cannot "update 2142" unless you provide some normative text to
> replace it. And our earlier consensus was to NOT write any such
> normative text.

The Chairs decided to start new USEPRO drafts, old decisions wrt the
drafts up to 06 are not necessarily relevant anymore.  We had very
long deliberations about the precise wording down to details like A
and AAAA vs. MX records, but that was thrown away

1:  I support a news@ default, it's needed and useful.  As a SHOULD.
2:  An additional (or alternative) usenet@ is confusing and bogus,
    this part of RFC 2142 has to be removed (by an update).
3:  For the "mismatch" idea it's necessary that the path-identity 
    has an IP matching the connecting IP, or more IPs including the
    connecting IP, is that correct ?
4:  Putting it all together adding an MX for news@<path-dentity> is
    straight forward, but of course they can also run a SMTP server
    directly at the IP of that server for this purpose.

I see zero reasons why those very simple requirements shouldn't go
into the spec.  
 
> RFC 2142 was merely reflecting the existing confusion as to which

Then let's kill it.  RFC 2142 says that both addresses are specified
in RFC 977, but I don't find it.  Besides RFC 977 is now obsolete,
and I'm almost sure that RFC 3977 doesn't mention it.

> Any mention of 2142 in USEPRO would be informative only

With an "updates 2142" we'd be sure to get rid of the cruft.  If an
admin ignores the control messages informing them about a status
change for a group there must be a simple way to discuss such issues
by mail.  

Alternatively let's eliminate the _concept_ of moderated groups from
this draft because its "specification" is far too inadequate and too
incomplete for an RFC, let alone standards track.

Frank