headers
Charles Lindsey | 7 Jan 2000 16:25
Picon
Picon

Boilerplate

The following (or something like it) was originally posted on Dec 31st, but 
seems to have got lost through some problems at Landfield.

Now we are almost through our pass of the present draft, I should like to 
prepare a full draft to post on the IETF sites (just to show the world that we 
are still in business and doing something). So here is the Boilerplate that will 
appear at the two ends of the draft, including the table on contents (no page 
numbers, because I have pagination turned off at the moment).

Things I need comment on:

1. I thought section 8, as currently being discussed, was the end, but I now 
discover two further sections on Propagation and Processing and Security 
Considerations that were in Dan's old draft. I suspect the first of these is 
either not needed, or is best put somewhere else. And as for the Security 
Considerations, I do not think now is the time to fix its final form, but I 
might include a wish-list of topics that people think ought to be covered.

2. See my question in section 12 (Acknowledgements) and tell me what you would 
like to see there long term.

3. There is provision for Appendices on A-News and B-News (to be taken from 
Son-of-1036, presumably). Do we really need to include these? I reckon that any 
hitherto working B-News site will have collapsed in a heap on Jan 1st, on 
account of the way it stored dates in its history file. Likewise appendices on 
Obsolete Headers and Obsolete Control Messages from Son-of-1036.

I have now started on the job of automating the cross-references within the 
draft.
(Continue reading)

Permalink | Reply | 39 comments |
headers
Henry Spencer | 7 Jan 2000 19:09

Re: Boilerplate

On Fri, 7 Jan 2000, Charles Lindsey wrote:
> 1. I thought section 8, as currently being discussed, was the end, but I now 
> discover two further sections on Propagation and Processing and Security 
> Considerations that were in Dan's old draft. I suspect the first of these is 
> either not needed, or is best put somewhere else.

I agree with the suggestion that the remnants of section 9 would make a
good preface for section 8.  Although it is motherhood, it's important
motherhood; in particular, the paragraph containing the word VITAL really
needs to appear somewhere, and I don't recall the issue being discussed
explicitly anywhere else. 

> 2. See my question in section 12 (Acknowledgements) and tell me what you would 
> like to see there long term.

Hmm.  I would say that the right thing to do is to explicitly credit
people who've either written at least a couple of paragraphs of text, or
otherwise had some specific measurable effect on the final result, and
then credit the mailing list as a whole (without attempting to enumerate
its members) for useful discussions. 

> 3. There is provision for Appendices on A-News and B-News (to be taken from 
> Son-of-1036, presumably). Do we really need to include these? ...
> Likewise appendices on 
> Obsolete Headers and Obsolete Control Messages from Son-of-1036.

These, and anything else that we're declaring "obsolete, do not use",
would probably make a good short Informational RFC.  I included them in
son-of-1036 because I thought they ought to be discussed somewhere, if
only for the benefit of archivists, but there is no particular reason to
(Continue reading)

Permalink | Reply | 37 comments |
headers
Charles Lindsey | 10 Jan 2000 10:30
Picon
Picon

Re: Boilerplate

In <Pine.BSI.3.91.1000107125411.29968F-100000 <at> spsystems.net> Henry Spencer
<henry <at> spsystems.net> writes:

>I agree with the suggestion that the remnants of section 9 would make a
>good preface for section 8.  Although it is motherhood, it's important
>motherhood; in particular, the paragraph containing the word VITAL really
>needs to appear somewhere, and I don't recall the issue being discussed
>explicitly anywhere else. 

OK, I shall try and do something like that.

