Re: [Isms] tsm pre11 - minor issues

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: "'Dave Shield'" <D.T.Shield at liverpool.ac.uk>;
<j.schoenwaelder at jacobs-university.de>
Cc: <isms at ietf.org>
Sent: Saturday, February 07, 2009 1:13 AM
Subject: Re: [Isms] tsm pre11 - minor issues

> > -----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.
>

You might consider adding 'e.g. ' in front of 'Response or Report' to reduce any
implication of inextensibility.

Tom Petch

> >
> > 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