Subject: Re: New USEPRO path-identity text

From: John Stanley <[email-masked]>
Date: Wed, 6 Jul 2005 12:25:23 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>It is clear that routers on the Internet are configured to route packets
>to the sites which officially own the IP addresses as allocated by the
>processes established by ICANN.

I don't think it is so clear. There are a lot of routers that route
packets for a large number of addresses to the wrong place deliberately.
For addresses belonging to domains such as doubleclick.net, for example.
And, of course, many of the routers in China deliberately route a large
number of addresses to the wrong place.

About the best you could say is "an IP address .. that is in the routable 
address blocks as defined in RFCxxxx", where RFCxxx is the RFC that 
defines the non-routable addresses.

>That ticket is still open, and under discussion.

I neither know nor care what discussion is taking place on the "ticket
system". I know and care what discussion is taking place here, and here is
it very quiet concerning the problem. Nobody I've seen has bothered to
mention the lack of a colon in the last proposed text, that indicates a
consensus to me.

>I don't think the world out there is going to accept any encoding of IPv6
>addresses other than the one currently in widespread use (as defined in
>RFC 3986 as well as lots of other places).

Of course they will "accept it". Why wouldn't they? It's not like they 
have to type the thing in every time they post an article.

   2.   An encoding of an IP address - <IPv4address> or <IPv6address> - 
        [RFC 3986] which SHOULD be a publicly recognized address 

I publicly recognize 192.168.0.1, but it is not routable and its use as a 
path-identity is questionable.

                                     To ensure that a <path-identity>
   provides a unique identity for the news-server concerned, it should
   be one of:

>Are people happy with that?

If you are happy that you haven't ensured that the path-identity is 
unique despite your statement to the contrary, I'm happy.

---

From: John Stanley <[email-masked]>
Date: Thu, 7 Jul 2005 10:24:10 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>   4.   Some other (arbitrary) name believed to be unique and registered
>        at least with all other news-servers sending articles directly
>        to the given one. The news-server administrator is responsible
>        for choosing an appropriate name (and will bear the consequences
>        of an inappropriate choice). 

Dear USENET admin:

Don't do what we say you can or you might be sorry!

Sincerely,
USEFOR Working Group

---

From: John Stanley <[email-masked]>
Date: Fri, 8 Jul 2005 11:54:02 -0700 (PDT)

Bruce Lilly <blilly@xxxxxxxxx>:

>That seems OK; I'm wary of "elide all colons" because dead::beef:cafe
>and dead:beef::cafe mean different things in IPv6-ese.

You cannot "elide all colons" until after you have undone the "double 
colon abbreviation" step for IPv6, because, as you point out, the double 
colons means something different than the single colon.

And once you have elided them, there is no reason to put something else in 
their place. Simply remove the colons. Problem solved. There are no 32 
character UUCP names to conflict with.

---

From: John Stanley <[email-masked]>
Date: Fri, 8 Jul 2005 11:57:19 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Some people profess great concern that we have not provided a way to
>enforce the uniqueness of these names.

>That sentence is just a polite way of saying "Yes, we know that the
>uniquesness is not enforceable. Tough!".

"That sentence" says nothing of the sort. It's telling the hapless admin 
that even if he does what we tell him to do, there may be "consequences" 
from his "inappropriate" choice. 

If what we tell him to do results in an "inappropriate choice", then I'd
say the only "inappropriate choice" he has made is in listening to us.

Either fix the instruction so it does not result in "inappropriate 
choices" or remove the threat.

---

From: John Stanley <[email-masked]>
Date: Wed, 13 Jul 2005 11:01:39 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>RFC 2142 states that 'the <ABUSE@xxxxxxxxxxx> address "must" be valid',
>but only where COMPANY is an 'Internet service provider' 

[Note to someone who can do something about it: will you PLEASE get this 
damn archive to STOP modifying the messages it archives? I am getting very 
tired of trying to guess what someone has written just because it looks 
like an email address. Since the address shown above has no dot in the 
RHS, it's not a valid address to start with, so it cannot be mandated. 
The statement as it stands is patently absurd: RFC2142 cannot mandate an
invalid address.]

> If you equate "must" with "MUST" (as you appear to do), 

Still putting words in my mouth, eh, Charles? I equate "must" with a
mandatory action as defined in the dictionary. I equate "MUST" with the
RFC2119 language that requires a reason for a mandate, which YOU have not
yet provided. If you think the two are the same, well, you are wrong. Do
not say that I think the two are the same; that's a lie and that's putting
words in my mouth.

> then what I have written is essentially the same. 

