Subject: Minneapolis - agenda items please.

From: Lars-Johan Liman <[email-masked]>
Date: Wed, 13 Feb 2002 14:15:11 +0100 (MET)

It's that time of the year again ... when we go to Minneapolis, and to
be able to drag you people there I need agenda items.

Suggestions, please!

				Cheers,
				  /Liman

---

From: Lars-Johan Liman <[email-masked]>
Date: Wed, 20 Feb 2002 11:26:35 +0100 (MET)

> Suggestions, please!

If I don't get any interest Real Soon Now (TM), there's not going to
be a meeting in Mpls. They close the agenda registration on Friday,
and it has to pass our AD first.

				Cheers,
				  /Liman

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Feb 2002 20:42:13 +0700

Date:        Wed, 20 Feb 2002 11:26:35 +0100 (MET)
    From:        Lars-Johan Liman <[email-masked]>
    Message-ID:  <[email-masked]>

  | If I don't get any interest Real Soon Now (TM), there's not going to
  | be a meeting in Mpls.

I won't be in Minneapolis so I don't care anyway, but the agenda should
be to finish (or at least progress) any pending work that the WG has in
its charter.   What that might be the WG chair should have a handle on.
If there is no pending work, or none that seems to need meeting time,
there shouldn't be a WG meeting (they're not mandatory).

The meeting shouldn't be for random person X to reply to your message
and say "I'd like to give a talk about ..."

kre

---

From: Philip Hazel <[email-masked]>
Date: Thu, 21 Feb 2002 09:40:22 +0000 (GMT)

> there shouldn't be a WG meeting (they're not mandatory).

I won't be in Minneapolis either, but I would like to progress the ID
that I'm editing: draft-ietf-dnsop-dontpublish-unreachable-03.txt. There
has been very little comment on that draft. Just

  (a) One minor clarification rewording.
  (b) A controversy over whether to include an explicit list of non-global
      networks. Views for and against have been expressed. Currently
      there is no list (I am on the anti side).

Is it possible to move this ID into WG Last Call? The minor re-wording
can go into the next draft. The detail of this change is:

Current draft:

6.4 Specification of no SMTP service

   MX records that point to host names whose address records specify the
   loopback address have been seen in the DNS. This seems to be a
   misguided attempt to specify "no SMTP service for this domain" more
   positively than just refusing connections to the SMTP port. (A refused
   connection is treated as a temporary error, because it might be the
   result of a system rebooting, for example.)

   If such a facility is required, it SHOULD instead be done by
   arranging for the hosts in question to return

     554 No SMTP service here

   to all SMTP connections.

Proposal is to reword the final paragraph to read as follows:

    If such a facility is required, it SHOULD instead be done by
    arranging for the hosts listed in a domain's MX records to return
    a 554 error response, either on initial connection, or following a
    RCPT command for an address in a domain for which there is no
    service.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 22 Feb 2002 23:11:09 +0100

Sorry, to jump in the discussion at a late point. I'm rather new to this
list.

>     RCPT command for an address in a domain for which there is no

Care should be taken IMHO to keep the wording RFC 2821 (SMTP) compliant.
    RFC 2821 Section 3.1 Session Initiation
already specifies a procedure just for that case (3rd paragraph):

    The SMTP protocol allows a server to formally reject a transaction
    while still allowing the initial connection as follows:
    [ ...]

Maybe a referral to the above mentioned Section would be a good idea?

Also:

    loopback address have been seen in the DNS. This seems to be a
    misguided attempt to specify "no SMTP service for this domain"
    more positively than just refusing connections to the SMTP port.

<SIDENOTE>
From my experience it's more likely that spammers don't have a valid
ip address to point the MX of their domain to. But they need a IP
to pass anti-spam checks, so they use 127.0.0.1 and have the advantage
not to get the bounces back. Btw. I have also seen the use of 0.0.0.0
instead of 127.0.0.1. The impact of 0.0.0.0 on some SMTP daemons is rather
terrible.
</SIDENOTE>

