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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 2 May 2006 16:24:44 +0100

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

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
in fact
- is it clear that you can only NOTIFY in one direction?
- why are you only allowed to TRACE from the session owner?

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?

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?
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
direction this second RESPONSE is sent in; 3.2.1 says that RESPONSE
messages are only caused by CREATE/REA/NOTIFY.

r.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 May 2006 15:02:26 +0200

Robert and All,

> new session but traces an existing one.]

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

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

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

> is actually inserted - outgoing interface or incoming interface

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

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

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

> 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