more coments on draft-ietf-sacred-protocol-bss-00

here are my comments, mostly editorial. (obviously, if the group has
consensus for http, we can ignore the beep related comments.)

*** section 1, 2nd paragraph:
>    The security of the protocol is based on [SRP]. The protocol uses
>    [BEEP] as its transport layer and the [SASL] SRP mechanism [SASL-
>    SRP] to encapsulate the SRP exchanges. The payloads consist of a set
>    of XML messages defined here. The protocol sets out to meet the
>    requirements in [REQS].

beep isn't a transport layer, so either:

    s/as its transport layer/for its exchange model/

    s/transport layer/session layer/


*** section 2, sections 2.1.1-2.1.6

it would be a lot easier if there were three paragraphs in each of these six
sessions.

    - the first paragraph says "The purpose of this operation is..."

    - the second paragragh says "The X sends the A ... The Y sends the B
..."

    - the third paragraph says "This operations requires XXX security"


*** section 2.1, editorial remark regarding "tuned"

the term "tuned" is a term of art in beep. typically, sessions are "tuned
for security" (a generic expression) or "tuned for privacy" or "tuned for
authentication" (both more specific expressions).

you can probably replace the editorial remark with an example of a session
being tuned, e.g., one of the examples from section 3 of rfc 3081.
alternatively, if you'd like to show an example of SRP, scroll down to the
end of the message, and i've put in an example:


*** Section 2.2:

>    Where there is a choice (e.g. Remove account), servers MUST support
>    both options and clients MUST support at least one of the options.

s/Remove account/either SRP or cTLS/


*** Section 4.1

the URIs used to start the profile are inconsistent with the one defined at
the beginning of section 4.


*** Section 4.3

>    code  meaning
>    ====  =======
>    777   Extension (ProcessInfo) used not supported
>    778   Required extension (ProcessInfo) not present


appendix e of rfc 821 introduced the "theory of reply codes", which has
modestly evolved since 1981. a reply code is a three-digit number. the first
digit is 1-5 and indicates success/failure,
permanent/transient/intermediate. the third digit is 0-9 and is an
instance-identifier. the second digit is interpreted as:
syntax (0), informational(1), connection(2), security(3),
application-specific(5).

since these two codes reflect a permanent error, the first digit should be
5. since they reflect application-specific requirements, the second digit
should be 5. the third digit can be something that isn't already used.


*** Section 5, IANA Considerations

here are two new open questions:

1. should we apply for a port number?
2. should we define a url scheme?


*** Appendices A & B

it would be nice if this material was consistently indented, capitalized,
etc., to make it easier to read...

/mtr

ps: here is what tuning for authentication and privacy looks like using SASL
SRP:

#######

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 170
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/TLS' />
    L:    <profile uri='http://iana.org/beep/SASL/SRP-SHA-160' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END
    I: MSG 0 1 . 52 184
    I: Content-Type: application/beep+xml
    I:
    I: <start number='1'>
    I:    <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
    I:        <![CDATA[<blob>...</blob>]]>
    I:    </profile>
    I: </start>
    I: END
    L: RPY 0 1 . 170 783
    L: Content-Type: application/beep+xml
    L:
    L: <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
    L:     <![CDATA[<blob>...</blob>]]>
    L: </profile>
    L: END
    I: MSG 1 0 . 0 559
    I: Content-Type: application/beep+xml
    I:
    I: <blob>...</blob>
    I: END
    L: RPY 1 0 . 0 429
    L: Content-Type: application/beep+xml
    L:
    L: <blob>...</blob>
    L: END
    I: MSG 1 1 . 559 82
    I: Content-Type: application/beep+xml
    I:
    I: <blob>...</blob>
    I: END
    L: RPY 1 2 . 429 66
    L: Content-Type: application/beep+xml
    L:
    L: <blob status='complete' />
    L: END

        ... successful transport security negotiation ...

    L: RPY 0 0 . 0 127
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/transient/sacred/bss' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 52
    I: Content-Type: application/beep+xml
    I:
    I: <greeting />
    I: END

#######