IMHO it would be a good idea to explicitely ban the use of "0.0.0.0"
(haven't found it mentioned in the draft at all) and it probably should
be a MUST NOT.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Philip Hazel <[email-masked]>
Date: Mon, 25 Feb 2002 09:13:19 +0000 (GMT)

> Maybe a referral to the above mentioned Section would be a good idea?

That's a good point.

> (haven't found it mentioned in the draft at all) and it probably should

I've been trying not to put too many explicit addresses in the draft, in
an attempt to keep it about principles rather than specifics (which
people might interpret as complete lists). 0.0.0.0 is clearly an address
which does not have global significance, but perhaps this does need
stating explicitly, because people do seem to do the most stupid things.

What do others think? I don't know enough about TCP/IP to know whether
this ban should just be 0.0.0.0 or perhaps something wider such as 0/8.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Feb 2002 00:31:46 +0100

Philip Hazel <[email-masked]> writes:

> Is it possible to move this ID into WG Last Call?

I might have missed it, but does everyone agrees with this draft being
a good thing?  I still don't see how it can be enforced, and I don't
see how it harms anyone else but the people that put incorrect
information in their own DNS zones.

Compare the current discussions in SAAG on publishing non-protocol
recommendations as BCP that uses RFC 2119 keywords.

Of course, the contents of the draft is good and everyone should
understand and follow it, but doesn't everyone already?  Is there any
point in caring about the people that doesn't?

---

From: Philip Hazel <[email-masked]>
Date: Tue, 26 Feb 2002 08:39:11 +0000 (GMT)

> information in their own DNS zones.

I was encouraged to write the draft, so I assume there are other people
who support it.

It's a BCP document, so there's no concept of "enforcing". It just says
"This is the best way to go about things if you want good interworking."

> understand and follow it, but doesn't everyone already?

No. If they did, I wouldn't have written it. It was written because I
and others had encountered enough situations where clueless people had
done the wrong thing. Probably out of ignorance.

> Is there any

Well, not everybody is born knowing everything. There are newbies coming
into this all the time, and having documents available to educate them
is a good thing, IMHO.

Furthermore, if somebody doesn't follow these guidelines, in some cases
it will waste YOUR resources. That's another reason for having a
document to point at.

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 26 Feb 2002 15:18:20 +0100

> information in their own DNS zones.

Assume  example.com has a MX to mail.example.com and mail.example.com
has A 127.0.0.1.
You receive e.g. spam from @example.com and your mailserver tries do deliver
a bounce. I am sure there a lot of mailservers out there that will suffer
quite some harm (and did in the past).

Another example is section
     6.3 SMTP servers behind firewalls
I know lot of e.g. universities do this. Their faculties are somewhat
independant and want to maintain their own DNS and Mailservers, but
they have zillions of relay open workstations. So the computing staff
blocks port 25 incoming on the border routers and forces the departments to
add a lower priority MX gate.university. That way they don't have to maintain
static routing tables on the mailserver as gate.university delivers
via MX and does "the right thing". However this has a big impact
on the sending mailservers, as they never can reach the best prio MX,
time out and then backup. So it doesn't harm the DNS maintainers but
people that try to send email to that destination.

> point in caring about the people that doesn't?

Yes. Some people simply don't think of consequences or are too unexperienced.
Developers of software (e.g. mailservers) have a document of "bad things"
that can happen and may put workarounds in.
Thus I think it fits pretty well as a companion to
    1178 Choosing a Name for Your Computer
    1536 Common DNS Implementation Errors and Suggested Fixes
    1713 Tools for DNS debugging
    1912 Common DNS Operational and Configuration Errors
    2182 Selection and Operation of Secondary DNS Servers

	\Maex

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 26 Feb 2002 11:10:09 -0500

From:  Markus Stumpf <[email-masked]>
Date:  Tue, 26 Feb 2002 15:18:20 +0100
To:  [email-masked]
Message-ID:  <[email-masked]>
References:  <[email-masked]> <[email-masked]>
In-Reply-To:  <[email-masked]>; from [email-masked] on Tue, Feb 26, 2002 at 12:31:46AM +0100
Organization:  SpaceNet AG, Muenchen, Germany
X-PGP-Fingerprint:  66 F3 75 79 01 D0 B8 5F  1A C7 77 88 4A B6 70 DF

>...

Re below: not just universities. When I was at Digital Equipment Corp,
there were cases of internal areas firewalled off from the rest of the
corporate net which was firewalled from the Internet. It was common
for the first MX to be for direct delivery, one or more second
priority to be for delivery to mail servers on the inner firewall, and
then several third priority for delivery to the main Digital firewall.
An outside mail sender would thus have to always go thorugh a number
of MXes before getting one that they could connect to. But this didn't
seem to cause much problem. I'm sure that, over the years, millions of
pieces of mail were delivered this way.

Donald

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 Feb 2002 19:06:25 +0100

> quite some harm (and did in the past).

Let's analyze that:

1) example.com administrators did this intentionally to cause problems
   for you.  Then it is a MTA problem, and should be fixed.  People
   will do this to you if it causes problems in your software, so you
   must protect yourself from it.

2) example.com administrators did this unintentionally.  They won't
   receive any mail so they will hopefully fix this themselves sooner
   or later.  Even if they don't care and never fixes it, this
   shouldn't cause any problems because other people's MTA should
   handle it as an attempted attack in 1).

