![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
From owner-ietf at ISI.EDU Wed May 2 07:20:47 1990 Date: Wed, 2 May 90 08:36:57 EDT From: Bob Stewart <stewart at xyplex.com> To: BILLW at mathom.cisco.com Cc: ietf at ISI.EDU In-Reply-To: William "Chops" Westfield's message of Tue 1 May 90 14:49:00-PDT <12586296024.28.BILLW at MATHOM.CISCO.COM> Subject: Host requirements RFCs.. I second Bill Westfield's sigh about checking off the do/don'ts from copies of the requirements pages. I just did it, too. I doubt that most of the people who pick up on that trick will understand what they get back. Many of them will be scared off by the painfully honest who admit that their terminal server doesn't do the things a general host must, or confused and suspicious of attempts to explain. It would be nice if the requirements were clearer about applicibility in special purpose hosts. Like it or not, with all us vendors in the game, the average level of sophistication in the Internet community can only decrease (not from us, from our customers! :-} ). Commercial success brings its own set of problems and responsibilities. I have a concrete proposal. Suppose we publish a new RFC that gives an "interpretation" of RFC-1122&3 appropriate to special-purpose hosts like terminal servers. Are there any other examples? This RFC could effectively soften a few of the requirements for this particular case, and it would give the vendors something to point the procurement agents at. Done honestly and carefully, I think it would have the effect of STRENGTHENing the impact of RFC-1122&3. Bob Braden
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.