Re: [Isms] tsm pre11 - minor issues

["David Harrington" <ietfdbh at comcast.net>]

> -----Original Message-----
> From: dave.shield at googlemail.com 
> [mailto:dave.shield at googlemail.com] On Behalf Of Dave Shield
> Sent: Friday, February 06, 2009 6:03 AM
> To: j.schoenwaelder at jacobs-university.de; David Harrington
> Cc: isms at ietf.org
> Subject: Re: [Isms] tsm pre11 - minor issues
> 
> 2009/1/23 Juergen Schoenwaelder 
> <j.schoenwaelder at jacobs-university.de>:
> > On Thu, Jan 22, 2009 at 03:43:47PM -0500, David Harrington wrote:
> >
> >> I think I have covered all the WGLC comments
> >
> > Can the WG members please review the changes?
> 
> A few minor nits which seem to be still present:
> 
> 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. It is present
in step one at somebody's request to help clarify when a
securityStateReference can occur. But to add the list of message types
to both sides of the condition is unnecessary and limiting. If you
dislike the asymmetry, I can remove the (Response or Report message)
from step 1 to make them more symmetrical.

> 
> 
> Section 4.2, step 2)
>    Add a comma into the list of assignments to 
> tmStateReference cache fields.
> 
>    s/transportDomain tmTransportAddress/transportDomain, 
> tmTransportAddress/
> 
done.

> 
> Section 5.2
>    Step 3) includes a (single) substep numbering "a."
>    The equivalent text in section 4.2 has no such numbering.
> 
>    s/a./  /

done.

> 
> 
> Dave
>