[NNTP] draft-ietf-nntpext-tls-nntp-02.txt

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-02.txt

> 1.1: suggest you replace the last para with the text that's in NNTPAUTH:

>      The notational conventions used in this document are the same as
>      those in [NNTP] and any term not defined in this document has the
>      same meaning as in that one.

Sounds fine to me.

> 2 para 3: s/MUST NOT be used/MUST NOT be relied on/  (the stuff in 11.6
> only forbids caching security information).

Agreed.

> 2 last para: we don't have the concept of a mode change in NNTP. This
> paragraph merely repeats the meaning of "This command MUST NOT be
> pipelined" in 3.1 and therefore isn't needed.

Agreed.

> 3.2.1 para 2: in option (1), rather than dropping the connection
> immediately it should use the 400 generic response code.

No, because at the successful conclusion of the command, it's the client's
turn, at least as we've currently laid out the specification.  The server
is allowed to simply close the connection, but it's not allowed to send a
response, as I understand it.

> However, it appears from discussions back in March that this situation
> can never happen because it's the server which decides what offer in the
> first place. So all this text can be deleted.

This also sounds correct to me, and deleting text is even better.

> Also back in March, I wrote:

> | However, I'm a little bothered by the asymmetry between TLS failure,
> | where the *server* moves next (issuing a response code), and success,
> | where the *client* moves next (issuing a command). If this isn't cast
> | in stone, then I would strongly suggest making it always the
> | server. This has an additional benefit: you can specify that, after
> | TLS negotiation ends successfully, both sides return to the NNTP
> | initial connection state with the server issuing an initial
> | greeting. I suspect this will make things easier for client design.

> I'm not sure that I ever got an answer.

This sounds like a fundamentally good idea to me.  Ken, any opinions here?

> 3.2.2 first para: will it be clear from the TLS negotiation whether it
> succeeded or failed?

Yes.

> Note that this would be a good place for the 400 I mention above.

I don't see how.  580 doesn't mean that the connection is closing, whereas
400 does, does it not?

> 6 para 7: do you mean "deleting the 382 response" or do you mean
> "replacing the 382 response with a 502 response"? If you just delete the
> response, the client will sleep forever.

Yes, it would need a replacement.  I agree with this change.

The other minor wording changes look good to me.  Does everyone think that
with the above issues resolved, we're ready to go to last call on this
document?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>