Subject: Re: Not Ready for Draft? draft-ietf-ipngwg-addr-arch-v3-10.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Oct 2002 10:33:56 -0400

Robert,

I believe we are just going to disagree on the issue you have.

You seem to be saying that the addr arch document (in order to go to
Draft) requires that there exist at least 2 implementations that
enforce the requirement that IIDs are exactly 64 bits. That is, they
MUST NOT allow IIDs of length other than 64 to be used/configured.

The actual requirement that IIDs be 64 bits is not an implementation
requirement (in the addressing architecture document). It is a
principle that is to be followed by other documents that specify usage
of the IID. The last part of Section 2.5.1 says:

   The details of forming interface identifiers are defined in the
   appropriate "IPv6 over <link>" specification such as "IPv6 over
   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.

All the other IPv6 over foo documents are consistent with addr arch in
this regard.

I also remain unconvinced that the wording:

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

translates into a requirement that there exist implementations that
disallow IIDs of length other than 64. Following this logic, I suspect
one could effectively prevent just about any document from being
advanced to Draft. Documents typically have a number of principles
that are not testable or enforceable, or where no one would bother to
actually enforce something because the actual cost is too
high. Consider:

>     2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
> [...]
>    |                80 bits               | 16 |      32 bits        |
>    +--------------------------------------+--------------------------+
>    |0000..............................0000|0000|    IPv4 address     |
>    +--------------------------------------+----+---------------------+
>    Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
>    must be a globally-unique IPv4 unicast address.

What implementations prevent a non-globally unique IPv4 address from
being used here?  By your logic, this requirement would need to be
stricken from the document.

Or:

>    All interfaces are required to have at least one link-local unicast
>    address (see section 2.8 for additional required addresses).

By your logic, we have to show that there are implementations that
actually enforce that. I.e, it's not enough that implementations in
practice assign a LL address to an interface, we need to show that
there are implementations that prevent the possibility of the
interface ever operating without a LL address. This is unreasonable.

As a more general case, consider a protocol that specifies behavior
X. For example, protocol X must rate limit messages of type Y. Well,
anyone can come along and implement protocol X over raw sockets and
have it flood the network with messages of type Y violating the
required rate limitingf behavior.  By your reasoning, an
implementation of a protocol that doesn't also prevent another
implementation running over raw sockets from violoating the spec would
not be compliant. In general, no implementation can ensure that the
spec is not violated when viewed in this light.

Popping up a level, the arguments being used are fairly legalistic (on
both mine and your side). Based on some of your earlier mail messages
to the WG, it would seem that your real goal here is to do away with
the requirement that all IIDs be 64 bits long and in particular you
would like to remove the 'u' bit from the IID. But this was discussed
explicitly within the WG and there appeared to be little support for
your position.

It is time to advance addr arch to Draft Standard and move on.

Thomas
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Oct 2002 23:33:11 +0700

Date:        Wed, 02 Oct 2002 10:33:56 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | I believe we are just going to disagree on the issue you have.

That may be, but I would hope that there is at least one member of
the IESG who understands that 2026 is not just there to be disregarded
when it is inconvenient.

  | You seem to be saying that the addr arch document (in order to go to
  | Draft) requires that there exist at least 2 implementations that
  | enforce the requirement that IIDs are exactly 64 bits.

Either that, or the text that is in doc that requires that needs to be
removed.   Yes, that's what 2026 requires.

  | That is, they
  | MUST NOT allow IIDs of length other than 64 to be used/configured.

Yes.   The text quite clearly states that IIDs are required to be 64 bits.

Why exactly is it that you can't find the two implementations of this
that would make my argument here irrelevant?  I suspect that you have
tried.   That would be a simple answer.   It doesn't matter much what
the answer is, whether the requirement is unimplementable (which I doubt,
a "if (prefixlen != 64) return (EINVAL);" would be pretty easy to add...)
or whether it is just that in practice, everyone believes that this is
a nonsense requirement, but in any case, it is not being implemented, and
hence cannot be in a DS.

  | The actual requirement that IIDs be 64 bits is not an implementation
  | requirement (in the addressing architecture document).

Hmm - that's another interesting argument.   But go read it again.
The doc doesn't say that other specs must not define IIDs to be any
other length (to which I would object, I think, or not because of the
requirement itself but because I don't believe that docs should
ever specify what other docs are allowed to define - it is a dumb
thing to attempt in any case).   What it says, quite clearly, is that
the IID must always be exactly 64 bits.   No restrictions upon in what
contexts (just the couple of well known assumptions).

If the doc wanted to set out reasons why people should only ever use
64 bit IIDs, without actually making that a requirement, that would be
fine, but that is not what it is doing.   It doesn't even attempt to
justify the requirement, there's no rationale at all, it is simply
stated.

  | The last part of Section 2.5.1 says:
  | 
  |    The details of forming interface identifiers are defined in the
  |    appropriate "IPv6 over <link>" specification such as "IPv6 over
  |    Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.

Yes, but that's how the IID is to be created, not now big it is to be.
And in any case, that sentence is fine.

  | I also remain unconvinced that the wording:
  | 
  |    For all unicast addresses, except those that start with binary value
  |    000, Interface IDs are required to be 64 bits long and to be
  |    constructed in Modified EUI-64 format.
  | 
  | translates into a requirement that there exist implementations that
  | disallow IIDs of length other than 64.

I can't see how you can avoid "are required to be 64 bits long".

  | Following this logic, I suspect
  | one could effectively prevent just about any document from being
  | advanced to Draft.

Only ones that shouldn't be advanced.  And note, all that is required to
allow it to advance, is for the unimplemented feature to be removed.

  | Documents typically have a number of principles
  | that are not testable or enforceable,

The ones in question here are both testable and enforceable.  So,
that isn't relevant.   But if the WG wanted to rewrite this one as
a general guideline or something, it would probably cause less problems.
That is get rid of the "are required to be" language etc.

  | or where no one would bother to actually enforce something
  | because the actual cost is too high.

This is exactly (one of) the case(s) where 2026 should apply.   If a
doc is requiring something that cannot be implemented (reasonably) then
the requirement should be removed.

If that isn't done, then someone who later takes the doc, knows it is
a DS (or more), and hence knows that it has been fully implemented, gets
the thing, and then says "OK, all of this is proved implementable, I
have to implement it all", not knowing that everyone who went before
knows this is a joke, and that no-one actually bothered implementing
some particular part, because it is too hard, or just plain wrong, or
just unwanted (not useful) in practice.

This is exactly why 2026 requires at least 2 implementations of *everything*.

  | Consider:
  | 
  | >     2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
  | > [...]
  | >    |                80 bits               | 16 |      32 bits        |
  | >    +--------------------------------------+--------------------------+
  | >    |0000..............................0000|0000|    IPv4 address     |
  | >    +--------------------------------------+----+---------------------+
  | >    Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
  | >    must be a globally-unique IPv4 unicast address.
  | 
  | What implementations prevent a non-globally unique IPv4 address from
  | being used here?  By your logic, this requirement would need to be
  | stricken from the document.

Yes.   I had noticed that one.   And yes, it should go as well.   This
one happens not to concern me greatly, so it isn't one I had commented on
yet.

Note in this case, a correct (and entirely adequate) solution would be
just to reword the doc a little, to make it clear that using something
other than a globally unique IPv4 address will result in undefined behaviour.
That is, rather than forbidding it, just undefine it.

  | Or:
  | 
  | >    All interfaces are required to have at least one link-local unicast
  | >    address (see section 2.8 for additional required addresses).
  | 
  | By your logic, we have to show that there are implementations that
  | actually enforce that.

Yes, absolutely.   I had assumed that had been done.   I know of 
implementations that automatically assign a LL address whenever IPv6
is enabled on an interface, precisely because of that.  There is no
way to get an IPv6 interface without a LL address on it.  I'd assume
there are at least 2 such implementations, and that that was tested
in the interop report.   I wasn't part of the testing, so I don't know
for sure.   Certainly I'd hope that *all* implementations enforce this,
and that none permit an IPv6 interface to exist without a LL address.
That's one of the basic IPv6 requirements, I would have thought, but
for DS we only need two of them.

  | I.e, it's not enough that implementations in
  | practice assign a LL address to an interface, we need to show that
  | there are implementations that prevent the possibility of the
  | interface ever operating without a LL address. This is unreasonable.

No, it isn't, it is exactly what is required.   What would be the use of
having the requirement there, if you couldn't count on it being implemented?
If this were merely more fluff in the spec, then yes, it too should be
removed.   This one however, isn't.

  | As a more general case, consider a protocol that specifies behavior
  | X. For example, protocol X must rate limit messages of type Y. Well,
  | anyone can come along and implement protocol X over raw sockets and
  | have it flood the network with messages of type Y violating the
  | required rate limitingf behavior.  By your reasoning, an
  | implementation of a protocol that doesn't also prevent another
  | implementation running over raw sockets from violoating the spec would
  | not be compliant. In general, no implementation can ensure that the
  | spec is not violated when viewed in this light.

Huh?   What kind of logic is that?   There have to be (for DS) at least
two implementations of the protocol which implement the feature.   How
many others (for DS) exist that don't, is irrelevant (it becomes relevant
when the spec is due for full std status).   Here you seem to be confusing
the implementation, with the system that runs the implementation.  That
a system can run both a conforming implementation, and a non-conforming
one is interesting, but not relevant, the conforming one counts as one of
the implementations that is required.

