> > An abstract API should never need to get into such a level of detail > > to require a particular implementation. If you're aiming for something > > beyond that, IMO the IETF is the wrong place (e.g., a better place > > would be POSIX).
> To this point, does it make sense to use a common implementation as an > illustration of how an abstract API might be implemented? This is how I read > the ENO API document: not as a specification for a particular API, but as a > description of what such an API must cover, with the Linux/POSIX > configuration interfaces used as an illustration. For what it is worth, for the content of Section 2.2, another applicable term for what you describe would be "information model" (see RFC 3444). This is well-known IETF terminology but perhaps not used in that way e.g. by operating system kernel developers. One challenge with Section 2.2 is that even basic terminology will be very different depending on the context. I just share this so that the WG can make an informed choice. For an informational document this may all not matter, and thus I will stop here with further comments. Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
