Subject: Re: [Isms] tsm pre11 - minor issues

From: Dave Shield <[email-masked]>
Date: Fri, 6 Feb 2009 11:02:49 +0000

2009/1/23 Juergen Schoenwaelder <[email-masked]>:
> 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)/

Section 4.2, step 2)
   Add a comma into the list of assignments to tmStateReference cache fields.

   s/transportDomain tmTransportAddress/transportDomain, tmTransportAddress/

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

   s/a./  /

Dave

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Feb 2009 19:13:32 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Shield
> Sent: Friday, February 06, 2009 6:03 AM
> To: [email-masked]; David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] tsm pre11 - minor issues
> 

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.

>    s/transportDomain tmTransportAddress/transportDomain, 
done.

>    The equivalent text in section 4.2 has no such numbering.

done.

---

From: Dave Shield <[email-masked]>
Date: Mon, 9 Feb 2009 10:54:21 +0000

2009/2/7 David Harrington <[email-masked]>:
> 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

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

Dave

---

From: "tom.petch" <[email-masked]>
Date: Wed, 11 Feb 2009 16:23:46 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Dave Shield'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, February 07, 2009 1:13 AM
Subject: Re: [Isms] tsm pre11 - minor issues

> 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