If the only implementation of the protocol on the system in question was
the one on raw sockets, with no rate limiting, then that couldn't count
as one of the required two implementations, obviously.  If there weren't
two other implementations that actually implemented the rate limiting, then
that would have to be removed.

Note that 2026 does not require that no implementations get it wrong.
For DS it just requires that (at least) 2 (independent) implementations
get it right.

  | Popping up a level, the arguments being used are fairly legalistic (on
  | both mine and your side).

They revolve around what 2026 requires.  Yes.   If that's "legalistic"
then so be it.

But there are very good reasons for 2026 requiring what it requires.
If you want to change that, then go create yet another son of poisson
WG, and we can look at a revision of it.  (It would be kind of neat
to have a poisson2 group (in the tradition of poised95...) created
this year...)

  | Based on some of your earlier mail messages to the WG, it would seem
  | that your real goal here is to do away with the requirement that all
  | IIDs be 64 bits long and in particular you would like to remove the
  | 'u' bit from the IID.

Yes.   I do want to do away with both of those.   Partly because
they're both such nonsense requirements that no-one is implementing
them, and people are configuring interfaces using IIDs that aren't
64 bits long (remember the thread, on some other list, ngtrans, or
v6ops, or something I suspect) about why operators do this?

  | But this was discussed explicitly within the WG and there appeared
  | to be little support for your position.

Actually no.  If you go back and look at the record, I think you'll see
that there was much more support for a change than for no change.  Just
re-read the messages and see.   The best the chairs could come up with
was "no consensus to change the doc".   Nb: not "consensus against
changing the doc."   As I recall it, just about the only real opposition
(actually stated on the list) to changing this came from you...

(I don't know, obviously, but it is possible that the chairs then
believed that they couldn't change the doc, because attempting to specify
something that an IESG member doesn't like, or not to specify something
that they do like, can cause a doc to get held at "discuss" in the IESG
forever...)

Even one of the WG chairs, in the message that started this discussion
(in its most recent go around anyway) said, on the list, on Aug 4 ...

	Unfortunately, operators seem to be ignoring this restriction in
	numbering point-to-point links between routers.  I have spoken to 
	a few IPv6 operators, and it is common practice to use /125, /126
	or even /127 prefixes for these links.

	What does this mean for us?  Well, in my opinion, we don't want
	to standardize a restriction that we _know_ will be ignored by
	the folks who are deploying the software.
   
Exactly correct.   But even more than that, 2026 does not allow us to
advance documents that specify things that no-one uses.

But apart from that, once again, what the WG wants in this area is
irrelevant.   2026 places some mandatory requirements on docs advancing
through the process.  If they're not met, then it wouldn't matter if the
doc had 100% overwhelming consensus of the whole IETF, it still could
not advance (except that most likely, no-one would point out the defect
and it could just be silently ignored).

  | It is time to advance addr arch to Draft Standard and move on.

If the IESG can convince itself that this doc has actually met the
requirements for DS, as enumerated in 2026, then it can go ahead and
vote for that I guess.

I kind of hope that it is fairly obvious to just about anyone however
that the requirements in this case are not met.   I suspect that it is
even obvious to you, you're just trying to find some kind of argument to
allow them to be side-stepped here.

Incidentally, I sent the first message on this thread to the IESG (only).
Since then, it has been between us, with cc's going to both the IESG
and the WG.   But it has never been made clear whether in this small
exchange you've been speaking on behalf of the IESG, or just making
your own personal arguments.   Which?

kre

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Oct 2002 13:17:53 -0400

Robert,

> that they do like, can cause a doc to get held at "discuss" in the IESG

If you believe there is some sort of process problem here, there are
appropriate channels for raising such issues. Wondering whether there
may be an issue here while at the same time not actually raising the
issue is not helpful, IMO.

> your own personal arguments.   Which?

To be clear, I'm speaking for myself, as one of the INT ADs, and the
Area Advisor for this WG in particular.

The other ADs, who have been cc'ed on this thread, will form their own
opinions I'm sure.

I chose to cc my original response to your note back to the ipng
mailing list as a small step in having the IESG be more transparent.

Thomas

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 02 Oct 2002 13:43:10 -0400

Hi Robert,

>that they do like, can cause a doc to get held at "discuss" in the IESG

This is not the case, at all...

>(in its most recent go around anyway) said, on the list, on Aug 4 ...

Yes.  I expressed a personal technical opinion (which I still hold).  But,
there was not sufficient support for my opinion on the WG mailing list to
constitute a consensus to make a change to the document.  I accepted
that fact, and the change was not made.

Margaret

---

From: Robert Elz <[email-masked]>
Date: Thu, 03 Oct 2002 14:35:38 +0700

Date:        Wed, 02 Oct 2002 13:17:53 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | If you believe there is some sort of process problem here,