On the subject of Section 8, I am still unhappy with the burdens we are
placing on relaying agents to check for invalid stuff (see my pseudo
comments in 8.2). ISTM that if the injecting agent checks all the headers
for validity (and maybe lets through more than it should) then it is
probably simplest to let relaying agents just pass the stuff around as
fast as they can, and then do final thorough checks when it arrives at a
serving agent to be stored. If every relaying agent on the way MUST check
everything (I don't mind a MAY check) then that is going to be an awful
lot of duplicated work throughout the net. I had inderstood that modern
relay-only agents were fast just because they did little checking.

But nobody has really commented on that except Russ, who seemed to be on
the side of strong checks :-( .

>> 2. See my question in section 12 (Acknowledgements) and tell me what you would 
>> like to see there long term.

>Hmm.  I would say that the right thing to do is to explicitly credit
>people who've either written at least a couple of paragraphs of text, or
(Continue reading)

Permalink | Reply | 36 comments |
headers
Henry Spencer | 11 Jan 2000 03:08

Re: Boilerplate

On Mon, 10 Jan 2000, Charles Lindsey wrote:
> On the subject of Section 8, I am still unhappy with the burdens we are
> placing on relaying agents to check for invalid stuff...  it is
> probably simplest to let relaying agents just pass the stuff around as
> fast as they can, and then do final thorough checks when it arrives at a
> serving agent to be stored.

Our experience with C News was that when we said "we don't need to check
that, it doesn't matter to us", we usually ended up adding the check
later.  Willingness to pass erroneous articles caused trouble, and one
couldn't rely on every point of entry to the network being guarded by
proper checks, so "interior checking" was necessary, although inelegant
and theoretically redundant. 

> >[Appendices] and anything else that we're declaring "obsolete, do not use",
> >would probably make a good short Informational RFC. 
> 
> Seems like a good idea. Are you volunteering?

Not at present -- too much else to do -- although I don't think there is
any great hurry about this.

                                                          Henry Spencer
                                                       henry <at> spsystems.net
Permalink | Reply | 33 comments |
headers
Charles Lindsey | 11 Jan 2000 12:03
Picon
Picon

Re: Boilerplate

In <Pine.BSI.3.91.1000110210118.22690M-100000 <at> spsystems.net> Henry Spencer
<henry <at> spsystems.net> writes:

>Our experience with C News was that when we said "we don't need to check
>that, it doesn't matter to us", we usually ended up adding the check
>later.  Willingness to pass erroneous articles caused trouble, and one
>couldn't rely on every point of entry to the network being guarded by
>proper checks, so "interior checking" was necessary, although inelegant
>and theoretically redundant. 

Yes, but that was before the days of "relay only" agents that do not even
keep an active file. Can someone explain to me more precisely what these
agents do? ISTM that our present wording would outlaw them.

Surely the proper place for thorough checks is the serving agent. There is
an incentive to do it there because, if you don't, it's YOUR news spool
that gets mucked up. Note that we wouldn't forbid checks at relayers - just
not _require_ them.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl <at> clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 32 comments |
headers
Clive D.W. Feather | 11 Jan 2000 13:22

Re: Boilerplate

Charles Lindsey said:
> 9.  Propagation and Processing
> 
> [The following text (taken from Son-of-1036) is in our present draft
> at this point. Do we really want it (it is pure waffle)? In Son-of-
> 1036, it was an introduction to material about relaying etc which is
> now found in our "Duties of various agents" section. Would that be a
> better place for this material?]

Yes. And, yes, we do need it. These messages need to be sent out to the
authors of agents.

>         First, do no harm.
> 
>    It is VITAL to realize that decisions which might be merely
>    suboptimal in a smaller context can become devastating mistakes
>    when amplified by the actions of thousands of hosts within a few
>    hours.

s/hours/minutes/

[Technology constantly improves.]

>    [ISO 8859] International Standard - Information Processing - 8-bit
>         Single-Byte Coded Graphic Character Sets.  Part 1: Latin
>         alphabet No. 1, ISO 8859-1, 1987 Part 2: Latin alphabet No. 2,
>         ISO 8859-2, 1987 Part 3: Latin alphabet No. 3, ISO 8859-3,
>         1988 Part 4: Latin alphabet No. 4, ISO 8859-4, 1988 Part 5:
>         Latin/Cyrillic alphabet, ISO 8859-5, 1988 Part 6: Latin/Arabic
>         alphabet, ISO 8859-6, 1987 Part 7: Latin/Greek alphabet, ISO
(Continue reading)

Permalink | Reply | 0 comments |
headers
David C Lawrence | 11 Jan 2000 16:05

Re: Boilerplate

Charles Lindsey writes:
> Surely the proper place for thorough checks is the serving agent. There is
> an incentive to do it there because, if you don't, it's YOUR news spool
> that gets mucked up. Note that we wouldn't forbid checks at relayers - just
> not _require_ them.

Relay agents that do not check valid newsgroups are a scourge and
should be banned.  Their net effect is that sites are encouraged to
add bogus groups because it appears that they are valid and have
widespread existence, when in truth they might only really exist at a
couple of hosts but are propagated widely because of careless relay
agents.

Checking complete article validity is cheap.  It is not the bottleneck
in article propagation.  It should be done everywhere.
Permalink | Reply | 27 comments |
headers
Dave Barr | 11 Jan 2000 16:53
Favicon

Re: Boilerplate

David C Lawrence wrote:
> Relay agents that do not check valid newsgroups are a scourge and
> should be banned.  Their net effect is that sites are encouraged to
> add bogus groups because it appears that they are valid and have
> widespread existence, when in truth they might only really exist at a
> couple of hosts but are propagated widely because of careless relay
> agents.

Hm..  I hadn't thought of this in these terms before.  I too have
been annoyed at the proliferation of newsgroups that clearly are the
result of typos of valid newsgroups.

However, should a relay trash an article because one newsgroup is
bad or only because all newsgroups are invalid?  Unfortunately,
most of the newsgroups get auto-created out of "traffic" because of
crossposts to typo'd newsgroups.  I see no way to avoid this, except
to try outlaw the practice of auto-creation based on traffic to
crossposted newsgroups.

--Dave
Permalink | Reply | 11 comments |
headers
Russ Allbery | 11 Jan 2000 17:27
Picon
Favicon
Gravatar

Re: Boilerplate

Dave Barr <barr <at> visi.com> writes:

> Hm..  I hadn't thought of this in these terms before.  I too have been
> annoyed at the proliferation of newsgroups that clearly are the result
> of typos of valid newsgroups.

> However, should a relay trash an article because one newsgroup is bad or
> only because all newsgroups are invalid?  Unfortunately, most of the
> newsgroups get auto-created out of "traffic" because of crossposts to
> typo'd newsgroups.  I see no way to avoid this, except to try outlaw the
> practice of auto-creation based on traffic to crossposted newsgroups.

Most people who create newsgroups based on traffic are looking at their
unwanted log or the equivalent.  If it's crossposted to a valid newsgroup,
it won't show up there.

--

-- 
Russ Allbery (rra <at> stanford.edu)         <URL:http://www.eyrie.org/~eagle/>
Permalink | Reply | 0 comments |
headers
Russ Allbery | 11 Jan 2000 17:34
Picon
Favicon
Gravatar

Re: Section_8.02.01

Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:
> Russ Allbery <rra <at> stanford.edu> writes:
>> Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

>>>    A proto-article is one that has been created by a posting agent and
>>>    has not yet been injected into the news system by an injecting
>>>    agent. There SHOULD exist ONLY one copy of a proto-article.

>> What does that last sentence mean?

> It is intended to say that you do not start propagating a proto-article
> to multiple machines until it has been officially injected. I am not
> sure it is necessarily true (since an article may be propagated around a
> local site and only be 'injected' when it passes out through the
> firewall; OTOH, I think that is a case where double injection would be
> appropriate).  Anyway, suggestions for alternative wording welcomed.

    A proto-article is one that has been created by a posting agent and
    has not yet been injected into the news system by an injecting agent.
    Proto-articles SHOULD NOT be propagated to any other system or entity
    other than an injecting agent.

> An injecting agent SHOULD only accept articles from trusted sources.
> However, it MAY allow articles in which headers contain "forged" email
> addresses, that is, addresses which are not valid for the known and
> trusted source, especially if they end in ".invalid".

Sounds fine to me.

>> I'd prefer MUST; I think having relaying agents pass invalid junk along
(Continue reading)

Permalink | Reply | 1 comment |

Gmane