Re: RE: AD request / L2 Triggers Chapter Statement

Vernon Schryver <[email protected]> Mon, 17 Jun 2002 14:55:14 -0600 (MDT)
Newsgroups gmane.ietf.pilc
Message-ID <[email protected]>
> From: "James Kempf" <[email protected]>
> To: "James Carlson" <[email protected]>,
>    "Phil Neumiller" <[email protected]>,
>    "Lloyd Wood" <[email protected]>,
>    "JinHyeock Choi" <[email protected]>,
>    =?iso-8859-1?B?wMzB9sjG?= <[email protected]>,
>    "Alper E. YEGIN" <[email protected]>, "Mc.Ky" <[email protected]>,
>    "Behcet Sarikaya" <[email protected]>
> Cc: "Einar Vollset" <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>, <[email protected]>,
>    <[email protected]>, <[email protected]>,
>    "Vernon Schryver" <[email protected]>,
>    "Kamesh Medepalli" <[email protected]>

(I've somewhat trimmed that list of addresses,  perhaps too much
and also perhaps too little.  As someone else said, you guys really
ought to just subscribe to the mailing list instead of forcing
everyone else to get two or more copies of everything.))


> RFC 2460 has an explicit requirement on L2 for IPv6 that it support path
> MTU discovery and that layer 2 either handle segmentation and reassembly
> itself or that this be done in the driver by a shim. The requirment is
> abstract, in that it does not specify how the requirement should be
> implemented for a particular layer 2..

So what?  It is also silent about many other implementation issues that
cannot be detected on the wire or tested for standards conformance.

> As another example, RFC 2464 provides explict details as to how IPv6 is
> transmitted over IEEE 802 type (Ethernet) layer 2 networks. It has
> traditionally been that case that such RFCs describe how to implement IP
> over a particular layer 2. These types of RFC are very specific to a
> particular layer 2.

Yes, and those explicit details are visible on the wire and can be
tested for standards conformance.


> Both of these are standards track RFCs.

Yes, because they specify behavior that is visible outside of the box
and that can be tested for conformance.


> I would be interested to hear from you what specific characteristics of
> the proposal for a layer 2 triggers specficiation you find to be any
> different from the existing cases.

He repeatedly stated the primary characteristic.  It is that the
behavior that the standard claims to be standardizing must be visible
outside of the box.  Any characteristic that cannot be deduced by
watching the wire is outside the realm of standards track RFCs.
An RFC that talks about behavior that cannot be tested is merely so
much hot air.

If you care about standards, you should be concerned about "compliance."
If you handed a prototype 3G phone to an independent testing lab, you
could not hope to receive a "Certified" label or a list of defects
for your L2 triggers standard.

No, a vendor's swearing, hoping to die, crossing its heart that it
really has followed the standard is not even hot air.


Vernon Schryver    [email protected]

_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/