> then why bothering to write RFC2553? if any ISV can do what he
wants it
> has been only a useless effort.
There is a strong case to be made that the IETF should limit itself to
the definition of protocols, i.e. the bits that flow on the wire, and
should not be concerned with APIs. APIs are typically determined by two
factors, the function that you want to provide and the environment in
which you provide it. The IETF knows a lot about what function to
provide, but it generally does not know all that much about the
environment. Would you still use the socket API in a firmware
implementation? Would it be the same in a massively parallel machine?
What about a quantum computer? API definition in the IETF is always an
exception, not a norm.
In fact, we may observe that RFC 2553 is an informational document, not
a standard track document. It was produced by the WG in a burst of
enthusiasm, but it is a strange beast when in comes to process. How does
one apply the "implementation that interoperate" test? How do we
progress a document and drop features that were not in fact implemented?
How does it apply to hardware implementations of TCP/IP? If there are
not enough compliant implementations, does one obsolete the document and
forget about it?
On the other hand, the subject makes for volume of exchanges on the WG
list, which gives us a comforting sense of liveness...
-- Christian Huitema
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
