GIST: General Internet Signalling Transport

Note: This ballot was opened for revision 20 and is now closed.

(David Ward) (was Abstain) Discuss

Discuss (2008-12-04 for -)
The updated sections from our last conversation are not quite complete. This draft:

arrived in due to our conversation and is not referenced but, this document:

is in Unfort we should not reference such new material in a PS and it has to be removed or the document has to delay until both these drafts move to the IESG. Overall, may need to be removed as it is forward looking and causes much confusion.

Also, of great concern in;

"Within the network, there may be packets using the GIST UDP port but
  which are not in fact GIST traffic." 

and then

"Q-mode packets carry the same
  magic number as other D-mode packets (see Section 5.3.1).  A Q-mode
  packet intercepted within the network which does not match both the
  UDP destination port and the magic number MUST be forwarded
  transparently at the IP layer""

This means that my filter has to inspect beyond the port and look for your magic number. This is akin to deep-packet-inspection for GIST packets. This is pretty much a non-starter.


This specification allocates the following codepoints in existing

      Well-known UDP port XXX as the destination port for Q-mode
      encapsulated GIST messages (Section 5.3).

The DPI mechanism won't work and it should be removed.

Next in on the discussion of IP options, it is unclear what IP options would want to be set on GIST messages and why. Unless specific IP options are to be used and explained why they are necessary, I believe you should remove the section completely as there is no reference in the rest of the doc (I may be incorrect).

Last, a disclaimer should be added to the document that this technology is expected to be deployed in specific limited internet domains (e.g. research, enterprise, wall-garden scenarios).

Magnus Westerlund (was Discuss, Yes) Yes

(Jari Arkko) (was Discuss) No Objection

(Brian Carpenter) No Objection

Comment (2007-03-16 for -)
No email
send info
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?

(Lars Eggert) (was Discuss) No Objection

(Pasi Eronen) No Objection

Comment (2008-12-03 for -)
No email
send info
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).

(Adrian Farrel) (was Discuss) No Objection

Comment (2009-04-30 for -)
No email
send info
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
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

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


(Bill Fenner) (was No Record, No Objection) No Objection

Comment (2006-09-27 for -)
No email
send info
No Further Objection.  My concerns are adequately covered by several other DISCUSSes.

(Sam Hartman) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2009-06-03)
No email
send info
protocol-layer is not defined anywhere, so ABNF is incomplete.

(Chris Newman) No Objection

Comment (2007-04-12 for -)
No email
send info
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.

(Tim Polk) (was Abstain) No Objection

Comment (2008-03-27 for -)
No email
send info
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

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.

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2009-04-30)
No email
send info
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

(Ron Bonica) Abstain

Comment (2009-04-09 for -)
No email
send info
I'm afraid that the following comments aren't very charitable. My apologies in advance.

This document has the following problems:

- it isn't clear on the problem that it sets out to solve
- it isn't clear on the deployment scenario for which it is intended
- it proposes a solution that is very complex
- it is not well presented

The first three problems are associated with one another. While it is clear that NSIS was chartered to improve upon current signaling technology, those improvements weren't well scoped by a real-life deployment scenario. I believe that this lack of scoping lead to the complexity that we see in the solution.

Also, the document is not well presented. If it is truly a solution document, the solution should be described very crisply (probably in fewer that 150 pages.)

(Ross Callon) (was Discuss) Abstain

Comment (2009-04-08)
No email
send info
I am leaving my vote as "abstain" because I still feel that this should 
be "experimental".  I believe that my other discuss comments were addressed in a past update. 

To me this appears to have very substantial implications on routers, hosts, and other devices as well. Thus while there are some implementations, nonetheless for something with this wide an effect, I think that there also needs to be testing in reasonably sized networks before it moves from "experimental" to "proposed standard". I feel that there also needs to be a very substantial justification for why we need this as a standards track protocol (in addition to the existing signaling mechanisms that we have, such as RSVP and RSVP-TE).

(Lisa Dusseault) (was Discuss) Abstain

Comment (2008-12-10)
No email
send info
My position on this document is ABSTAIN because I do not feel it has the quality we expect on the standards track.  I would move to NO-OBJ if it were Experimental.

(Ted Hardie) (was Discuss) Abstain

(Jon Peterson) Abstain

(Mark Townsley) Abstain

(Cullen Jennings) (was Discuss, Abstain, Discuss) No Record