Subject: Re: Shame vs Engineering

From: John Stanley <[email-masked]>
Date: Thu, 4 Aug 2005 16:50:26 -0700 (PDT)

Bruce Lilly <blilly@xxxxxxxxx>:

>And "limit retransmissions" is mentioned in BCP 14 as a harm mitigation
>item suitable for imperative keywords such as MUST.

Yes, yes, that's very nice. But if we have four options available, then 
all four have to meet that criterion or they should not be available, no?

>There is also something called DHCP, so while e.g. 216.49.158.220 is fully
>routable, it may be assigned to one host at one time and to a very
>different host a moment later (the Path field has no timestamp),

If a news server admin has his servers assigned addresses by DHCP and 
doesn't make sure the same address is assigned each time, he deserves to 
lose articles/see dups. It's just silly to do that.

Notice that the only mandate refers to injection agents, so apparently it 
is ok by us for an admin of a transport or serving agent to use DHCP to 
configure his IP address and use that in the Path. If that's true, why not
for injection, too?

>Once upon a time, there was a registry for UUCP names, and a UUCP Mapping
>Project associated with it.

I know that, too. And there were UUCP names that were never mapped because
either the admin never sent in the data or the map coordinator for that 
area just ignored it.

>> See above. 10.x.x.x is not a routable IP address and does not fall into 
>> the category of valid as we have attempted to define it.

>Note DHCP. 

DHCP and 10.x.x.x are two different concepts. If someone configures his 
DHCP to lease out 10.x.x.x addresses, then they are not valid under item 2 
and thus outside the scope of this discussion.

>That's orders of magnitude difference, where
>an IP address can easily be reassigned before an article finishes 
>propagating.

If an admin runs his servers that way, who are we to tell him no?

On the other hand, if we tell transport and serving agent admins they CAN 
run them that way, who are we to tell injecting agent admins not to? After 
all, the Path entry is NOT a contact address, so the Path entry for an 
injecting agent is really no different than one for a transport or serving
agent.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 5 Aug 2005 07:47:59 -0400

> all four have to meet that criterion or they should not be available, no?

They shouldn't be "options" if they don't meet the (uniqueness) criterion.

> lose articles/see dups. It's just silly to do that.

He may have no choice; IP addresses are assigned by a service provider.
Use of an IP address, in order to meet the uniqueness requirement, would
have to be predicated on the address being not only globally routable,
but also statically assigned.  That's something that the site administrator
might be able to determine, but cannot in general be determined by some
other party, which makes use of IP addresses for diagnostics of limited
use, at least as a path entry (if we were to provide for comments, that
would be another matter).  In practice, IP addresses are used in Path so
rarely, and FQDNs are so readily available, that it's really not worth
spending a lot of time worrying about this; the semantics and protocol
impose a uniqueness requirement.  Uniqueness is guaranteed by a FQDN, but
not by an IP address (in general) or an unregistered, unregisterable UUCP
name, or by some random string.  Let's specify that (to meet the uniqueness
requirement) the Path entries (other than the tail-entry) MUST be FQDNs
and move on.

> configure his IP address and use that in the Path. If that's true, why not

The use of the Path field entries to limit retransmissions and the
corresponding name uniqueness requirement applies to *all* entries in
the Path field (except the meaningless tail-entry).

> If an admin runs his servers that way, who are we to tell him no?

We are the protocol specifiers, and the requirement exists due to the
field semantics and the use in transport protocols. 

> After 

Agreed.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 05 Aug 2005 10:25:27 -0400

Bruce Lilly wrote:
 > In practice, IP addresses are used in Path so
> impose a uniqueness requirement. 

There is a difference between a unique path entry, an unique FQDN,
and a unique FQDN that is in the DNS tables (which is what is required
when abuse@ is a MUST.)

Maybe there are a lot of people here that don't actually look at
path headers enough to know what is in them now, working perfectly well,
but would become non-compliant with text proposed.

To get an example I went to news.software.nntp and THE VERY FIRST ARTICLE
I CHOSE had this:

cox.net!news-xfer.cox.net!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!news.glorb.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail

1. cox.net is not a FQDN.  Is there a good reason to prohibit this entry?

    There certainly is a good, practical, maybe even necessary, reason to allow
    it when you have a multiple machines doing routing (and all the big providers
    certainly do.)

2. nntp.frontiernet.net
    No DNS entries.

3. postnews.google.com
    No DNS entries.

4. z14g2000cwz.googlegroups.com
    No DNS entries

This article had a Complaints-To, and an X-Complaints-To header fields.

How many people would have difficulty finding contact information
for any of those path entries?  Compare that to the hassle of cox.net
telling all its up and downstream peers all of its routing server
names, or google.com maintaining DNS records for all of the internal
machines behind its firewall.

Since NEWS is not USENET, does anyone see a problem with someone
running a private server on 192.168.x.x (or other globally non-unique
IP addresses), and sticking those IP addresses in the path?  If articles
with those paths leak out to Usenet, what do I care if they don't
propagate?

I agree with John that we don't need explanatory notes about
adminstrators bearing consequences for violating a MUST.  There
is no end to obvious things we can emphasize using extra NOTEs.

