Re: [NSIS] comments on the handling of RESPONSE/TRACE/NOTIFY messages

Robert and All,

Am 02.05.2006 um 17:24 schrieb Hancock, Robert:

> hi,
>
> these comments are most inspired by a reading of sections 4.3.3/4/5
> (additional cross references added where appropriate):
>
> i think all of these messages need slightly clearer specification
> about what MRM is used and what direction they can be sent in.
>
> i assume that in reality all of these messages have to be sent
> using the same MRM as the session was created with (by CREATE or
> REA message). otherwise there is no guarantee that the routing
> state to forward them exists. (note that the routing state is
> keyed by MRM, so you cannot leave it unspecified.) [this affects
> at least 4.3.5. I assume here that the TRACE does not create a
> new session but traces an existing one.]

You are right. Especially, TRACE is sent via an existing signaling
session.

>
> also, I don't think the terminology 'upstream/downstream' is useful
> here, since flows may not even exist yet (what do these terms mean
> if you are sending a NOTIFY about a REA?) should the direction
> just be described as 'towards NI' rather than 'upstream'? But

Ok, you are right, especially people that are not completely
NSIS-safe will have hard times in understanding it right.
I see the 'towards NI' as a good candidate; This suits
also the 'DR behind a NAT' case well, where REA must
be used. It would read 'send REA with LE-MRM towards SDA'.

> in fact
> - is it clear that you can only NOTIFY in one direction?

You can only NOTIFY in one direction, as it is defined in
Section 3.8.5  Reporting Asynchronous Events:

    NOTIFY messages are sent hop-by-hop upstream towards NI until they
    reach NI.

> - why are you only allowed to TRACE from the session owner?

For simplicity it has been decided to allow TRACE only from the
session owner.
BUT: This has been decided as a preliminary semantics, since
there have been requests to the WG about the TRACE semantics
in general. The requests have been without larger responses.

Long story short: The semantics of TRACE is quite young and
we have not received anything else than "...this might be useful"
from the WG.

Anyway, I will send a separate email about the semantics of TRACE.

>
> I note (4.2.8) that the TRACE object can only hold one type of
> IP address. How would this function in a mixed v4/6 environment
> using NAT-PT? (is this an error condition?) Also, which IP address
> is actually inserted - outgoing interface or incoming interface
> of the message?

NAT-PT: This was left out intentionally, because NAT-PT seems to
be viewed as a bad idea in the IETF.

The "what IP address is actually inserted" falls under the point I have
raised above: Need input from the WG. (I will send an email, as said
above).

>
> There are some oddities in the processing of RESPONSE messages.
> In 3.2.2 ("Classification of RESPONSE Messages") it says that
> 'Informational' is normally only used with NOTIFY messages. Does
> this mean that a RESPONSE can be sent in response to a NOTIFY?

No, A RESPONSE cannot be sent in a response to a NOTIFY.
This will be clarified!

> The scenario at the end of page 29 implies that a RESPONSE can
> be generated as a result of a RESPONSE, but doesn't say which

Good catch. This will be clarified that responses are only sent
upstream.

> direction this second RESPONSE is sent in; 3.2.1 says that RESPONSE
> messages are only caused by CREATE/REA/NOTIFY.

3.2.1 says RESPONSES are only caused by CREATE/REA/TRACE!

Many thanks for the good review

   Martin

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis