On  5 Mar 2009, at 12:37, Lars Eggert wrote:
It would not set a precedent that the IETF is approving *all*
such proposals, but it would set the precedent that the IETF
has approved *one* such proposal.

Please forgive me, but I disagree that the above is
a well formed concern.

Permitting one proposal to move forward as Informational has
NEVER implied that some different proposal needs to be approved
as either Informational or standards-track.

There is A LOT of IESG/IETF/WG history of approving one thing
and not approving another, for a wide range of protocols
in a variety of different IETF Areas for many many years now.

At that point, we're arguing about whether IPv6 options
for one kind of walled garden vs. another kind of walled garden are OK.

I do not agree with this.

In particular, I don't think it is either accurate or descriptive
to call "MLS networking" a walled garden.  I agree it has significant
differences from the global Internet, but those differences are
fundamentally due to differences between any single-level OS
and any multi-level OS.

My personal opinion is that "profiling" (to use an ITU-T term)
of core Internet protocols is counterproductive. They are what
makes the Internet universally interoperable, and creating
non-interoperable flavors is something the IETF should attempt
to prevent and not foster.

This isn't profiling, nor is it an ITU-T proposal, nor
(to the best of my knowledge) is this similar to any ITU-T concept.

Now, there is widespread profiling, particularly for IPv6.
Many countries, including but not nearly limited to the USA,
have national profiles for IPv6-related IETF standards.
The IETF has even engaged in profiling of its own specifications
sometimes.

(I'd be fully OK with MLS IPv6 moving to a separate EtherType,
but I don't think that's on the table for discussion.)

Well, if that happened, commercial vendors (for all IPv6 products,
not just MLS ones) likely would simply move all IPv6 traffic
to that new EtherType (or have implementations handle either
EtherType identically and using a common send/receive/forwarding
implementation).

In that outcome, if my guess is correct (and my guess might not be :-)
then the IETF's decision-making would be circumvented.  I don't think
that is really in the best interest of the IETF -- and I am trying
to look out for the IETF (speaking as someone who has been active
in IETF for a couple of decades now).

If the IETF is the standards body for all IPv6 uses and extensions,
as it claims to be, it would be quite odd to refuse to consider
such IPv6-related proposals.

The IETF is this standards body, and it has considered the proposal. The question now is whether it should approve it.

Yes, and just to be clear, but not "approve it as a standard",
rather "not object to publishing this option as an Informational RFC".

If I got my history straight, the IPv4 sensitivity label dates
back to DARPA days, i.e., to a time when the US government
funded much of Internet research and deployment, and the resulting
protocols reflect that to some degree.

At a high-level, that's about right...

DARPA did fund much of the Internet research from about 1970 through
much of the 1980s.  However, by 1990, most of the Internet research
was NOT DARPA funded, and nearly all of the development was done by
commercial firms (e.g. Cisco, 3COM, DEC, HP, and Sun).  DARPA was
still funding the BSD development part way into the early 1990s,
but 4 BSD wasn't a MLS system.

I question whether a 1:1
mapping of that technology into IPv6 is a good engineering choice today.

If you have a concrete better proposal, people would like to read
the Internet-Draft.  This topic is NOT new.  It has been discussed
in various places in the IETF, off and on, for at least 8 years now.
So far, no concrete better proposal has appeared.

How long do we want to stall the IPv6 migration of MLS networks ?

A secondary concern is that this document resurrects IPv4 technology
that has been declared Historic for continued use with IPv6,

RFC-1108 was declared Historic over objections from the very few
IETF participants who know MLS users.

I didn't follow that process, but this decision did require and get IETF consensus, i.e., the IETF decided that the technology is obsolete for IPv4.

I contested then, and even now contest, that there was ever
any real IETF consensus either way on the topic of deprecating
RFC-1108.

You may disagree with this decision, but it was made. Because it was made, I question why it makes sense to resurrect obsolete technology in IPv6.

Where is the I-D with a concrete proposal for an alternative solution ?

This current I-D has been out publicly for ~2 years now.  An IETF-wide
4 week last call was made last fall, with little feedback either way.

The comments that were received have been addressed by subsequent
edits to this I-D, including the comments made during the past month
or so on this list.

Using labelled IPsec was the original plan for IPv6 MLS networks,
as a check of the original IPsec RFCs (written by me) should reveal.
Since then, over the past ~13 years, various efforts have been made
to create/use a labelled IPsec approach for MLS environments.  Both
implementation experience and operational experience has shown that
my  (and the IPv6 WG's) earlier hope and belief (i.e. that labelled
IPsec would be a sufficient substitute for these labels) was incorrect.

If this effort has failed and the plan now is to go back to IP-based MLS,
I believe we should explicitly discuss whether the IETF community
wants to go that way, rather than implicitly making it so by allocating a codepoint.

Right.

This is why an IETF-wide 4 week last call was held last fall,
and this I-D was edited to address the (limited) feedback.  It is
also why this was explicitly discussed here more recently, again
with (limited) feedback that has now been addressed by recent
revisions of the I-D.

Frankly, much MORE discussion of this I-D has happened already
than EVER occurred on the IESG's deprecation of RFC-1108 a few
years back.

And the review for this I-D has already FAR exceeded the process
requirements of RFC-2026 as amended.

There is an old fishing expression,
        "It is time to either fish or cut bait."
and that is really where this topic is right now.

Yours,

Ran
r...@extremenetworks.com


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to