Date: Wed, 9 Oct 2002 12:18:09 -0700
From: "Dave Thaler" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
It should be fairly obvious by now that I haven't yet read the
scoping-arch doc ... Normally I wouldn't comment about something
I haven't read, my excuse is that that's not what I thought I was
doing here, I though I was commenting on the addr-arch-v3 doc,
which is the one in the subject...
That so much of this is turning on points related to the scoping-arch
doc, which isn't even a PS yet, suggests to me that:
| > > So, this would be consistent with the suggestion that we
| > > change the Addr Arch document to list subnet-local and larger
| > > scopes as administratively defined (instead of just admin-local
| > > and higher)?
| >
| > Yes. Given the issues with magically setting the subnet-local
| > zone id when multiple prefixes are enabled on an interface I
| > would agree with that change.
|
| I would disagree with that change.
So would I. The change I would make is to delete all references
of subnet-local from the addr-arch doc, and simply leave those values
as "to be defined" and then define them in the scoping-arch doc.
Sticking new stuff in docs, as they're in the process of going from PS
to DS is generally not proper, and while just defining a new number is
probably not going to be the kind of thing that would cause a problem,
doing so when there is no existing meaning for that number will just
lead to potential confusion.
That is, what happens if addr-arch is published as a DS, and even gets
to full std, with "subnet-local scope" in it, but the IETF never finishes
defining the subnet local stuff, and it eventually all just vanishes from
sight?
In 20 years, people will be wondering what this strange definition of
a subnet local scope, that has no meaning is all about.
Best is to remove it from the current doc, and place the definition
where it really belongs. Let's not have the addr arch doc anticipate
what might come in the future,
| The zero-config counter argument is a box that is labeled as
| having its default configuration be that interfaces are on the
| same subnet different but different links (e.g. guaranteed
| to be different because they're different media, like an
| 802.11 access point with a wired Ethernet link).
That's not a good example. Remember the "link" we're talking
about here isn't a physical link - that idea vanished when repeaters
were first invented (which was just about the same time as ethernet).
A link for our purposes is the place where broadcast/multicast packets
will go, and that can certainly cross a wired/wireless ethernet boundary.
Not that it always will, but it certainly can, so "guaranteed to be
different" isn't the case there.
A better example would be a subnet made up of an ATM link and an
ethernet link (where the ATM is not running LANE). Or to be more
perverse perhaps, an X.25 link and an ethernet link. There, the
link level address formats differ, so they cannot possibly be same
link. (There are plenty of other examples).
I'm not sure I'd expect to see many zeoconf boxes that fit this
"guaranteed to be different" kind of model ever actually appear.
So I'm not sure I'd be treating arguments about what they might do
very seriously.
I'm also not sure I really like the restrictions that seem to be
being proposed for subnet-local - they seem to blow away some of
the expectations I'd had for where and why I'd actually want to
use multi-link subnets (which certainly isn't as some kind of alternative
to bridging wireless and wired lans).
But I will wait until after I have actually read that draft before
I make comments about that.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
