Editorial corrections [Was: Re: [Fwd: I-D ACTION:draft-ietf-sacred-protocol-bss-03.txt]]

Stephen,

Here are a some comments for you, I regard all of these as editorial.

-Missing plate-holder text about the use of key words "MUST",
 "SHOULD", etc.

 Reason: Required text.

-Section 1, first sentence: Replace "PKCS#15 structures" with "PKCS
 #15 [PKCS15] structures".

 Reason: Correct spelling, reference the document itself (it is
 already in the "References" section).

-Section 1, first sentence: Replace "from a workstation" with "from a
 credential server, using a workstation"

 Reason: Clarity.

-Section 1, penultimate paragraph: Replace "OPTIONAL" with
 "optional".

 Reason: No need for key words in an informational "Introduction"
 section (requirements on implementations follow from the protocol section
 anyway).

-Section 2, second paragraph: Replace "which are based on XML" with
 "which are described in XML".

 Reason: The schema is conformant to the XML Recommendation, not based on
 it (I also suggest adding a reference to the W3C XML Recommendation
 here).

-Section 2.1.1, first sentence: Suggest replacing current text with:
 "This operation does not require authentication."

 Reason: Clarity. The current use of the key word "REQUIRE" simply does
 not match its intended use in RFC 2119.

-Section 2.1.2, second paragraph: Replace "SASL mechanism used" with
 "SASL [SASL] mechanism used."

 Reason: Reference the SASL document (already in the "References"
 section), period missing.

-Section 2.1.3, last sentence: Remove.

 Reason: Not needed. Sentence is already in the previous paragraph.

-Section 2.3.3, first paragraph: Suggest replacing all use of
 ds:CryptoBinary with base64Binary, here and in the schema.

 Reason: ds:Cryptobinary apparently strips off leading zeros. It is
 used only twice in the schema, but one of these usages
 <PasswordVerifier> is apparently wrong since a password verifier is
 the output of a digest operation and this may well have leading
 zeros. The introduction of the ds:CryptoBinary type therefore does
 not seem to add much to this memo since it is used only for one type
 which just as well could have been defined using the base64Binary.

-Section 2.3.3, second paragraph: Replace "This extensibility scheme like
 that used..." with "This extensibility scheme is similar to..."

 Reason: Could not understand current text...

-Section 2.3.4: Replace "pkcs#15" with "PKCS #15"

 Reason: Consistency.

-Section 3.1, the example: Replace the "<![CDATA..." text with
 something simpler, e.g. "<sacred:DownloadRequest.../>"

 Reason: We use an XML schema, not a DTD to define the protocol. This
 is the only place where CDATA is used in this memo.

-"References" section: Suggest replacing "[BEEP]" with "[RFC3080]"
 etc. for all RFC references.

 Reason: Consistency. Already a couple of RFCs are referenced this
 way. All or none!

-- Magnus