Re: [Isms] tsm pre11 - minor issues

[Dave Shield <D.T.Shield at liverpool.ac.uk>]

2009/2/7 David Harrington <ietfdbh at comcast.net>:
>> Section 4.2
>>    Step 1) explains the presence of a securityStateReference as
>>    being "(Response or Report message)"
>>
>>    Step 2)  simply states that no securityStateReference is present.
>>    It would probably be worth indicating the context here too.
>>
>>    s/no securityStateReference/no securityStateReference
>> (Request message)/
>
> The RFC3411 architecture provides for extensibility, including the
> types of messages. We should not list all the types of messages
> because that would implicitly limit the extensibility.

I wasn't really thinking of "(Request message)" as being prescriptive
of what types of message each of these steps should be applied to.
That's clearly handled by the presence or absence of the
securityStateReference parameter.

    I just though it might be useful to give some context as to when
this was likely to occur - just as had been done in the first case.
If you suspect that this might be misinterpreted as being prescriptive,
then fine - leave it out.

   (Unless you can think of another form of words which might be
less open to misinterpretation - e.g "Request-style message",
or even "e.g. Request-style message")


>                                                                                        If you
> dislike the asymmetry, I can remove the (Response or Report message)
> from step 1 to make them more symmetrical.

No - this is useful clarifying information.  It would be a pity to remove it.

Dave