Re: BEEP adjustments [was: Re: I-D ACTION:draft-ietf-sacred-protocol-bss-01.txt]

All ok for me, except about 2.4 (see below).

Stephen.

Magnus Nystrom wrote:
> 
> (No, _this_ message is _not_ about the substrate issue ;)
> 
> Stephen,
> 
> Thanks for your work in producing this draft.
> 
> In order to clarify the separation between the messages themselves and the
> BEEP profile more clearly, I suggest that the places where BEEP is
> mentioned before the current Section 4 are rewritten slightly.
> 
> Specifically, the changes I would like to see are
> 
> Section 1:
> 
> s/The protocol uses [BEEP]/The protocol is profiled for BEEP [BEEP]/
> 
> Section 2.3:
> 
> (See separate posting regarding SRP, but in case that is not well
> received, at least:
> 
> s/sTLS means that the BEEP session MUST be "tuned" for
> server-authenticated TLS/sTLS means server-authenticated TLS/
> 
> s/cTLS means that the BEEP session MUST be "tuned" for
> mutually-authenticated TLS/cTLS means client-authenticated TLS/
> 
> s/SRP means that the BEEP session MUST be "tuned" for SASL-SRP;/SRP means
> SASL-SRP;/
> 
> and then move the para about "tuned" BEEP sessions to the BEEP profile
> section.
> 
> Section 2.4:
> 
> Drop 2.4 since it does not make things more secure or efficient but adds
> confusion (e.g. is there some operational requirement that requires the
> server to drop the connection after a successful exchange?)

Don't we need to say somewhere whether the session is expected to be
kept open? I don't see any requirement that a sacred server keep the
connection open, and I think its simpler if it just handles a single
transaction per connection/session. Hence the current text. I wouldn't
agree that saying nothing is right though.

> Section 3.1:
> 
> Replace the last two paragraphs with:
> 
>    "Where no specific response message is defined for an operation (e.g.
>    for UploadRequest) then the transport will indicate success or
>    failure.
> 
>    All of the response messages defined here MAY contain a Status
>    string, containing a value intended for human consumption."
> 
> (The BEEP profile already specifies the mapping to BEEP messages)
> 
> BR,
> -- Magnus

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email protected]
Ireland                             http://www.baltimore.com