Skip to main content

GIST: General Internet Signalling Transport
RFC 5971



(Magnus Westerlund)

No Objection

Lars Eggert
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Russ Housley)
(Sam Hartman)


(Jon Peterson)
(Mark Townsley)
(Ted Hardie)

No Record

(Cullen Jennings)

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

Lars Eggert
(was Discuss) No Objection
David Ward Former IESG member
(was Abstain) Discuss
Discuss [Treat as non-blocking comment] (2008-12-04)
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 Former IESG member
(was Discuss, Yes) Yes
Yes ()

Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2009-04-30)
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

Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2009-06-03)
protocol-layer is not defined anywhere, so ABNF is incomplete.
Bill Fenner Former IESG member
(was No Record, No Objection) No Objection
No Objection (2006-09-27)
No Further Objection.  My concerns are adequately covered by several other DISCUSSes.
Brian Carpenter Former IESG member
No Objection
No Objection (2007-03-16)
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?
Chris Newman Former IESG member
No Objection
No Objection (2007-04-12)
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.
Dan Romascanu Former IESG member
No Objection
No Objection ()

David Kessens Former IESG member
No Objection
No Objection ()

Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection ()

Pasi Eronen Former IESG member
No Objection
No Objection (2008-12-03)
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).
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2009-04-30)
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
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection ()

Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection ()

Tim Polk Former IESG member
(was Abstain) No Objection
No Objection (2008-03-27)
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.
Jon Peterson Former IESG member
Abstain ()

Lisa Dusseault Former IESG member
(was Discuss) Abstain
Abstain (2008-12-10)
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.
Mark Townsley Former IESG member
Abstain ()

Ron Bonica Former IESG member
Abstain (2009-04-09)
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 Former IESG member
(was Discuss) Abstain
Abstain (2009-04-08)
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).
Ted Hardie Former IESG member
(was Discuss) Abstain
Abstain ()

Cullen Jennings Former IESG member
(was Discuss, Abstain, Discuss) No Record
No Record (2009-04-08)