If we provide a clear explanation of how retransmissions are limited,
do we have to explain to implementors that they will have trouble
with propagation when they use a DYNAMIC IP address and stick that
in the Path?  It's a silly example anyway, because in the scenarios
some people have concocted to make their point, there is no way
for peers to connect and send news to such a machine.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 5 Aug 2005 12:33:08 -0400

> and a unique FQDN that is in the DNS tables (which is what is required

For the moment, I'm not concerned about the abuse@ stuff; there is a poll
in progress and I have separately responded to that.  I am concerned about
the use of the Path field for limiting retransmissions, the corresponding
uniqueness requirement and the document text related to that.

> cox.net!news-xfer.cox.net!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!news.glorb.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail

No IP addresses, no unqualified (UUCP or otherwise) names.

> 1. cox.net is not a FQDN.

Depends on your definition of "FQDN":

# nslookup -sil -type=any cox.net
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
cox.net nameserver = ns.west.cox.net.
cox.net nameserver = ns.cox.net.
cox.net nameserver = ns.east.cox.net.
cox.net mail exchanger = 100 mx.east.cox.net.
cox.net mail exchanger = 100 mx.west.cox.net.
Name:   cox.net
Address: 68.1.17.9

Authoritative answers can be found from:
cox.net nameserver = ns.east.cox.net.
cox.net nameserver = ns.west.cox.net.
cox.net nameserver = ns.cox.net.
ns.cox.net      internet address = 68.1.16.100
ns.east.cox.net internet address = 68.12.19.237
ns.west.cox.net internet address = 68.111.106.76
mx.east.cox.net internet address = 68.1.17.3
mx.west.cox.net internet address = 68.6.19.3

It looks like a FQDN (a name with the right-most label (net) being a
registered top-level domain name), and DNS reports several corresponding
records (I'll leave authoritative checks to anybody who cares), including
an A record.

Exactly what sort of definition of "FQDN" do you have in mind that would
exclude "cox.net"?

>     No DNS entries.

Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
nntp.frontiernet.net
        origin = auth01.roc.ny.frontiernet.net
        mail addr = hostmaster.frontiernet.net
        serial = 163
        refresh = 10800
        retry = 3600
        expire = 604800
        minimum = 900
nntp.frontiernet.net    nameserver = auth02.roc.ny.frontiernet.net.
nntp.frontiernet.net    nameserver = auth01.roc.ny.frontiernet.net.

Authoritative answers can be found from:
nntp.frontiernet.net    nameserver = auth02.roc.ny.frontiernet.net.
nntp.frontiernet.net    nameserver = auth01.roc.ny.frontiernet.net.

>     No DNS entries.

True, but it's still a FQDN, and there is a "google.com" responsible for
names under that hierarchy (with DNS records including SOA).
 
> 4. z14g2000cwz.googlegroups.com

Same situation as above.
 
> This article had a Complaints-To, and an X-Complaints-To header fields.

Not useful at the moment (no defined syntax).
 
> for any of those path entries?

Don't care.  That's not the purpose of Path.

> Compare that to the hassle of cox.net 

Unnecessary.
 
> with those paths leak out to Usenet, what do I care if they don't

That's not the issue.
 
> for peers to connect and send news to such a machine.

You seem to be confusing connection to a host with content in a Path
field.  One does not directly affect the other (e.g. one can connect
to the site which entered a private-use IP address using a different
name).

There are actually two criteria:
1. names MUST be globally unique (to prevent failure of transport due
   to name clashes)
2. names must (logically) be known to a site's immediate neighbors as
   that is where the checks for names to limit retransmissions take
   place

We do need to specify the first, as is it a global requirement associated
with the Path field semantics and the field's use in protocols.  We
shouldn't have to state the second as such provided that the description
of the semantics of the field are made sufficiently clear -- it should be
obvious.  I believe that the first paragraph of USEFOR section 3.1.6 is
currently sufficiently clear on that point.  If you feel that further
clarification is necessary, feel free to propose a change.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 8 Aug 2005 14:01:00 GMT

>1. cox.net is not a FQDN.  Is there a good reason to prohibit this entry?

Yes it is. It even has an MX record. If I saw that Path and wanted to
communicate with the admin of that server, I would try "[email-masked]"
rather than "[email-masked]".

>    No DNS entries.

There is an MX record for frontiernet.net. And a name server at
auth01.roc.ny.frontiernet.net. But nothing else. Not impressive. 

>    No DNS entries.

Well, did you expect any? :-)

>machines behind its firewall.

Presumably the reason cox.net put that shortened version in the Path was to
save it the trouble of informing its peers each time it brought a new
server on stream. That is the sort of thing we need to explicitly allow
next time we update the text telling how to construct Paths.

>with those paths leak out to Usenet, what do I care if they don't

A cooperating subnet can always agree to break the rules. But if it is
possible for a news transmission path to enter some intranet with a
firewall and leave the same intranet at another point to progagate onwards
through Usenet, then the admins had better be careful what
<path-inentity>s they insert as it passes through their internal machines.

>is no end to obvious things we can emphasize using extra NOTEs.

Sure. All I want is to point out the slight theoretical risk of using
names not in the DNS. I am open to suggestions how to express this. But,
so long as Bruce is protesting that we have not closed that miniscule
loophole, then I think we need to say _something_.

-- 
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