Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall.com!tp From: tp@mccall.com (Terry Poot) Newsgroups: news.admin Subject: Re: automatically mailing warnings about dropped Message-ID: <1991Jun17.105848@mccall.com> Date: 17 Jun 91 15:58:48 GMT References: <284CDCD5.55A7@tct.com> <1991Jun11.182041.4837@iccgcc.decnet.ab.com> <1991Jun12.163939@mccall.com> <1991Jun14.224045.26157@zorch.SF-Bay.ORG> Reply-To: tp@mccall.com (Terry Poot) Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 120 In article <1991Jun14.224045.26157@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > tp@mccall.com (Terry Poot) writes: >> herrickd@iccgcc.decnet.ab.com writes: >>> chip@tct.com (Chip Salzenberg) writes: > >>>> I hereby retract my 10^hopcount proposal in >>>> favor of an error report broadcast using a >>>> systematically changed message ID. I'm not sure >>>> whether that solution is the best one possible, >>>> but it's the best I've read so far, and I am now >>>> persuaded that its cost would be acceptable. > >Too much overhead; you are targeting a message at >_all_ Usenet sites to inform _one_ site. I really >can't see the attraction of that at all. Do you have the same problem with Cancel control messages, which exhibit the same behavior? B news attempted to limit the cancel to only the sites that needed to see it. It didn't work well, so C news and ANU news at the very least always propagate cancels to all feed sites. And in this case, there isn't a real problem, it's just a way for someone to try to get his foot out of his mouth before it gets wedged too tight. The error reports are much more useful to the net as a whole than cancels, and after the initial rash of these when the facility is first introduced, there should be fewer of them than cancels flowing around the net. (And as for the initial rash of errors, there are proposals out there that reduce this problem to a reasonable amount as well.) .... >> Regular messages in a specific group seem much >> more reliable. > >Worse and worse; we are right back to the problem of >the original posting warning that a change was coming; >if you put information where it won't be seen, you >might as well not go to the trouble. > >There are _two_ problems to be solved here: > >1) A technical problem: how to get the information >back to the author or the site admin at the site >where failing messages are being created, without Solved by the error report proposal, if you consider the WHOLE proposal. >breaking anything further (Cnews has already gone >through a phase of reliably recycling old news, and >now one of reliably discarding without notice >articles with what used to be working article >headers; no sense trying for three disasters in a >row), Are you trying to tell us that news is too unreliable a transport to carry notices of its own problems? Do you have a serial line from each of your ethernet controllers tying back into your cpu for error reports? :-) >such as drowning the net in excess messages or I think you over-estimate. Most of the net runs good software, or I doubt even the C news crowd would have seen the changes that sparked all this as a doable thing. >the site of origin in excess email. Only the second >possibility has yet been effectively addressed so >far; all the methods of using news to do the job >send far too many copies to sites that don't care at >all about the information, wasting time, money, and >patience. Each site will store one copy of each report. He might get one from each feed, but he probably won't, any more than he gets any other article from every feed he has. If he does have 2 fully redundant feeds, he probably wants it that way. >2) A human factors problem: how to put the >information returned in a place where it is hard to >ignore, not lost in a mass of similar, but >inapplicable, warnings that condition the intended >recipient out of looking for the warnings at all. Remember a key facet of the proposal is that there will be a small number of sites that pick up all the error reports and mail them to the site with the problem. Thus, you won't have to read the group to find out you have a problem, someone will send you mail telling you. Of course, newer news software could have a feature whereby it scans the error reports looking for errors referring to the current site, so that notification would be swifter, and would occur even if mail couldn't get through, but it will still work quite well for a site not running such software, because he'll get notification by mail. >It's the old "crying wolf" problem. I have yet to >see a proposal here that beats sending a small >number of _pertinent_ notices to the email box of >the author/site admin, a location that a) is >regularly perused by the recipient, and b) waits >"forever" to be read (no expire == loss of >information). Unfortunately, it is all too likely that the small number in question is precisely zero. The various configurations of net connectivity are such that I've yet to see a proposal for a probabilistic method that hasn't been shot down by a counter example of a configuration that would get too many or too few messages. >Nothing posted to a busy newsgroup >satisfies this need at all. Most "inform by news" >proposals would require changes at the site of >origin to pull out only the pertinent notices and >present them to the responsible party, and one of >the givens in this situation is that changes at the >site of origin won't be made until _after_ notice of >a problem is seen, making "inform by news" methods >worthless. Read the whole proposal. The mail out notification was in Neil Rickert's original posting about this method of reporting errors. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!deimos!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA