GIST: General Internet Signalling Transport
RFC 5971

Discuss issues scrunched and added to the comment list at the end.

Comment Point 1

The Introduction contains...
   This specification
   concentrates mainly on path-coupled signalling, controlling resources
   on network elements which are located on the path taken by a
   particular data flow, possibly including but not limited to the flow
   endpoints.
This use of "mainly" begs the question: what else does it concentrate on?

----

Comment Point 2

I think the reference to [13] should be moved to Informative to allow
the I-D to go forward without being encumbered. Furthermore, the I-D is
not named correctly in the reference.

----

Comment Point 3

The use of square-bracket numbers in Figures 7, 8, and 9 is unfortunate 
as the references are all indicated in exactly that way. Would it be
possible to use dome other form of bracket in the figures?

----

Comment Point 4

A.5 has


   Length (12 bits):  Length has the units of 32-bit words, and measures
      the length of Value.  If there is no Value, Length=0.  If the
      Length is not consistent with the contents of the object, an
      "Object Value Error" message (Appendix A.4.4.10) with subcode 0
      "Incorrect Length" MUST be returned and the message dropped.

This is ambiguous! The only way to know the length of the contents of
the object (i.e., the Value) is by examining the Length field. I think
you mean, "If the Length is not consistent with the expected length of
the Value field..."

----

Comment Point 5

In 5.1 you have...

   Messages with missing, duplicate or invalid objects
   for the message type MUST be rejected with an "Object Type Error"
   message with the appropriate subcode (Appendix A.4.4.9).

You are making a rod for your own backs!
With this rule, a legacy GIST node will not accept a message with a 
new object on it, even if you are willing to let that node pass the
unknown object on for processing at a further GIST node that does
understand it.

For example, in 5.2.2...
   Currently, each object can occur at most once...
But give the rule above, you will find it hard to change this without
upgrading every box in the network.

But, in A.2.1 you save yourself with...
   The leading two bits of the TLV header are used to signal the desired
   treatment for objects whose Type field is unknown at the receiver.

Could you make these statements all consistent?

Although I note...
   The combination AB=11 is reserved.  If a message is received
   containing an object with AB=11, it MUST be rejected with an "Object
   Type Error" message (Appendix A.4.4.9) with subcode 5 ("Invalid
   Extensibility Flags").
...means that AB=11 can never be used where there is a risk of hitting 
a legacy node.

----

Comment Point 6

The reason for the use of the magick number is poorly explained.
It appears to derive from a fear that other, non-GIST traffic will 
arrive on the GIST well-known UDP port. But what is this fear grounded
upon? The document doesn't explain.

If it is a fear of an attack, then the magick can also be inserted by
the attacker, so it doesn't help. If it is a fear that the well-known UDP
port is somehow already in use for some other traffic, then what traffic
and what is the meaning of the IANA registry?

----

Comment Point 7

According to Section 7.1, the Query refresh is an important mechanism 
to trigger detection of reroute events so as to inform the signaling
client that it should refresh the end-to-end state. Section 4.4.4 
suggests that this refresh should default to 30 seconds and suggests 
a formula to decay this rate in the presence of congestion caused by 
a large number of sessions all needing to issue refreshes.

I could not find any discussion of how fast the client really needs 
to find out about these events, and therefore how rapid the refresh
process really needs to be. Can we guarantee that the decayed rate 
will always be fast enough? If so, why not start at the slower rate 
in all cases? If not, how will the protocol notify the client in time?

It seems to me that the resolution of this Discuss may lie either in
defining a "refresh reduction" technique such as was invented for 
RSVP in RFC 2961, or in requiring the source GIST node to inspect the
RIB (as mentioned, but not made mandatory in Section 7.1).
  
----

Comment Point 8

Section 5 includes definitions of messages in a loose, but nevertheless
formal, language. I see operands =, /, and []. There is also some  
assumption about ordering. The same syntax is used in the definition of
some of the TLVs later in the section, where operands 0* and 1* are also
used.

I would like to see a formal definition (or a reference to a formal
definition) of this language so that the message construciton is
unambiguous.

----

protocol-layer is not defined anywhere, so ABNF is incomplete.

No Further Objection.  My concerns are adequately covered by several other DISCUSSes.

This is too disconsolate to be a DISCUSS and not quite strong enough for an ABSTAIN.

I'm very doubtful about the real deployability of GIST; these extracts
say why:

1.1.  Restrictions on Scope
...
   Flow splitting:   In some cases, e.g. where packet-level load sharing
      has been implemented, the path taken by a single flow in the
      network may not be well defined.  If this is the case, GIST cannot
      route signaling meaningfully. 

2007-03-16: This text has disappeared in version -11, but elsewhere
in the document I find:

   This specification does not define mechanisms for GIST to manage
   multiple parallel routes or an unstable route.

so my concern remains.

...
   Legacy NATs:  GIST messages will generally pass through NATs, but
      unless the NAT is GIST-aware, any addressing data carried in the
      payload will not be handled correctly.

2007-03-16: This text has disappeared in version -11, and  section
7.2.1 has been added. That is good, but it does document that in
some NAT scenarios, GIST will simply fail.

This is no specific comment on the design of GIST - I suspect that
any solution would have the same issues.

Is it certain that flow splitting can't be handled by an extension
to the route change mechanism?

This document is so long and complex that I consider it highly unlikely it will deploy.  As a result I am not concerned it will cause harm to the infrastructure.  Because the WG delivered on its charter item I will vote no objection.  Were this an individual submission, I would probably abstain.

The latest version no longer uses the Router Alert option, so it
probably will not cause harm to the existing infrastructure.  

I do agree with Chris's comment that this is unlikely to be useful or
deployed, but I am voting no objection because this is in the WG
charter (however, if the WG charter was proposed today, I would
probably not support it).

Reviewing this version of the document (19), I share the concern that
been expressed about the general deployability of this mechanism, 
and would be more comfortable with an experimental status or more 
explicit scoping of the expected applicability to areas where 
deployment is better understood

I have  a vaguely uneasy feeling on this document.  Perhaps it is the consequence of trying to
consume RFCs 4080, 4081, and the state machine document as well as gist in rather short
order, but the complexity seems to be substantial.  I am joining the ABSTAINs for now, but
could change that position based on the discussion on today's telechat.  Specifically, I
could change my position if convinced this is both implementable and not dangerous to the
Internet.

If I do change my position, I would move to DISCUSS to address the following issue.

Support for TLS is required, but different modes may be selected (e.g., different
ciphersuites and authentication mechanisms).  These changes significantly impact the
security provided (and as a result, the degree to which the requirements in 4081 are met.)
 The security considerations section should elaborate on the impact of server-only vs.
mutually authenticated TLS, as well as alternative authentication procedures, with respect
to the various requirements.