ietf-nntp new Draft available

[Stan O. Barber]

Andrew Gierth wrote:
> 
> >>>>> "Stan" == Stan Barber <sob at academ.com> writes:
> 
>  Stan> The next draft is available in the usual place:
>  Stan> ftp://ftp.academ.com/pub/nntp/ietf/nntpext.txt.
> 
>  Stan> Enjoy. See you Monday.
> 
> Unfortunately not in my case :-(
> 
> Here are my comments on the draft (in addition to my previous
> comments on the PAT command):

Specifically, what of your previous comments were not addressed in the draft?
Simply saying that the are in addition with out SPECIFICALLY indicating what the
unaddressed issues are is disingenous.

> 
> 11.3 NEWGROUPS and 11.4 NEWNEWS
> 
> The syntax for NEWGROUPS allows (as an addition to current practice)
> the use of "UTC" as an alternative to "GMT"; the syntax for NEWNEWS
> does not. This should be made consistent, preferably by removing UTC
> unless there are real (rather than purely aesthetic) reasons to allow
> it.

I will ask the group at IETF about this and take a lead from them on what to do.

> 
> 9.3.2 IHAVE
> 
> The final example and use of the 435 response is not consistent with
> current practice.


Okey. This was intended to clarify RFC977 and was something not in the reference
version. I will see what others have to say and modify based on consensus.

Did you comment this from the previous draft? I don't recall anyone bringing
this up before now and that draft has been available for four months.


> 14. Security considerations
> 
> Firstly, I suggest that the order should be reversed, with the
> paragraphs on access control etc. coming before the ones on logging
> and proprietary info.

Suggestion noted. I will wait to hear from others on this before making this
change.


> 
> The section on DNS spoofing, while it touches on the issue of
> mismatched forward/reverse lookups, should, IMO, spell out explicitly
> the requirement that reverse DNS lookups should be confirmed by
> performing the forward lookup before the returned name is used for
> either access control or logging or trace information (including trace
> headers added to posted articles).

Hmm. Evidently, those that reviewed the HTTP 1.1 spec didn't see this as an
important enough issues since the text here is based on that spec. Again, I will
look for future comments before making more changes here.

> 
> An additional section to the security considerations should be added
> pointing out the effect that a single insecure site can have on the
> larger NNTP network(s) of which it is part (whether the global Usenet
> or some other network).

Does this affect the performance of the protocol or just the data shipped around
by the protocol? If the latter, I was attempting to address that in the first
part of the this section. If the latter, I'd be very interested in further
exposition on this.