You are patently wrong. RFC2142 tells us that ONLY the top level domain
abuse address "must" be valid. YOU tell us that abuse at the FULLY
QUALIFIED DOMAIN NAME as found in the path-identity MUST be valid. That is
NOT the same, and no amount of nonsense you produce will change the
differences.

>{3. You don't have to provide any abuse address at all if you are not an
>ISP, but that is the same in RFC 2142.}

You clearly don't understand the difference between a rule and an example 
of that rule. RFC2142 says:

   For well known names that are not related to specific protocols, only
   the organization's top level domain name are required to be valid.

It does NOT define "organization" to be "only ISP". It uses an example of 
an ISP. Does your news server reject any article that is not from Jerry 
Schwartz? (That's the example from RFC1036). 

>If the "must" is justified, then the "MUST" is justified.

The "must" in RFC2142 applies only to "the top level domain". The "MUST"  
you are trying to force down our throats applies to the FQDN as entered in
the path-identity. They do NOT apply to the same thing, and thus the
justification for one does not cover the other. YOUR "MUST" is much
stronger than RFC2142's, so YOU bear the burden of justifying it.
Furthermore, RFC2142 is an existing standard that we are not free to
modify; USEPRO is a draft that we are tasked with creating.  And finally,
while RFC2142 says it is encouraged, it explicitely says that an abuse
address at anything lower than the top level domain is NOT required.

What is the interoperability issue that is being solved by your MUST? Why
are you overriding RFC2142?  Either produce the argument supporting your
MUST or remove it. This twisted reading of RFC2142 and ridiculous claims 
that you are saying the same thing are just a waste of our time.

>Look carefully at the position of the word "only" in those two sentences.
>They do NOT say the same thing.

"Only the top level domain is required to be valid" says that the only 
requirement is for the top level domain. Other than "top level domain" has 
no requirement. The "only" is the same.

Now, either produce a valid argument for having any mandate regarding the
FQDN abuse address or remove it.  You want to say "SHOULD", that's a 
different story, and I might agree with you. You want to say "MUST" or 
even "must" and I'll demand a justification for your requirement in light 
of RFC2142. It's your burden when you try to supercede an existing 
standard; either do it or do it not.

---

From: John Stanley <[email-masked]>
Date: Wed, 13 Jul 2005 18:34:59 -0700 (PDT)

Steve Walker <nntp@xxxxxxxxxxxxxx>:

>If two sites use the same pathstamp one will just change. 

If they notice the problem and don't decide to get into a whizzing match 
over who has rights to the name. 

> ... the only way to solve it ...

I'm not claiming it is a problem that needs solving, I'm just pointing out 
that the talk about "unique" and how we are ensuring that these things are
is just hot air. "SHOULD do a, b, c, or d" doesn't ensure anything, even 
if a, b, c, and d were capable of ensuring uniqueness.

---

From: John Stanley <[email-masked]>
Date: Mon, 18 Jul 2005 12:42:55 -0700 (PDT)

More assertion, no justification.

>OK, so the three people who have answered have given three different
>answers:   
>which does tend to support my contention that some clear statement in our
>draft is needed.

It does nothing of the sort. I'd be as correct in saying that the sun came
up in the east this morning which supports my claim that you need to
justify a difference from RFC2142. You do need to justify the change, but
the sun has nothing to do with it. The fact that three people can come up
with three addresses that do the same thing is somehow a "Bad Thing" that
causes an interoperability issue that YOU need to step down from on high
to fix?

(And, in fact, my first answer included one of the other's, so there are
really only two answers, and the shotgun approach I suggested first would
succeed no matter what.)

>So there is one respected institution that totally ignores RFC 2142 :-( .

The correct response to ignorance of the law is not to create more useless 
laws. But how do we know it ignores RFC2142? I've not sent an email to 
abuse@ the top level domain and had it bounce. Have you?

>Looks like that one might "go unanswered" :-) .

Do you see anything in any RFC that says that a valid email mailbox must 
result in "answers" for it to be valid? I do not. Your comment is 
worthless. Less than worthless, because you intended it to cloud the 
issue. 

>But for an innocent who does not even recognise that it is an academic
>institution, and that "cs" stands for "computer science", and who has 
>never heard of 'whois' or 'nslookup', you need a simple rule that anybody 
>can apply, such as "look at what appears in the Injection-Info, or in 
>front of the 'POSTED' in the Path, and stick "abuse@" in front of it.

And I could argue that someone who is so ignorant of anything to do with 
the net ought not to be wasting anyone's time sending abuse reports. If 
the problem appears in USENET, then there will be an excess of cluefull
people who can deal with the problem. We don't need ten million abuse 
reports for one article, thank you very much. 

RFC2142 covers the issue. RFC 2142 explicitely says the opposite from what
you want. Either you can justify the override of RFC2142 or you cannot.
Please make some attempt at some time soon; these repeated assertions
about what ought to be said are not sufficient.

>OTOH, for an injecting agent, USEPRO currently says you MUST create such
>an MX record (or have the A record listen to port 25), and you MUST
>provide abuse@ as well as the other two (modulo a complaints address in
>Injection-Info).

Yes, we know what you want USEPRO to say currently. (I'm curious how you
"modulo" a complaints address with anything else. Do you mean "sans"? The
two words are different.) When do you think you might get around to some
justification for this difference from existing standards and RFC2119
mandate? Perhaps this week?

>So we are stronger there, because RFC 2142 only requires abuse@ at the
>"top level domain" (figuring out which is the "top level domain" is left
>as an exercise for the student).

Yes, we know what RFC2142 says. It's not much of an exercise. It's really 
not that hard. It's really not an interoperability issue, and it isn't 
even a critical issue, especially for ignoramuses who don't understand 
internet addresses anyway.

>Non-net-savvy people should only need "abuse@", and then only to the
>injecting agent. With double stamping, they would see:
>
>    ...!new15@xxxxxxxxxxxxxx!nntpserver.com!POSTED!not-for-mail

No, they wouldn't. 

> ...so you simply tell them to "use whatever is to the left of the 
>'POSTED'".

Gee, do you really think it is so hard to understand that "nntpserver.com" 
is a "top level domain" and that RFC2142 applies to that top level 
domain? I don't. Do you imagine that many people would bother sending 
abuse reports to "abuse@com", and then, if they do, that they would be 
smart enough to have anything worth listening to if abuse@com even was a 
valid address?

Quick poll: how many people think that someone would send an abuse report 
to abuse@xxxxxxxxxxxxxxx, and if they did, that it would contain any 
information any clued person would bother caring about?

And you do you really not understand that paths can be so trivially forged 
that you cannot trust anything more than what your own server puts there? 
When you see a path like:

	a!b!c!d!e!God-almighty-himself!POSTED!not-for-mail

do you REALLY believe that God Almighty Himself has posted this article? I
mean, it IS "just to the left of the POSTED".

---

From: John Stanley <[email-masked]>
Date: Wed, 20 Jul 2005 11:42:14 -0700 (PDT)

Using the old "it's in the draft" justification:

>The CHANGED rules (as you call them) were written into the draft about 5
>years ago, 

RFC2142 is dated 1997, which is more than 5 years ago. USEPRO-00 is dated
2004, which is not more than 1 year ago. We deliberately put off
discsussing USEPRO until USEFOR was well on its way, so now it is USEPRO's
turn for scrutiny -- not five years ago. You want the rules of RFC2142
changed. Justify the difference or drop it.

>and even passed unscathed through a Working Group Last Call (an
>argument you are fond of using when it suits your purpose).

Charles, if "passed last call" doesn't apply to changes you want to make,
then I find it particularly hypocritical of you to apply it when you don't
want to remove some pet idea of yours. It doesn't matter if it past a
"last call", it still requires justification. "Because we want to" isn't
good enough. (And I could point out a lot of things that you've changed
unilaterally after multiple last calls, so don't play this game with me. )

I've seen nobody supporting keeping the requirement. I've seen replies 
agreeing it should be removed. Everyone other than you seems to think it 
ought to go. Either justify it (and convince us) or lose it.

>Perhaps it is the same interoperability issue that justifies defining
>"postmaster" in RFC 2821 with a "MUST".

I doubt it, since "postmaster" is an email management issue and "abuse"  
isn't. And since RFC2142 didn't think it was an issue. Either justify the
change or remove it.

>It is related to fighting security
>issues, and breaches of security count as "harm" in my book.

What a load of poppycock. Not having abuse@FQDN as a valid address has 
nothing to do with "security issues". It neither creates nor prevents 
them, your high-sounding gobbldygook notwithstanding.

You can justify neither the mandate nor the difference from RFC2142. If 
the process were operating correctly, that would mean the mandate would 
dissappear. In USEFOR, it means that you'll leave it because you can. I'd 
call that an abuse of the editor's position.

There is no interoperability issue, your security issue is a farce, you 
cannot come up with anything more serious than something like "idiots 
won't be able to complain unless we hold their tiny little hands and tell 
them explicitely where to complain to". That's not an interoperability 
issue justifying an RFC2119 mandate, nor is it an issue serious enough to 
justify overriding RFC2142. You can't figure out what a "top level domain" 
is and can't comprehend sending an abuse report to several places at once 
just to make sure it gets through. THAT certainly isn't an 
interoperability issue, and it certainly isn't a "security" issue.

Either come up with something relevant or remove the mandate.