So it seems as if the intended target of this draft (or at least for
the example above) is MTA authors.  MTAs should cope with receiving
all these local or reserved addressed as "real" MX, NS etc addresses,
and still do the right thing.  It should be required reading for
anyone writing an MTA.

> people that try to send email to that destination.

Donald just gave an instance were this scenario "didn't seem to cause
much problems" for DEC and "that over the years millions of pieces of
mail were delivered this way".  Why forbid such scenarios?

> that can happen and may put workarounds in.

Yes.  I agree that the draft documents some well known but not
previously documented problems.  You can point newbies to draft and
they will learn something.  Good.  For some more complex setups,
however, these recommendations can be questioned -- such as in the DEC
example, or putting "localhost" in SOA to prevent W2k flooding, or
cases where it is difficult to define what "a public DNS zone" really
is (e.g., if I firewall my mail server so that only people in country
A can access it, should I put its IP address in the global DNS?).

---

From: Rob Austein <[email-masked]>
Date: Tue, 26 Feb 2002 12:18:48 -0500

> pieces of mail were delivered this way.

At the cost of some resources belonging to the people sending the
mail.  Anecdotal evidence goes back at least to the late '80s, when
WSMR-SIMTEL20.ARMY.MIL sometimes had nontrivial backlogs in its
outbound mail queue due to all the delays associated with trying all
those MX relays at sites that did this.  Yes, the mail got through
eventually, and yes, we've learned how to MTAs that are less sensitive
to this kind of problem, but since the situation would have been
completely avoidable if the zone admins hadn't listed all those
unreachable addresses, it's hard to avoid viewing it as (presumably
unwitting) anti-social behavior that's worth discouraging.

Completely gratuitous externalities considered harmful.

---

From: Johan Ihren <[email-masked]>
Date: 27 Feb 2002 11:58:52 +0100

Rob Austein <[email-masked]> writes:

Rob,

> Completely gratuitous externalities considered harmful.

Well, the way of avoiding this would typically by through switching
from 

* a "pure" DNS configuration with a simply connected namespace that
  contains som unreachable nodes 

* to a "split-DNS" setup with a namespace that change depending on
  viewpoint but all nodes are reachable.

I agree to the anti-social properties of optimizing for your own
benefit on someone else's behalf. But in this case I cannot help
wondering whether it is really so much better to try to cater to all
the semi-reachable stuff (nodes that are reachable from certain
vantage points but not all) through the complexities of split-DNS
everywhere.

And when we take into accout the increasing numbers of mobile hosts
that *change* their vantage point over time it can be argued that it
is better to get off the plane and find the same Internet, but with
somewhat changed reachability characteristics, than is is to find a
different Internet because you're on a different side of a split-DNS
gateway point.

Split-DNS is not a general solution to be advocated, it is a general
problem to be avoided. Yes, there are specific cases when it is the
least evil choice, but I really do not want to see it as a general
solution to this type of problem.

