ietf-nntp WG Review of draft-dfncis-netnews-admin-sys-05.txt

[ned+ietf-nntp at innosoft.com]

> sorry to bother you again, but it's been more than a month since I last
> heard anything about the RFC process for NAS. Do you think you'll have
> time to proceed with (3) anytime soon?

Thanks for reminding me; I did an AD review a week or so ago but neglected
to send the comments out to the list. Here they are:

The document does not have the necessary full copyright and intellectual
property rights statements. This text needs to be added before the document can
be accepted for publication.

The draft should make it clear from the outset that it currently provides
readonly access to a database of information about netnews and that no
operations to write to the database are provided.

I'm a bit concerned about the use of protocol versions rather than a
capabilities discovery scheme for future protocol extensions. Version numbers
are quite inflexible -- each time additions are made to the protocol a
compliant server has to implement all those additions plus all previous
additions made at lower numbers before it can claim to implement that version.
Additionally, version numbers don't provide any means of returning
per-capability parameters or limits. Given that this protocol is currently
deployed I don't insist on changing schemes, but it may make sense for version
2, should it come to pass, to introduce a capabilities command of some sort and
be the last version number you assign.

The security considerations section needs work.  First of all, at least some
reference should be made to the use of PGP keys throughout the document. It
isn't necessary to explain the use of PGP keys in any detail, but it at least
needs to be mentioned.

The claim that "security issues are only vital for the server-server
communication" is a serious stretch. Again, this protocol provides access to
PGP keys. I'm no expert, but it seems to me that all sorts of mischief would be
possible if a bogus server were to hand out the wrong keys to clients.
Alternately, it could omit or hand out incorrect information about the netnews
hierarchy.  I don't see a facility in this protocol for a client to validate
that it is talking to a legitimate server. Nor does there appear to be a way to
secure the connection to the NAS server. Again, this issue should be discussed
in the security considerations section.

The fact that validation of client IP addresses is currently the only form of
client authentication is probably OK for an experimental protocol, but it needs
to be mentioned in section 6.2 as well as in the security considerations
section.

That's it. I note in passing that given the security issues raised
above an IESG warning note might be attached even if they are described
in the security considerations section.

				Ned