• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

RFC531 - Feast or famine? A response to two recent RFCs about network informatio

发布: 2007-6-23 14:09 | 作者:   | 来源:   | 查看: 17次 | 进入软件测试论坛讨论

领测软件测试网

   
  Network Working Group M. A. Padlipsky
Request for Comments #531 MIT-Multics
NIC 17450 June 26, 1973

Feast or famine?
A Response to Two Recent RFC's About Network Information

In RFC514, Will Kantrowitz returns to the theme of his superb RFC459.
There are too many people spending too much time asking for too much
information about Network Hosts. In RFC519, John Pickens returns to
the theme of his rather querulous RFC369. It's not easy to learn how
to use.network Hosts. On the one hand, it would seem that there's a
veritable feast of information going around; on the other hand it would
seem that there's a terrible famine. Can this apparent contradiction be
resolved?

I think it can be, and will attempt to do so after making a few
observations about the respective poles. In regard to the issues
Kantrowitz raises, matters are perhaps even worse for the "big" Servers
than for the experimental ones; we have something like 50 CUBIC feet of
system listings for Multics, plus untold user-supplied programs which
might be of interest, plus several thousand employees (if our "site" is
construed to mean M.I.T. as a whole) -- surely they didn't want all
that, even before the request was withdrawn.

But what of the issues Pickens raises? Surely prospective users ought
to have some means of learning about the resources available. The
point, it seems to me, is that they do ... but they aren't using them.
As Network Technical Liaison for Multics, I've never heard from any of
the U.C.S.B. investigators. I don't even recall their having requested
a Multics Programmers Manual despite the fact that our Resource Notebook
section offers one to any Network site, on request. I do recall seeing
instance after instance of botched login attempts from them in our error
logs, though. I called their Liaison to alert him to the problem but
they weren't in touch with him either.) I also recall saying time after
time, after seeing them floundering around, "it's a pity nobody reads
the Resource Notebook."

That, I think, is the key: we have a Resource Notebook; it lists
Technical Liaisons; it gives information about the Hosts thought to be
relevant to Network users; it gives references to other published
information. _Why_don't_we_use_it_??? Sure, not all the sections are
up to par. Sure, some sorts of information are neither contained nor
pointed to. But that amounts to a need for seasoning -- the meal is
there, and it's neither a glutton's portion nor a starvation diet.
Let's work with what we've got instead of charging around demanding MORE

or sulking around bemoaning the (false) fact that the cupboard is bare.

Placing the right amount of reliance on the Resource Notebook, then,
ought to lead to a solution of the information problem. In its current
form, it would have solved the U.C.S.B. people's problems fairly
completely, for it already tells them to get in touch with me and it
already shows them how to log in. (Assuming, of course, that it wasn't
the unstated object of their game to do it all with only on-line
information.) The Resource Notebook could even have solved the RML
people's problems, for had it been made clear to them that global
requests for Host information are to be handled through the Notebook
they'd have been in touch with people who could have explained why their
requests were inappropriate. And on close decisions, the Resource
Notebook maintainers would know whom to consult with in regard to
appropriateness of results for new categories, I believe.

This is not meant to push the Resource Notebook as a panacea. Clearly
it needs strengthing in terms of content. Even more clearly, it needs
wide dissemination. (The planned Network New Users' Packet will show
how to get at it on-line at the NIC, I'm told. Even better, perhaps we
might want to make it available in microfiche.) Also, this is certainly
not meant to suggest that the Notebook be viewed as supplanting the
individual Hosts' users' manuals, although it does seem to be the
partial repository for documentation to any generic commands we manage
to come up with. But I also think it's important for the NWG to
understand and agree on the proper perspective in which to view the
Resource Notebook -- and I suggest that that perspective should be as
"primary source of Host information." To view it otherwise would, it
seems to me, be wasting both the investment it already represents, and
the opportunity it can represent.

[ This RFCwas put into machine readable form for entry ]
[ into the online RFCarchives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]

文章来源于领测软件测试网 https://www.ltesting.net/


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网