Johan

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2002 05:23:04 -0800

> Completely gratuitous externalities considered harmful.

motto of poor dns admin: think locally, act globally

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2002 05:40:20 -0800

[ excuse the metaphoric 'you ]

> vantage points but not all) through the complexities of split-DNS

of course the simple answer is one probably should not build such
sickness in the first place.  but if you insist on such a disease,
why should i pay for your being lazy and doing a half-assed job?

> different Internet because you're on a different side of a split-DNS

won't the mobile host either be
  o tunneled to 'inside' and hence will have the inside view of the
    dns
  o or living outside and hence have an outside view of the dns?

> Split-DNS is not a general solution to be advocated

similarly to the designs it is trying to accommodate.  but, if you
insist on those kinds of designs, you need to do the full job.  don't
complain if insisting on kludge-A leads you to needing kludge-B.  "Oh,
what a tangled web we weave/when first we practice to deceive."

> it is a general problem to be avoided. Yes, there are specific cases
> when it is the least evil choice, but I really do not want to see it
> as a general solution to this type of problem.

i doubt any of us like it.  but if you're gonna make a mess, it seems
your responsibility to contain it.  entropy and all that.

randy

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 27 Feb 2002 14:38:58 +0100

On Tue, Feb 26, 2002 at 07:06:25PM +0100, Simon Josefsson wrote:
> [ ... ]
> [ ... ]

You'be missed the exapmle in the draft, where the admins did this
intentionally to have a MX but they don't want emails at all.
They don't do this to cause any harm intentionally, but they don't know
better.

> and still do the right thing.  It should be required reading for

Sure. IMHO this draft is of general interest and with this topic it
targets MTA authors as well as DNS admins.

> mail were delivered this way".  Why forbid such scenarios?

I have checked with some people who are very familiar with sendmail and
exim. According to them neither of those MTAs has any provisions to
handle the situation effectively. They go best MX, time out and the
backup MX. I know qmail does handle it more effectively, as it maintains
an IP timeout table.

That it works/worked for one company doesn't mean it doesn't cause any
problems. Think of the situation where AOL, yahoo, hotmail and a few
other "big email players" will switch to such a setup and I predict
it *will* cause troubles on your mailserver, of course not on theirs.
You'll get lots of hanging smtp connections waiting for a timeout and
your mailqueue will grow and the load on your server will also.

IMHO the section "4. Unreachable servers" in RFC 2182 "Selection and Operation
of Secondary DNS Servers" applies also to backup MX servers and the
arguments there are well thought out.

> A can access it, should I put its IP address in the global DNS?).

Would you consider your mailserver a "public" mailserver or a mailserver
dedicated to country A ?
As long as you use ACLs on your mailserver to allow emails (not
connections) from country A through and reject all others with a
permanent error code (there's a note about it in the draft as well as in
RFC 2821) I would consider it public. I am aware that this scenario
is different from the DEC one.
If you use a firewall for the ACL task, I'd not consider it public and
ban it in global DNS.

	\Maex

---

From: Johan Ihren <[email-masked]>
Date: 27 Feb 2002 15:07:46 +0100

> [ excuse the metaphoric 'you ]

I didn't see that comment on the first read-through... but fortunately
I did see it before replying ;-)

> > wondering whether it is really so much better to try to cater to
> > all the semi-reachable stuff (nodes that are reachable from
> > certain vantage points but not all) through the complexities of
> > split-DNS everywhere.

> > And when we take into accout the increasing numbers of mobile
> > hosts that *change* their vantage point over time it can be argued
> > that it is better to get off the plane and find the same Internet,
> > but with somewhat changed reachability characteristics, than is is
> > to find a different Internet because you're on a different side of
> > a split-DNS gateway point.

>   o or living outside and hence have an outside view of the dns?

Yes. And those two are *different*, which is exactly my point. They
shouldn't be. If you and I sit down in two chairs next to each other I
see a certain benefit to us being able to share a common view of the
namespace we call the Internet.

