The attribute descriptions in 3.7 (stages 2 and 7 of the example) have been
updated and generalised.

The relevant text in 5.7.3 is updated to:

                                                          Support
   for this protocol in conjunction with TCP is REQUIRED; associations
   using it can carry messages with transfer attributes requesting
   confidentiality or integrity protection.  

and in B.1 for the description of the message transfer attributes argument to
SendMessage:

      Security:  This attribute allows the NSLP to specify what level of
         security protection is requested for the message (such as
         'integrity' or 'confidentiality') ...

From Sam Hartman:

At several points in the document, the text refers to the secure attribute
passed from the NSLP to GIST as if it is a boolean.  Clearly there are a number
of potential security services including integrity, confidentiality,
authenticotion of one or both parties, etc.  While it would be nice to think of
security as a true/false switch this seems misleading.