Discussion on the mailing list preferred the option of providing strong
implementation guidance. Text updated accordingly.

In 4.3.2 (case 2 of message forwarding):

                                                Note that if the node
       which finally processes the Query returns an Error message, this
       will be sent directly back to the originating node, bypassing any
       forwarders.  For these diagnostics to be meaningful, any GIST
       node forwarding a Query MUST NOT modify it except in the NSLP
       payload; in particular, it MUST NOT modify any GIST payloads or
       their order.  An implementation MAY choose to achieve this by
       retaining the original message, rather than reconstructing it
       from some parsed internal representation.

In 4.3.4 (final paragraph)...

   In the first two cases, only the common header of the GIST message is
   examined; in the third case, the MRI is also examined.  The rest of
   the message MUST NOT be inspected in any case.  Similar to the case
   of Section 4.3.2, the GIST payloads MUST NOT be modified or re-
   ordered; an implementation MAY choose to achieve this by retaining
   the original message, rather than reconstructing it from some parsed
   internal representation.

Pending discussion on the mailing list.

[Following Routing Area Directorate comments from Adrian Farrel]

The GIST specification allows nodes to forward messages, either after
consultation  with the NSLP (section 4.3.2) or if there is no local NSLP
(4.3.4). However, the forwarding process does not change the IP header or
included Network-Layer-Information object. This means that any errors introduced
by the forwarding node will get reported back to the node that first originated
the message; this will get confused because it is being told about error
conditions which it was not responsible for.

There are several possible approaches for dealing with this:

a) note more strongly in the text that the forwarder is supposed not to change
any of the GIST payloads, so it should not introduce any errors. Disadvantage of
this: we have to trust implementations which do forwarding to be correctly
written so that they do not introduce message changes in the process.

b) allow or force the forwarding node to introduce a new object to indicate that
it has processed the message in some non-trivial way (effectively introducing
route recording). Probably one would still want to report errors to the
originator, but the error reporter would also include the recorded route to make
diagnostics easier. Disadvantage of this approach: it makes the implementation
of forwarding more complex, and in particular rules out implementations which do
simple in-place modifications of the message (the goal for RMD for example).

c) allow the originating node to include an object which records the route taken
through any forwarding nodes. this object would be of extensibility class AB=10
(forward unchanged) or possibly AB=00 (reject if unknown). Typically, the
originating node would only include such an object for diagnostic purposes (to
avoid putting additional processing load on the forwarders).

c') same as (c), but define the object as part of the base specification (so all
nodes would support it from the start).

d) depend on a future GIST traceroute capability (e.g. the NSIS ping approach)
to discover such forwarding nodes and find out what they are doing. So, the
diagnostics would not be built into the base protocol, but would be available as
an extension to support investigations if message mangling by forwarders turns
out to be a problem.

The original discussions with Adrian are included below:
============================================================
>>>> Section 5.6
>>>>> How will we handle an error introduced by a GIST forwarding node?
>>>> Will the error be reported to the forwarding node or to the 
>>>> originator? If the latter, is this:
>>>> - helpful
>>>> - a security weakness
>>>
>>>The error only goes back one GIST hop. It is then up to
>>>GIST to report if necessary to the local NSLP, and up to the NSLP to 
>>>carry out recovery or further reporting back up the chain.
>>
>> So...
>>
>> A---B---C---D---E---F---G
>>
>> A, C, E and G are GIST-capable.
>> Only A, C, and G have the NSLP present.
>>
>> Query goes ABC. C intercepts and processes at NSLP.
>
> Call this Query1.
>
>> Query goes CDE. E intercepts and forwards (no NSLP).
>
> Call this Query2 (it is a different message).
>
>> Query goes EFG. G intercepts and processes at NSLP.
>
> This is still Query2 (E did not change it).

Aha. You mean "E was not supposed to change it" :-)

>> Response is targeted G to C.
>> Response is targeted C to A.
>>
>> Suppose E introduces an error in the forwarded Query.

My point here is that E has clearly received the message into a software 
buffer and has parsed the message. It may have deconstructed it, and may 
rebuild it before transmission. E may have a bug.

>> My question is: where will G send the error message?
>>
>> You have answered clearly: not to A.
> Right.
>
>> But I think the I-D says: to C (since C was the last NSLP node to 
>> touch the message).
>
> Strictly: it's the node which originated Query2 at the GIST level. 
> (But GIST originated it because the NSLP asked it to.)

Right.

>> So C will get an error message (saying, for example, you duplicated 
>> an object).
>>
>> Is this helpful? How do we know who damaged the message?
>
> The forwarding parts of the specification and related parts of the the 
> API (sections 4.3.2/4.3.4) are supposed to pin down that E cannot 
> mangle the message.

Well, that is OK, but what if E *does* mangle the message?
You see, the I-D also pins down that C cannot build an incorrect message, 
but you still (correctly) have an error code to handle the case when it 
does.

> We can check if this
> needs to be made more precise (possibly in 4.3.2). If there comes a 
> time in the future where we wish to allow intermediate nodes to do 
> more significant changes to messages they forward, then I think the 
> right design approach would be to have them modify the NLI as well so 
> that they get to deal with errors they have introduced. (The NAT 
> traversal mechanism of 7.2 already does this.)

In the extreme case, E decodes the message and delivers it to the local NSLP 
which responds saying "count me out". In this case GIST forwards the 
message. But actually, the GIST component has done quite a bit of processing 
and you are making substantial implementation assumptions if you say that 
the component has held on to the message exactly as received and will not 
require to rebuild it. So I think E is very capable of introducing an error.

You might consider adding an object or field that allows a forwarding GIST 
node to record that it has forwarded the message without actually changing 
the important contents of the NLI.