Sure, lots of web sites will be down, or unreachable, whatever. But
that's a property that is inherent to any distributed system: parts
may fail or loose contact. Temporarily or permanently. But the
namespace that describes the parts should always be the same.

> your responsibility to contain it.  entropy and all that.

While I agree to the principle (you and I can share the same horse in
the argument against the firewalling brigade) the question I have is
what constitutes the greater evil to the Internet: 

        * a namespace that changes (to the point of being different
          for two people sitting next to each other), but with all the
          stuff you do see reachable 

        * a namespace that is static (in the sense that you and I can
          share it, regardless of whether we're sitting next to each
          other or on opposite sides of the Atlantic), but with some
          stuff unreachable to one or both or us.

It can well be that the first one is better after all, but it is not
obvious to to me that this is the case.

I do not like the semi-reachable stuff myself, but I do realize that
such things are already very common, and are still increasing.

Regards,

Johan

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2002 06:18:25 -0800

> namespace we call the Internet.

given the world of vlans, because we are in the same room does not mean
our laptops are logically in the same room.  as someone whose daytime job
requires a machine tunneled, i am horrifyingly aware of the implications
and consequences.

> the argument against the firewalling brigade)

i was not saddling up rosenantes.  i was mearly saying that, if one is
going to partition the net, then one is responsible for a clean and
thorough job.

> the question I have is what constitutes the greater evil to the Internet:
> 

well said.

but i have a *very* severe alarm that goes off when i see increasing
entropy.  so i choose the former, thems that plays pays.  you do that
stuff, you are a consenting adult.

randy

---

From: Johan Ihren <[email-masked]>
Date: 27 Feb 2002 16:58:11 +0100

Randy,

> given the world of vlans, because we are in the same room does not
> mean our laptops are logically in the same room.  as someone whose
> daytime job requires a machine tunneled, i am horrifyingly aware of
> the implications and consequences.

I don't care whether we're on the same planet. I only care whether we
both claim to be on *the* Internet, and the criteria for that should
be that we share the namespace. All of it.

As the v4/v6 transport discussions show, the namespace is really what
matters to define the Internet. Not shared transport. And therefore
(almost *by definition*) not identical reachability.

I really think that you and I agree on this...

> going to partition the net, then one is responsible for a clean and

I agree that should be the goal.

> stuff, you are a consenting adult.

I agree to consenting adult part, but I do not agree that split-DNS
everywhere, as an attempt at painting over the semi-reachability
problem, minimizes entropy. As any painter knows: with sufficiently
bad groundwork, no amount of paint will make it look nice. And in this
case the paint is of highly questionnable quality.

Let me put the argument this way (in my day job as the devil's advocate):

* DNS is about the namespace and it's coherency. 

* The transport layer is about reachability.  

* The application layer is about coping with lack of reachability.

By trying to solve this in DNS, couldn't it be that you're working in
the wrong layer?

Johan

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Feb 2002 21:32:21 -0800

[ again, sorry for the metaphoric 'you' ]

> be that we share the namespace. All of it.

when one of us *chooses* to be behind a partition, they are knowingly
not on the Internet.  many consequences flow from that.

> (almost *by definition*) not identical reachability.

yup.  and when one of us leaves the Internet, the namespace will most
probably be different.

i suspect this is the core of our difference.

i see it as our responsibility to see that v4 and v6 transports are just
different transports on the same interney.

i see it as 'your' responsibility to live with the altered physics when
you, irregardless of transport, *leave* the internet by moving behind
a firm boundary.

> problem, minimizes entropy.

maybe not in the short term.  but in the long term, once you go down the
path of accepting chaos, it only gets worse.  heat death of internet
predicted. news at eleven. :-)

> * The application layer is about coping with lack of reachability.

[ i don't think i buy this last splat ]

> By trying to solve this in DNS, couldn't it be that you're working in

no.  i think where we differ is that i really think that when you go
behind a firewall, or something else that changes visibility, you have
left the internet.  if you then want to communicate to the internet,
it is your responsibility to compensate for all the wierdnesses which
you have chosen to impose.  it should not become everyone else's
problem.

i am not trying to solve anything in the dns.  i am asking you not to
leak your problem *into* the dns.

[ btw, i thing this is a useful argument to have.  thanks ]

randy

---

From: Philip Hazel <[email-masked]>
Date: Thu, 28 Feb 2002 09:09:37 +0000 (GMT)

> backup MX. I know qmail does handle it more effectively, as it maintains

I am very familiar with Exim (I wrote it :-). It *does* have provisions
to handle these problems. Of course it tries the best MX first, times
out, and then goes to backup. But it remembers that the best MX timed
out, and it won't try it again until its retry time arrives. As time
passes, the retry time increases (configurable, but normally gets up to
about 6/8 hours max). Thus, after a while, most messages will go
straight to the backup, with a new attempt at the best MX every now and
again. (I guess this is the same as "an IP timeout table".)

Exim also has a provision to handle the MX->localhost->127.0.0.1
problem. You can configure it to ignore certain IP addresses that come
up in a DNS lookup. Typically, 127/8 are ignored. Exim behaves as if the
A records don't exist.

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Feb 2002 16:18:33 +0700

Date:        Wed, 27 Feb 2002 21:32:21 -0800
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | i see it as 'your' responsibility to live with the altered physics when
  | you, irregardless of transport, *leave* the internet by moving behind
  | a firm boundary.

There's a presumption in this that leaving the internet is a voluntary
choice, made by a party that is excluded.

If your ISP decides that they don't like your mail behaviour (perhaps
you say bad things about them in public...) and filters you - whose
responsibility is it to then "hide" the problem by rearranging MX records
so mail can get delivered without delaying other sites MTAs attempting to
connect to filtered addresses?

Of to be even more bizarre, if I decide to filter (the metaphoric) you,
so my MTA cannot reach your MX target, who should be dealing with that
as a problem?   You're the filtered one after all.

Filtering creates all kinds of issues, and simply deciding that someone
else should "fix" it seems to me to be outside reality.

kre

ps: is this discussion about the "don't publish unreachable" draft, or
about the "v4-v6 namespace fragmentation" draft?   I would have guessed the
former, but some of the comments make me believe that it might be about
the latter - it would be nice if the Subject header gave some clue...
I know that the meeting agenda item is v4-v6, but most of the discussion
seems to be about whether unreachable addresses should be published.
All very confusing...

---

From: Johan Ihren <[email-masked]>
Date: 28 Feb 2002 11:13:30 +0100

Hi Randy,

> [ again, sorry for the metaphoric 'you' ]

Don't worry. You have a strong opinion here. My position is to a large
extent to be "opposite Randy", so I accept the consequence of being at
the center of your cross-hairs ;-)

> not on the Internet.  many consequences flow from that.

Yes, this is clear. The question is whether the Internet benefits from
you not sharing your view.

> yup.  and when one of us leaves the Internet, the namespace will most

I agree it will (obviously this is common today), but I argue it
should not unless you can prove to me that this is a *benefit* to the
Internet.

> i suspect this is the core of our difference.

No, it is not. The core is whether this is a DNS problem or an
application problem. Unreachability is a fact. Changing the namespace
is a *choice*.

> different transports on the same interney.

They simply cannot be. Not with your definition of "same Internet". I
define "same Internet" as "same namespace" (and that will work
here). You define it (as I understand) as "1-1 reachability for any
given pair of nodes". And while I (very strongly) sympathize with your
definition, it simply will not work for the v4/v6 transport case.

Of course there will be nodes in the mesh that are unreachable to
other nodes, since they share no transport. And I argue that they
should still be allowed in the DNS, since although unreachable, they
are also unambigous, which should be the determining criteria.

> you, irregardless of transport, *leave* the internet by moving behind

I have no problem with that responsibility. When I go behind your
firewall my Kerberos authetication fails, since you block port 88. An
application problem. That's fine. I would however be most disturbed if
I couldn't eve look up my Kerberos server, or worst of all, your
warped namespace directed me in a new and unwanted direction. Ick!