I didn't say that.  I didn't ever say there was consensus to change
things, just as no-one (other than perhaps, by implication, you in your
recent message, ever claimed there was consensus not to change things).

I did some idle musing, based upon experience of WG's sometimes deferring
their opinion of what is technically best, to demands of the IESG.
But that was never anything more than wondering.

But even if I did believe there was a problem in this case, I
wouldn't bother with ...

  | there are appropriate channels for raising such issues.

because it wouldn't matter anyway.   Wasting everyone's time debating
process issues that simply don't matter isn't productive.   Here, it
doesn't matter, as whatever the WG consensus was, 2026 gives the WG
(and the IESG) no choice in the matter (or not unless someone revises
2026 first).

Of course, the WG can decide to recycle the doc at PS if it wants to.
But so far anyway, I don't think there's been any consideration to that.

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 04 Oct 2002 16:34:02 +0900

>>>>> On Wed, 02 Oct 2002 10:33:56 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> All the other IPv6 over foo documents are consistent with addr arch in

I don't want to delay the publication of the draft, but there is one
thing which has always been unclear to me.  So please let me ask a
question.

Then the "other documents" should be considered as an implementation
requirement?  For example, does RFC 2464 require implementations to
use 64-bit interface identifiers (and prohibit using shorter or longer
identifiers) on ethernet links?  Also, does RFC 2374 require
implementations to use 64-bit interface identifiers (and prohibit
using others) for aggregatable global unicast addresses?  If so (for
both questions), how can we configure an aggregatable global address
on a link which has an "IPv6 over foo" document requiring a different
length than 64 as interface identifiers?

I cannot be clear on those questions just from the specification
documents.  Perhaps there have been discussions on this that make the
points clear, and I'd apologize in advance if so, then please give me
a pointer.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Oct 2002 22:40:58 +0700

Date:        Fri, 04 Oct 2002 16:34:02 +0900
    From:        JINMEI Tatuya <[email-masked]>
    Message-ID:  <[email-masked]>

  | Then the "other documents" should be considered as an implementation
  | requirement?

I'm not sure what you are meaning there?

  | For example, does RFC 2464 require implementations to
  | use 64-bit interface identifiers (and prohibit using shorter or longer
  | identifiers) on ethernet links?

No, nothing like that at all.   It requires 64 bit IIDs for stateless
autoconfiguration to work, which is hardly a surprise (and defines 64 bit
IIDs for link local addresses, which is also not exciting) but apart from
that, there is no reason for that doc to express any kind of requirement
on this, and so it, quite correctly, doesn't.

  | Also, does RFC 2374 require
  | implementations to use 64-bit interface identifiers (and prohibit
  | using others) for aggregatable global unicast addresses?

No, it doesn't.   That doc kind of assumes the 64 bit IID requirement
from the addr arch doc, but nothing in it in any way depends upon that.
It is mostly concerned with the upper part of the address (how the
prefix is divided up for allocation purposes).   Personally I'm not sure
the IETF should be getting involved in attempting to specify that in
any way (though giving some examples of how it might be done is fine).
But in any event, it really has no bearing on the topic being discussed
in this thread.

  | I cannot be clear on those questions just from the specification
  | documents.

I'm not surprised, and I sympathise.   Part of the problem is that these
docs are attempting to over specify that which does not require specification
at all.

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 05 Oct 2002 01:09:08 +0900

>>>>> On Fri, 04 Oct 2002 22:40:58 +0700, 
>>>>> Robert Elz <[email-masked]> said:

> I'm not sure what you are meaning there?

I meant to refer to the following part

>> It is a
                                       ^^^^^^^^^^^^^^^
>> of the IID.

and asked if the usage specified in the "other documents" is an
implementation requirement or not.

					JINMEI, Tatuya

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Oct 2002 23:39:58 +0700

Date:        Sat, 05 Oct 2002 01:09:08 +0900
    From:        JINMEI Tatuya <[email-masked]>
    Message-ID:  <[email-masked]>

  | and asked if the usage specified in the "other documents" is an
  | implementation requirement or not.

Sorry, I'm still not understanding.   An implementation requirement
of what?   Addressed to whom?

Clearly what 2464 says includes requirements upon implementations of
2464.    I don't think 2374 really requires much of anyone, it just
(attempts to anyway) tell the registries (and sub-registries, etc)
how to allocate addresses.

I don't think they're directly related to the addr arch doc though?
Or not to the current issue anyway.

The quote from Thomas in your earlier mail was just his attempt to
use 2464 (etc) as demonstrations that 64 bit IIDS had been implemented
as specified by addr arch (interpreting addr arch as a specification for
RFC writers, rather than anyone else).   They wouldn't be relevant, even
if this was reasonable, as they don't actually specify what Thomas was
hoping or assuming that they do, and so don't further his argument.

The whole rest of the community can just ignore that little bit of by-play
I think.

kre