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/