> [ i don't think i buy this last splat ]

I'm not claiming that the apps layer is *only* about lack of
reachability, of course. My claim is that in the context of
reachability, namespace shielding and such that we're discussing, the
apps layer *must* be able to cope with unreachability, since you
*cannot* shield it entirely.

The way DNS helps out is through *redundancy*, not by erasing what is
not right now reachable from exactly whereever. Going in that
direction lies near-realtime dynamic update of apps services in DNS.

And madness.

> leak your problem *into* the dns.

Wrong. The DNS has no problem coping with unreachable nodes in general
(let's exclude nameservers for the moment). It is the applications
that have problems. And when you, unsuccessfully, try to patch that
application problem by recommending that the Internet namespace should
be chomped up into lots of almost but not entirely equivalent views
you are, indeed, pushing an application problem into the DNS.

And, as I've said before: perhaps you should, but then you should do
it with open eyes. 

What do you say about the following statement? Can you agree to this:

        "It is split-DNS that fragments the DNS, not the
        semi-reachable stuff by itself"

If you can, then I think we're within reach of closure on this topic...

> [ btw, i thing this is a useful argument to have.  thanks ]

Absolutely. Like an appetizer to the upcoming foodfight ;-)

Johan

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 28 Feb 2002 11:39:48 +0100

--On Wednesday, February 27, 2002 05:40:20 -0800 Randy Bush <[email-masked]>
wrote:

<snippety> 

> your responsibility to contain it.  entropy and all that.

Definitely agree -- but, most of the problems with ugly solutions seems to
stem from the fact that they tend to require more clue to maintain, while
of course clued people tend to stay away from kludges.. 
Some down-to-earth advice might work wonders here. 

(I've had a rant building up about this. It remains to be seen if it will  
 turn out useful or just produce hot air.. don't hold your horses ;-) )
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

---

From: Johan Ihren <[email-masked]>
Date: 28 Feb 2002 12:34:52 +0100

> else should "fix" it seems to me to be outside reality.

Well said.

> kre
> 
> ps: is this discussion about the "don't publish unreachable" draft,
> or about the "v4-v6 namespace fragmentation" draft?  I would have
> guessed the former, but some of the comments make me believe that it
> might be about the latter - it would be nice if the Subject header
> gave some clue...  I know that the meeting agenda item is v4-v6, but
> most of the discussion seems to be about whether unreachable
> addresses should be published.  All very confusing...

It is really about both, in a general sense. They are connected in
devious ways, which I think is becoming obvious to anyone who has had
the stamina to follow us this far.

But at a higher level it is not about any of them, but rather about
the definition of "the Internet" (wow, how's that for a meta-discussion?).

There are two choices of definition:

* "1-1 mutual reachability for any pair of nodes, adjust the namespace
  to fit". Let's call this "Internet Classic".

* "same namespace, regardless of reachability". Let's call this
  "Internet Noveau".

and their respective consequences are:

* with the classical, definition the v4/v6 migration goes down in
  flames (since that definition makes v4 and v6 *different* internets
  rather than different transports for the *same* Internet). Then they
  *should* have different namespaces.

* with the latter definition v4/v6 migration becomes at least
  teoretically possible, since nodes are allowed to be unable to reach
  each other while still inhabiting the same Internet. But instead
  split-DNS becomes bad form, since the unreachability characteristics
  should not be tracked in the DNS namespace.

I really don't think that I can make the choice any clearer than that.

It should also be pointed out that with the latter definition we raise
the requirements for the v4/v6 DNS transport bridging ickiness, while
with the former we lower them.

Johan

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Feb 2002 05:10:52 -0800

> Some down-to-earth advice might work wonders here. 

which, i presume, is the purpose of philip's exercise.  thanks for saying
it far more simply that i seem to be able to.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Feb 2002 05:38:29 -0800

> the center of your cross-hairs ;-)

what i meant was the use of the word 'you' when it is not really you who
is moving behind a wall.  it's a limitation of english.

> application problem. Unreachability is a fact. Changing the namespace

and then in your response to kre you say the opposite, that the definition
of the internet is at the core of the issue.

i really don't have anything new to say, so will relieve you of having to
read it.

randy