GIST: General Internet Signalling Transport
RFC 5971

[Ballot comment]
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.

----

[Ballot comment]
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

[Ballot comment]
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.)

[Ballot discuss]
I would be happy to see this specification published as experimental but I do not think it is "a reasonable basis on which to build the salient part of the Internet infrastructure". Some of the reasons why include:

The change to using a port number to detect a GIST packet is, seems to me, a worse choice that RAO. It has most the problems of RAO plus some more. Routers can not process these slow path packets as anything like wire speed so they will need to make sure that the untrusted nodes can't introduce large numbers of these packets. The only way to do this is to filter at the trust boundary (as they do for RAO today). You can say they should only filter if both the port and magic number match but non gist aware equipment will not know how to filter on the special gist magic number and just filter on port. This will result in all traffic on whatever port is chosen for GIST begin blocked into the domain even if the traffic is not GIST traffic. For example, it could be voip packets - the document implies nothing should use the unregistered well known ports but that empirically does not seem to be true. Furthermore, giving ISP a solid reasons they need to block certain ports for network management considerations is exactly the wrong thing to preserver the type of internet the IETF generally desires. This will be a step backward for network transparency even if no one ever deploys a single GIST node.


The advice for the routers seems to be to rate limit the packets GIST packets that are passed to the slow path. This seems like it will cause extremely confusing situations for the applications using GIST. For example, imagine that three GIST aware routers ore on the path, A, B, and C. And B is seeing a lot of GIST packets and just ignoring half of them. Some of the times when a GIST path will look like A,B,C while other times it will be just A,C. It does not seem like there is a way to discover or reliably deal with the non deterministic  behavior of GIST node that is ignoring some but not all GIST packets.


As discussed in section 8.2, the authentication has no idea of who is the correct party to connect to. Given this I don't see how TLS can provide integrity or confidentiality as described in 8.1

[Ballot discuss]
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.

[Ballot comment]
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).

[Ballot discuss]
DISCUSS

This document has moved on a long way since I did the Routing Area
review some years ago. Well done for that.


Discuss Point 1

(This point inherited with some modifications from Dave Ward)

I feel that if this I-D were labeled as Experimental we could have moved
forward long ago. Note that being Experimental is not an indictment of
the protocol spec, but a statement about how important the protocol is
and how disruptive it might be. A new IGP would certainly remain
Experimental until it had been deployed successfully in the wider
Internet and we had a deployment experience report. Conversely, if the
protocol is intended only for deployment in "safe" situations such as
walled gardens, we could move forward with a very clear statement in the
Abstract and Introduction (as well, perhaps, as a dedicated section on
the subject of deployment).

The action to resolve this Discuss point is therefore one of three
things:
- make the document Experimental
- include the deployment discussions                   
- explain to me why neither of the above is necessary.

It should be noted that resolving this point with either of the first
two suggestions will close down my other Discusses.

----

Discuss Point 2

(This is a new point and so, because of the stage of the process, I
will be willing to give way on it far more easily.)

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

Discuss Point 3

(This point inherited with some modifications from Dave Ward)

I am not comfortable with the mechanism for detecting GIST packets at
a GIST node. If I understand correctly, each IP packet for any
destination must be examined as follows:
- emaine IP payload
  - if payload is UDP examine UDP port number
    - if UDP port number is reserverd for GIST
      - apply a rate limit
      - check the first word of UDP payload is magick
The first two checks must be made for all UDP traffic and the second
check constitutes a form of deep inspection.

Can this be done at line speed by a GIST-capable node? I am concerned
that a GIST-capable node might become stressed by a large amount of
non-GIST transit UDP traffic. This traffic might even be the flow that
GIST is being used to support.

Are you proposing that this check should be done in hardware on the
GST-capable nodes? If not, how can you be sure that the slow path will
be able to handle the pass-through data fast enough?

----

Discuss Point 4

(This is a new point and so, because of the stage of the process, I
will be willing to give way on it far more easily.)

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.

----

[Ballot comment]
----

COMMENT

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

----

[Ballot discuss]
I found ABNF for Stack-Proposal to be incorrect (or at least confusing).
Section 5.2.2 says:

  Stack-Proposal:  This field contains information about which
      combinations of transport and security protocols are available for
      use in messaging associations, and is also discussed further in
      Section 5.7.

      Stack-Proposal = 1*stack-profile

      stack-profile = 1*protocol-layer

This is ambiguous: how does one can find out where one
ends and another begins (there are no delimiters between s,
no field specifying how many of them, or any other type of framing)?

One way to fix this part of my DISCUSS is to define ABNF to match Appendix
A.3.4. Alternatively you need to at least add ABNF comments explaining that
some fields are omitted (e.g. number of s) with pointers
to sections where they are defined.


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



Then Section 5.7.1 says:

  A Stack-Proposal object is simply a list of profiles; each profile is
  a sequence of MA-Protocol-IDs.  A profile lists the protocols in 'top
  to bottom' order (e.g.  TLS over TCP).

It is still not clear how it is possible to find out where a profile ends.


Then Appendix A.3.4 says:

  Type:  Stack-Proposal

  Length:  Variable (depends on number of profiles and size of each
      profile)


    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Prof-Count  |    Reserved                                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                    Profile 1                                //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  :                                                              :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                    Profile N                                //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Prof-Count (8 bits): The number of profiles listed. MUST be > 0.

  Each profile is itself a sequence of protocol layers, and the profile
  is formatted as a list as follows:

  o  The first byte is a count of the number of layers in the profile.
      MUST be > 0.

  o  This is followed by a sequence of 1-byte MA-Protocol-IDs as
      described in Section 5.7.


So my understanding is that a Stack-Proposal is stored as a TLV object.
What about each Profile? Are they stored as TLV objects as well?



In multiple places: you need to clarify how port numbers are encoded
on the wire (I assume they all in "network byte order").

[Note]: 'Please check your comment field so that it doesn''t contain old text! RE-evaluate your ABSTAIN positions. All that stays in ABSTAIN please indicate in the comment field that you have performed this re-evaluation. Pleas also include some motivation behind your decision.' added by Magnus Westerlund

[Note]: 'Please check your comment field so that it doesn''t contain old text!

RE-evaluate your ABSTAIN positions. All that stays in ABSTAIN please indicate in the comment field that you have performed this re-evaluation. Pleas also include some motivation behind your decision.' added by Magnus Westerlund

[Ballot comment]
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.

[Ballot discuss]
The updated sections from our last conversation are not quite complete. This draft:
http://www.ietf.org/internet-drafts/draft-hancock-nsis-gist-rao-00.txt

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

http://tools.ietf.org/html/draft-nsis-ext-00

is in 5.3.2.5. 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, 5.3.2.5 may need to be removed as it is forward looking and causes much confusion.

Also, of great concern in 5.3.2.3;

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

Later:

This specification allocates the following codepoints in existing
  registries:

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

[Note]: 'RE-evaluate your ABSTAIN positions. All that stays in ABSTAIN please indicate in the comment field that you have performed this re-evaluation and also include some motivation behind your decision.' added by Magnus Westerlund

[Ballot comment]
Let's discuss this in the call. I seem to remember an agreement with the authors the last time they attended an informal call, but I am not sure that the terms of that agreement have been met in v17.

[Ballot comment]
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).

[Note]: 'RE-evaluate your ABSTAIN positions. All that stays in ABSTAIN please indicate in the comment field that you have performed this re-evaluation and also include some motivation behind your decision.
' added by Magnus Westerlund

[Ballot comment]
Both the routing AD have abstained on this because they do not believe it is appropriate for internet routing. I have heard their arguments, believe they are sounds, and support their position.

[Ballot comment]
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.

[Ballot comment]
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 if convinced this is implementable.

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.

[Ballot comment]
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.

[Ballot discuss]
Holding Discuss for IANA until the authors clarify:
Action 7:

Upon approval of this document, the IANA will create the following
registry "Error Codes/Subcodes" located at http://www.iana.org/assignments/TBD
Assignment Procedures: FCFS
Initial contents of this registry will be:

Error code Error subcode Error class Error case/name Reference
---------- ------------- ----------- --------------- ---------

[ Can you please help IANA by converting the contents of Appendix
A.4.4 to the appropriate contents for this registry? It's unclear
exactly what format you need/want for this registry. ]

IANA Last Call comments:

IANA has questions.

We couldn't parse the list of Error Codes/Subcodes from the
Appendix. Could you please provide the initial contents in a table
format suitable for entry into the IANA Registry?

Also, it would be helpful if you had a table for Appendix A.4.2 for
AI-Types as well.

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "PORT NUMBERS" registry located at
http://www.iana.org/assignments/port-numbers
sub-registry "WELL KNOWN PORT NUMBERS"

Keyword Decimal Description References
------- ------- ----------- ----------
gist [tbd]/udp Q-mode encapsulation for GIST messages [RFC-nsis-ntlp-15]


Action 2:

Upon approval of this document, the IANA will create the following
registry "NSLP Identifiers" located at http://www.iana.org/assignments/TBD
Assignment Procedures: Specification Required
Initial contents of this registry will be:

NSLPID Application Reference
------- --------------------------------------------- -----------
0 Used for GIST messages not related to any signalling [RFC-nsis-ntlp-15]
application.
1-32703 IESG Approval [RFC-nsis-ntlp-15]
32704-32767 Private/Experimental Use [RFC-nsis-ntlp-15]
32768-65536 Reserved - not to be allocated [RFC-nsis-ntlp-15]


Action 3:

Upon approval of this document, the IANA will create the following
registry "GIST Message Types" located at http://www.iana.org/assignments/TBD
Assignment Procedures: Standards Action or Expert Review
Initial contents of this registry will be:

MType Message Reference
-------- --------- ---------
0 Query [RFC-nsis-ntlp-15]
1 Response [RFC-nsis-ntlp-15]
2 Confirm [RFC-nsis-ntlp-15]
3 Data [RFC-nsis-ntlp-15]
4 Error [RFC-nsis-ntlp-15]
5 MA-Hello [RFC-nsis-ntlp-15]
6-63 Standards Action [RFC-nsis-ntlp-15]
64-119 Expert Review [RFC-nsis-ntlp-15]
120-127 Private/Experimental Use [RFC-nsis-ntlp-15]
128-255 Reserved - not to be allocated [RFC-nsis-ntlp-15]


Action 4:

Upon approval of this document, the IANA will create the following
registry "Object Types" located at http://www.iana.org/assignments/TBD
Assignment Procedures: Standards Action or Specification Required
Initial contents of this registry will be:

OType Object Type Reference
-------------------------------------- -------------
0 Message Routing Information [RFC-nsis-ntlp-15]
1 Session ID [RFC-nsis-ntlp-15]
2 Network Layer Information [RFC-nsis-ntlp-15]
3 Stack Proposal [RFC-nsis-ntlp-15]
4 Stack Configuration Data [RFC-nsis-ntlp-15]
5 Query Cookie [RFC-nsis-ntlp-15]
6 Responder Cookie [RFC-nsis-ntlp-15]
7 NAT Traversal [RFC-nsis-ntlp-15]
8 NSLP Data [RFC-nsis-ntlp-15]
9 Error [RFC-nsis-ntlp-15]
10 Hello ID [RFC-nsis-ntlp-15]
10-1023 Standards Action [RFC-nsis-ntlp-15]
1024-1999 Specification Required [RFC-nsis-ntlp-15]
2000-2047 Private/Experimental Use [RFC-nsis-ntlp-15]
2048-4095 Reserved - not to be allocated [RFC-nsis-ntlp-15]


Action 5:

Upon approval of this document, the IANA will create the following
registry "Message Routing Methods" located at http://www.iana.org/assignments/TBD
Assignment Procedures: Standards Action or Expert Review
Initial contents of this registry will be:

MRM-ID Message Routing Method Reference
---------- ----------------------- -----------
0 Path Coupled MRM [RFC-nsis-ntlp-15]
1 Loose End MRM [RFC-nsis-ntlp-15]
2-63 Standards Action [RFC-nsis-ntlp-15]
64-119 Expert Review [RFC-nsis-ntlp-15]
120-127 Private/Experimental Use [RFC-nsis-ntlp-15]
128-255 Reserved - not to be allocated [RFC-nsis-ntlp-15]


Action 6:

Upon approval of this document, the IANA will create the following
registry "MA Protocol IDs" located at http://www.iana.org/assignments/TBD
Assignment Procedures: Standards Action or Expert Review
Initial contents of this registry will be:

MA-Protocol-ID Protocol Reference
------------------- ---------------------------------------- ---------
0 Reserved - not to be allocated [RFC-nsis-ntlp-15]
1 TCP opened in the forwards direction [RFC-nsis-ntlp-15]
2 TLS initiated in the forwards direction [RFC-nsis-ntlp-15]
3-63 Standards Action [RFC-nsis-ntlp-15]
64-119 Expert Review [RFC-nsis-ntlp-15]
120-127 Private/Experimental Use [RFC-nsis-ntlp-15]
128-255 Reserved - not to be allocated [RFC-nsis-ntlp-15]


Action 7:

Upon approval of this document, the IANA will create the following
registry "Error Codes/Subcodes" located at http://www.iana.org/assignments/TBD
Assignment Procedures: FCFS
Initial contents of this registry will be:

Error code Error subcode Error class Error case/name Reference
---------- ------------- ----------- --------------- ---------

[ Can you please help IANA by converting the contents of Appendix
A.4.4 to the appropriate contents for this registry? It's unclear
exactly what format you need/want for this registry. ]


Action 8:

Upon approval of this document, the IANA will create the following
registry "Additional Information Types" located at
http://www.iana.org/assignments/TBD
Assignment Procedures: FCFS
Initial contents of this registry will be:

AI-Type Type Name Reference
------- ------------------- ------------
1 Message Length Info [RFC-nsis-ntlp-15]
2 MTU Info [RFC-nsis-ntlp-15]
3 Object Type Info [RFC-nsis-ntlp-15]
4 Object Value Info [RFC-nsis-ntlp-15]
5-65535 Available for Assignment [RFC-nsis-ntlp-15]


We understand the above to be the only IANA Actions for this
document.

The "GIST:  General Internet Signaling Transport" has been reviewed by
the IESG, and there were several discusses issued against the draft. We
feel that all open issues from the IESG have been resolved.

There was a working group last call that ended on June 25th.
Additionally, there was a GIST Interop event, that raised a few more
issues, that have all been resolved in the Working Group and were part
of the WGLC. The interop report:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07954.html

The I-D is now ready for AD and IESG review. Below are details about the
I-D:

Title:  GIST:  General Internet Signaling Transport
I-D: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-14.txt

Status: Proposed Standard

Response to template:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes. The ID has passed working group last calls, has had good reviews
during the process, including an early reviews by Bob Braden and Brian
Carpenter prior to acceptance as a working group document.  It has been
reviewed by the IESG, and we feel that all DISCUSSes from the IESG have
been cleared.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, etc.)?

No concerns.  The document has undergone extensive Working Group review,
and has several (at least 6) interoperable implementations.

 
4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No
 
5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

There is a strong consensus in the WG supporting this work, at this
point there is no disenting voices about the protocol in the WG.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) Does the document a) split references into normative/informative,
  and b) are there normative references to IDs, where the IDs are not
  also ready for advancement or are otherwise in an unclear state?
  (Note: the RFC editor will not publish an RFC with normative
  references to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

The document does split references into normative and informative ones.

9) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

This draft proposes a general signaling transport protocol.  It is based
on the use of existing transport and security protocols under a common
messaging layer. GIST does not handle signaling application state
itself; in that crucial respect, it differs from application signaling
protocols such as SIP, RTSP, and the control component of FTP, but this
follows the basic NSIS 2-layer signaling model defined in RFC 4080.

  - Working Group Summary

There have been several WGLC on the document, plus several pre-WGLCs on
the document.
The editors have gotten extensive feedback from implementors and have
clarified text based upon the feedback.  There are 6 or more independent
implementations of GIST, and there was an interop event prior to the
Paris IETF meeting.

  - Protocol Quality

This document was reviewed by the working group chair as well as the WG.
We feel that this document is ready, and implementors feel that the
specification is implementatble.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
I changed my vote to "abstain" because I still feel that this should
be "experimental", but other ADs don't agree and this is not an issue
open to compromise (it can't be 1/2 experimental and 1/2 standards
track). I believe that my other discuss comments were addressed in the
recent 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". Thus my inclination would be to prefer "experimental" status at first.

That said, I don't really like to put a "defer" on a document since this slows down an already excessively slow process, but I nonetheless feel that I need a couple of weeks to review this properly. My apologies.

[Ballot comment]
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?

[Ballot discuss]
First, thanks for a well written protocol writeup.  While I'm bringing
up serious concerns, I think that we'll be able to address them and
move forward relatively quickly.


The example in 3.7 should make it clear that when a GIST peer
intercepts a message, the forwarding of the query towards the flow
destination (should it happen) is an NSLP responsibility not an NTLP
responsibility.


GIST raises significant architectural concerns about the end-to-end
service model of the Internet.  In particular there are multiple cases
having to do with q-mode encapsulation where GIST nodes consume,
generate and modify packets that are neither sourced nor destined for
them.  The advice in section 7.2 goes against the requirements of
section 7 of draft-ietf-behave-nat-udp (an approved BCP).  Even so, I
think it is necessary for GIST to do these things but I think we need
to be very careful about the interactions with other things deployed
on the Internet.  We also want to discourage general applications of
this form and I think it critical that we establish architectural
requirements so that future proposals work with GIST.  I don't think
it necessary to block GIST on that architectural work.  RFC 4080
discusses some but not all of these issues; as best I can tell it does
not discuss AH, interactions with other IP options and
hop-by-hop/destination options, etc.  Also, RFC 4080 is not an IETF
consensus document; it was a working group document that was never
submitted for IETF last call.  This is not just an NSIS issue; it is
an IP service model issue.

I propose that:

1) A section of the GIST document be added clearly indicating when a
GIST implementation can modify a packet not targeted for itself and
when it is expected to intercept such packets.  That is currently
scattered too much throughout the document.  Specific care should be
given to cases where a GIST node will not forward traffic for which it
would normally act as a router.  In particular, I think it would be
harmful if traffic that happened to be on the GIST UDP port were
discarded if it clearly had no relation to GIST.


2) Discuss interactions with AH and other mechanisms that might be
added (especially by intermediate routers) that could cause problems
when packets are modified.


3) Explicitly call out this document's divergence from draft-ietf-behave-nat-udp.

4) Send a more general architectural question to the community and IAB.


Would it be possible to add a MAC (message integrity code) based on a
negotiated secret to D-mode packets using an extensibility mechanism?
If so, how would this be done?  I don't think we need require this
now, but I do think we need to make sure that if modification of
D-mode packets becomes a problem we have a solution we can specify.  I
am very uncomfortable with the "just use c-mode and an MA" response.
I can see cases where MA setup may be expensive, cases where a client
wants to only integrity protect some fields, etc.  In general, I want
to confirm the extensibility mechanisms are good enough to handle
this.


At several points in the document, the text refers to the secure
attribute passed from the NSLP to GIST as if it is a boolean.  Clearly
there are a number of potential security services including integrity,
confidentiality, authenticotion of one or both parties, etc.  While it
would be nice to think of security as a true/false switch this seems
misleading.



The discussion of TLS needs to describe what names certificates need
to use.

Section 8.3 claims that authenticated peers can be trusted not to
claim they are on-path when they are off-path.  Authentication is not
the same as authorization.  The discussion of when this assumption is
reasonable needs to be significantly expanded.


There does not seem to be a discussion of extensibility in the main
body of the document.


The advice at the end of section 3.5 indicates that there is a DOS
attack if SIDs are not cryptographically random, but only requires at
a SHOULD level that they be cryptographically random.  Why is this not
a MUST?  Also, given the security properties of SIDs, is it really
appropriate for each NSLP to choose the SID itself?  In particular,
without making assumptions about lack of structure in a SID, how can
you analyze the structure of GIST?  Could an NSLP embed IP addresses
or other structured data in a SID?  If so, wouldn't that have an
adverse security impact?

I don't understand the attack regarding off-path nodes inserting
routing state discussed briefly at the end of sections 3.5 and 8.3.
Is the attack that you could send a bogus query from off-path and get
the upstream directed traffic associated with a session?  Shouldn't
authorisation be part of a defense against this attack in addition to
SID randomness?

[Ballot discuss]
These are questions I have for other IESG members more than anything else and expect some of them may be in other people discusses.

If skype updated 200 million softphones to all start started sending the router alter options on every call, would this cause any problems to load on routers in existing networks?

This all assumes that the routing is very stable and does not change from one packet to the next. The essence of some of the anycast debate has questions if this is a good assumption about the state of the internet in the future.

I don't understand how the system protects from just inserting a man in the middle in the TLS connections. To be specific, when a TLS connection is formed from A to B, I don't understand what A and B check to verify that they are not talking to a man in the middle.

I have asked if any router or firewalls plan to implement this - I'm don't think I have received an answer. Any ideas? This does not directly effect something that we should change in the protocol but it is relevant in thinking about the review and if this is implementable.

NIT: There should have a normative reference to RFC 2113. I think [26] and [27] need to be normative.

[Ballot discuss]
I think that this draft should be "experimental" rather than "proposed standard". If this draft is deployed in a significant way, then it would have an enormous and "core" effect on the Internet. Thus there needs, in my opinion, to be operational experience on a significant scale before this becomes a proposed standard. Perhaps just as seriously, if this is NOT deployed in any significant scale, then making it a standard could confuse people wrt its relationship with other signaling protocols.


Also, here are detailed Routing Directorate comments from Adrian Farrell which need to be considered:


Hi Ross,

Here is my review of draft-ietf-nsis-ntlp-11.txt.

Although I have some doubts about the motivation for the
work, I have tried to concentrate on technical issues with
the protocol and the documentation. The concerns are
broken into technical and editorial in the lists below.

Please feel free to share these thoughts with the IESG or
the authors.

No doubt many of these issues have been discussed by the
nsis working group and satisfactory conclusions have
already been reached. I don't think there is a need to
enter into a debate on the points if that is the case,
but I would be happy to clarify any of my comments on
request.

Cheers,
Adrian

=========
Technical issues

----
Non-path-coupled signaling - Section 1 para 2
"concentrates mainly on path-coupled signaling". You raised
my hopes :-) But I think the document concentrates entirely
on path-coupled signaling.
We could note that there are only a few places where this
is actually enforced. For example, the Query, Response and
Confirm could easily be allowed to use an existing MA
(possibly set up on demand by a D-mode Query) and so out-
of-band signaling would be supported.
----
Section 1.1 - Multicast flows
You say:
  Multicast:  GIST does not handle multicast flows.
    This includes classical IP multicast and any of the
    small group multicast schemes recently proposed.
I think you might say that this is for future investigation
rather than say it is not supported. You may find that GIST
is perfectly capable of supporting multicast and is rather
a useful tool where all replication points are
GIST-capable.
----
Section 2 - Definitions
The definitions of routing and transport don't appear until
section 3.1. Given that these terms have subtle context-
specific meanings in nsis, and that readers familiar with
the current nature of the Internet may become confused, you
might consider moving these into section 2.


It would be helpful to define "routing state" in the
context of GIST.


The definition of "[data] flow" seems to be lacking. "A set
of packets" is pretty vague.
----
Section 3.1 - Routing
Does routing as described in this document determine how to
reach the adjacent GIST peer along the data path?
Surely either:
- routing (conventional IP routing) determines how packets
are forwarded along the data path
or
- GIST routing as described in this document determines
which is the adjacent GIST peer by probing nodes along
the data path.
----
Section 3.2 - Connection mode
The motivation "fast state setup in the face of packet
loss" is suspect. What makes you think that you will be
able to set up and maintain a MA more rapidly in the
face of message loss than you would be able to squeeze
through a single UDP message?
----
Section 3.2 - D-mode encapsulation
You say that UDP is the only encapsulation which does not
require per-message shared state to be maintained between
peers. Raw IP seems to do this job as well. So your point
is that UDP is the only encapsulation with other properties
that you desire that...
----
Router Alert interception
I am concerned about this process as specified.
Perhaps my memory of IP is a little rusty?
And perhaps I am telling you how to suck eggs, but the
current text on this is very scattered and unclear.


RFC 2711 defines the Router Alert option for IPv6.
The option carries a two byte field that indicates that the
datagram includes a message of a particular protocol. The
IANA maintains a registry of values for this field, and
new NSLPs could certainly be added to this registry.
The RFC states that:
  The router's interest and the actions taken by employing
  Router Alert MUST be specified in the RFC of the
  protocol that mandates or allows the use of Router Alert
That means that each NSLP specification must describe the
processing - i.e. it is out of scope for GIST unless (and
this might be sensible) a single new value is defined to
indicate that the datagram carries a GIST message.
Obviously, if you do this you will need to make a new
request in section 9.


However, note well that a datagram that is intercepted
because of the Router Alert option will be delivered to the
component for processing the payload protocol - in this
case UDP, and UDP will deliver the GIST message to the
destination port on the local host. So you need to be
really careful in IPv6: if you register with your local
IPv6 stack that you want to receive intercepted Router
Alert-flagged datagrams, you need to make sure that the
GIST port is enabled or the UDP stack will drop/reject
packets.


IPv4 is slightly less friendly than IPv6. Although the
Router Alert option defined in RFC 2113 also has a two byte
field, only one value (zero) is defined and there is no
IANA registry of other values. In IPv4, an IP stack decides
to intercept a Router Alert-flagged datagram "shall examine
packets carrying it more closely (check the IP Protocol
field, for example) to determine whether or not further
processing is necessary." I think that you would be well-
advised to define the precise examination that you are
requiring in the case of GIST. Are you asking that all
flagged packets are delivered to UDP (as marked by their
IP Protocol field) even though it may be that many cannot
be delivered - perhaps they are not even GIST messages. Or
are you asking that the IP stack checks such flagged
datagrams for:
- IP protocol = UDP
- destination port = GIST default port


Bottom line:
- You must recall that there will be other users of
Router Alert active in the network at the same time as
GIST
- You must take care that if a datagram is intercepted
and delivered to UDP, UDP will know what to do with it.
UDP is not a forwarding protocol.
- You must define the correct processing for any IPv6
Router Alert options in the "owning specification" or
define a new codepoint for GIST.
----
Section 3.4
I think it would be worth discussing somewhere how the
upstream node knows when state has been successfully
installed at the downstream node if the downstream node
requested the use of Confirm.
In fact the answer is that it doesn't. It just goes ahead
and tries a message and if it doesn't get an error back
everything must be OK.
This is probably within the spirit of not optimising for
error conditions, but you might want to make it a bit
clearer.
----
Section 3.5 SIDs
The statement about whether NSIS implementations could
provide common functionality to generate SIDs is clearly
out of scope. I suggest removing it.
You need to add a couple of clear statements in this
section:
- Is the SID maintained end-to-end or does each NSLP
that handles the message insert its own SID?
- What is the scope of uniqueness of the SID? Is it per
node, or is it per NSLP ID?
----
Section 4
Is this section normative? It includes some 2119 language
(e.g., 4.3.4) and some text that appears to be definitive
(e.g. the bullets in 4.3.2). However, the GIS service
interface (section 4.1) is clearly not normative.
It would be helpful if the text made clear what is and is
not normative. In particular, some text in 4.1 like:
This abstract service interface definition in no way
constrains implementations, is non-normative, and is
only provided as in formation to help understand how
GIST might be used.
----
Section 4.1.2 Security
This section should discuss where the keys come from and
how they are distributed (or ref 8.2).
----
Section 4.2.1 para 1
Says: "The primary key" without reference to any other
keys.
----
Section 4.2.1
"All of this information is learned from prior GIST
exchanges". Well, once I had read the rest of the document,
I understood this!
Can you clarify that there are specific GIST exchanges that
are used to set up Message Routing State and that those
exchanges distribute this information.
----
Section 4.3.1 D-mode Normal encapsulation
"Each datagram contains a single message"
Didn't I see something about bundling somewhere?
----
Section 4.3.1 Q-mode
"usually with an IP router alert option"
How so "usually"?
----
Section 4.3.2 para 2
You say that the interaction is with signaling application
policy, but I think that the interaction is with the
signaling application, itself. The application is
responsible for applying policy. That is, GIST does not
interact with a policy component at this stage.
----
Section 4.3.2 para 2
(Perhaps a nit)
You say that GIST MUST propagate the Query. But consider
that the local node may be the destination of the Query.
----
Section 4.3.2 bullets
Given how these look to be normative, it might be best to
put bullet 3 before bullet 2. Otherwise there is a small
security hole because bullet 2 can be used to discover that
a given MRI/SID/NSLP-ID combination exists on a target node
----
Section 4.3.3 bullet 2
Worth saying why.
"...to preserve fragment ordering"
----
Section 4.3.4 - GIST Hop Count
A.4.4.2 shows clearly that an error is generated by a GIST
node if it decrements the hop count to zero on receipt. But
the definition in A.1 says:
  GIST hops (8 bits):  A hop count for the number of
  GIST-aware nodes this message can still pass through.
This is inconsistent. A message sent with a hop count of 1
will have the count decremented to zero on receipt
resulting in an error. So the value 1 did not represent the
number of nodes that the message could pass through.
In fact, there is no point in sending a message with hop
count 1.


In 4.3.4 you have
  2.  The GIST hop count has reached zero.  The error
      "Hop Limit Exceeded" (Appendix A.4.4.2) SHOULD be
      returned to the sender, which MAY retry with a
      larger initial hop count if it is clear that a
      loop has not been formed.
It is not explained how a receiver of a "Hop Limit
Exceeded" error can tell whether a loop has not been
formed. And it is not explained how the initiator of
such an error message could know, either.


Additionally, the statement (in several places, e.g.,
4.3.2) that the GIST hop count prevents looping is not
completely accurate. It prevents indefinite looping, but
it does not prevent looping per se.
----
Section 4.3.4 point 3
Is there a valid race where this can happen? For example,
when a signaling application crashes.
Suggest you add "during normal processing", or "this is an
error condition", or remove "...this should never happen"
as you go on to describe how to handle it anyway.
----
Section 4.4
This section appears to say that an MA cannot exist without
some Routing State. Is this the case, and if so why?
Surely it would be helpful to prevent MA flap to allow an
implementation to retain an MA without Routing State in
case a subsequent usage became apparent.
Confusingly, section 4.4.2 describes MA "Re-use", but this
is meant to describe "multi-use" because the MA is assumed
to already be in use. Perhaps you could change the title
and text in 4.4.2?
Note that a receiver that does not install routing state
until it receives a Confirm, may have an MA set up with no
associated routing state. And such an MA could be assigned
for use for other routing state.
----
Section 4.4.1 page 29
"about the node itself"
Which node?
----
Section 4.4.2 Peer-Identity
s/uniqueness between peers/uniqueness across the set of
all potential peers/


Should you suggest a source of this value since the
uniqueness will depend on all implementations selecting
a value in the same way. Perhaps you could suggest the
use of the Router ID, or some-such.
----
Section 4.4.2 bullet 1
"This will only fail..."
This is a subjective measure of failure.
What you actually mean is "This will only happen..."
But if this can happen (and if it can be done by an on-path
attacker) you need to describe how to recover/protect.
----
Section 4.4.2 bullet 2
"These should be rare events..."
Not only is "rare" subjective, but I don't see how you can
say that hijack attempts should be rare. So the protection
against this type of attack seems to be that you allow a
new MA to be set up and then let it time out.
----
Section 4.4.3 Soft State Concerns for Routing State


You should think carefully about the soft state scalability
concerns of RSVP (see RFC 2961). The Routing State
maintenance process that you describe here and expand on in
Sections 6.2 and 6.3 scale linearly with the number of
Routing States. Discussing rate limiting here is
interesting: how many Routing States would be needed before
rate limiting caused some state not to be refreshed?


The text at the end of 4.4.3 about refresh timing is good,
but conflicts slightly with paragraph 2 where:
  The Querying node MUST generate a Query before this
  timer expires
since what you really mean is that the Query node must act
to ensure the delivery of a Query before the time expires
on the Responder.


Given the impact of UDP rate limiting on top of unreliable
message delivery, you should probably be stronger in your
recommendation of suitable timer values.
----
Section 4.4.3 Leveraging Soft State NSLP for MA keepalive
In the event that the NSLP is a soft state protocol or
contains keep-alive messages, you may want to consider
leveraging those transactions in the setting of the
MA-Hold-Time. This would require that a suitable value for
the MA-Hold-Time was suggested by the NSLP application.
----
Section 4.4.3 TCP failure detection
One use of the MA-Hello may be the converse of what is
proposed. As currently stated, the message keeps alive an
MA that would otherwise be closed down. But another
possibility is that the TCP connection that underlies the
MA fails without being reported to the GIST implementation.
In this case, the implementation would not become aware of
the fact until it next tried to send, or until the hold
time expired.
Although not fatal, such a state of affairs delays delivery
of NSLP messages until the MA can be re-established.
Therefore MA-Hello could be used to detect MA failures. But
that would place quite a different timescale on the rate of
sending.
----
Parallel MAs
Not sure that I saw any comment on the correct use of
parallel MAs. I assume that the rules are that all messages
associated with one flow must be sent on the same MA to
avoid message re-ordering.
Can you make sure that this is stated somewhere.
----
Section 5.1 Confirm
  Confirm: A Confirm may be sent in D-mode, or C-mode if a
  messaging association has been re-used.
The implication of this text is that I can send the Confirm
and pipeline setting up the MA.
But the last para of 5.7.1 says that the Confirm is sent
over the MA.
The table in 5.5 supports 5.1, not 5.7.1.
----
Section 5.1 MA-Hello
A bit obvious, but you may want to recommend (or must) that
an MA-Hello sent in response to an MA-Hello that contains
R=1 does not itself contain R=1.
----
Section 5.2.2
Helpful to state here whether the presence of a duplicate
object is to be ignored or treated as an error.
The former would be better for forward extensibility, but
either would be acceptable.
----
Section 5.3.3
The final paragraphs describe good techniques for
implementations to protect the network. Are there also
mechanisms for nodes to protect themselves? Such as rate
limiting on the receive side.
----
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
----
Section 6.1 and Section 8.4
A DoS attack can come from any node in the network.
Such a node can send a Q-mode Query message as though it
was forwarding it at the GIST level. The result, from any
GIST capable node that intercepts it, may be a D-mode
Response direct to the (spoofed) Query node. The Query
node will handle the Response (according to Rule 2) by
sending a "No Routing State" error message.
Please consider whether a Responder node should be
recommended to keep track of such events and rate limit
processing of new Query messages under such circumstances.
----
Section 6.2
Can I receive er_NoRSM in Awaiting Refresh state?
I think so because my sent Query refresh may have been
lost, the peer may have timed out the state, and I may
have sent Data.
----
Section 6.2
to_Inactive_QNode is not possible in Awaiting Response
state because the timer is not running.
----
Section 6.2
What about the receipt of other errors? Especially fatal
errors.
----
Section 6.2 Rule 3
This action needs to check to see if Confirm was requested.
Should not send a Confirm if one was never requested.


What if the er_NoRSM is sent in response to the Confirm?
This is opening a tight loop! (Such could arise if the
peer has 'lost' the Routing State.


Also, if you have sent several (say 100) Data messages
immediately after a lost Confirm, you will receive 100
er_NoRSM messages and (according to this state machine)
you will send 100 new Confirm messages.


This is not just a mater of implementation optimisation
because you are impacting the network and the adjacent
nodes. Further, this state machine is presented as
normative so variations from it will be tested by
certification labs.
----
Section 6.3 Rule 1
Say "set R=1"
----
Section 6.3 Rule 5
Say "set R=0"
----
Section 6.3
Can I change my mind about whether I want a Confirm
while I am waiting for one?
For example, in Awaiting Confirm state I may receive a
new Query. Must I also set the R flag on the Response
or can I clear the flag and move to Established state?


Similarly, during the refresh processing (since the MA
is now set up and I no longer need to see the Confirm)
can I clear the R flag on refresh Responses? I think the
state machine allows this. But once I am in Awaiting
Refresh state, can I change my mind and send R=0 on my next
Response?
----
Section 6.3
I can receive a Confirm in Established state
----
Section 6.3
to_Expire_RNode is not possible in Awaiting Confirm
state because the timer is not running.
----
Section 6.4
Probably need to support tg_RawData in Connected state :-)
----
Section 6.4
er_MAFailure is not possible in Awaiting Connection state.
----
Section 6.4 Rule 8
Should there be some feedback to the Message State machines
or can we rely on them to fail to find an MA next time they
try?
What about potentially lost messages?
----
Section 7.1.1
"On the assumption"
Can you include the reference, please.  [26]?
----
Section 7.1.4
As demonstrated by Figure 9 and the text in 7.1.1, rapid
local repair may not be such a good idea. It will cause the
GIST state to thrash around and new MAs to be set up for no
purpose because the new flow path is actually an entirely
different route from the head-end.
Thus, in the figure, any action taken immediately by (say)
D1 is a waste of time because the new flow actually does
not touch D1.
Shouldn't you let the flow routing protocol (IGP?) converge
first and let the NSLP drive the repair through its
retransmissions/refreshes/explicit messages?
----
Section 9
The use of reserved blocks within the codepoint registries
appears non-standard. The word "Reserved" does not appear
in RFC 2434.
I would suggest the use of "IETF consensus" with an
additional note saying that the block is reserved for
future expansion. If you do not do this, IANA will not know
under what circumstances to open up the block for
allocation.
----
Section 9 - Object Types etc.
There is a note (using RFC 2119 language, which is not
appropriate in the IANA section) about what must be defined
if a new object type (etc.) is defined. You need to say
where those definitions are expected to be lodged. It reads
like you  are asking IANA to keep the definitions in the
registries.
----
Section 9 - Error classes
IANA will find it helpful if you make clearer that the
2-byte error code is split into an error class and an error
code. You are asking them to keep a registry of the 1-byte
error code as listed in A.4.4 and to track the error class
as a parameter of that registry.
As currently presented, IANA might reasonably assume that
the error codes 0x0101 and 0x0201 are different error
values
----
Section 11.1
draft-loughney-nsis-ext-02.txt seems to have expired.
Do you really want this RFC to be gated on the development
of a personal I-D?
If material in that I-D is normative to GIST (and it
appears that that is the case) you should consider moving
that material into the main GIST specification.
----
Section 11.2
A reference to draft-ietf-nsis-ntlp-statemachine-02.txt
would be a good idea.
----
Section A.2.1
The extensibility flags are very sensible. But the
definition of 10 is not clear. If the message is to be
delivered to an NSLP application, how are objects of this
type handled?
Note that I think the processing described in this section
is normative to the protocol and should appear in the body
of the document.
----
Section A.3.1.1 - Flow Label
You define a "may only be set" for the F flag without
describing how to handle the Flow label (presumably ignore)
if the F flag is set.
----
Section A.3.1.1 - S flag
You say that the S flag can only be set if P=1. How to
process the SPI if P=0?
----
Section A.3.1.1 - A/B flags
You say that these flags can only be set if P=1. How to
process the ports if P=0?
----
Section A.3.3 - Routing state validity time
Did you consider allowing zero for "always valid"?
----
Section A.3.4
Need to say what happens in Prof-Count = 0
The current text says:
"If there are no profiles (i.e. all bytes are null),"
Should this say "if there are no protocol layers in a
profile"?
The description of the padding is fine, but I presume a
receiver MUST ignore all bytes beyond the length indicated
by the layer count field.
----
Section A.3.5
Can MPO-Count be zero? Should say so for clarity.
Did you consider allowing zero for "hold open indefinitely"
Did you consider that different hold times might be
applicable to different MAs according to the protocols in
use?
----
Section A.3.8 - List of translated objects
Please say that the elements of this list are the object
type values defined for use in section A.2.
Please indicate whether the A, B and reserved flags are
relevant.
----
Section A.3.9
Please state padding rules.
----
Section A.4.1
I suspect it is the intention that the Additional
Information objects are encoded as sub-objects (i.e. as
TLVs) since otherwise, parsing the data is impossible
and future extensibility is compromised.
But where is the list of object type values, and shouldn't
IANA manage them?
----
Section A.4.3
Do you want to distinguish between protocol errors (i.e.
messages received at the wrong time) and message
formatting errors?
----
Section A.4.7
I should have thought that the class of this error is
a Permanent-Failure. Or do you plan that a Response will
also be sent even though the NSLP ID cannot be matched?
If no response, then according to Figure 7, the receiver
state machine is stuck. If the error class is Informational
then according to figure 6, the sender state machine is
stuck.
----
Section A.4.9 - Error sub-code 2: Missing Object
How will you identify which object was missing?




=========
Editorial issues

----
Abstract
s/universal/common/
----
Section 2 - Session Identifier
The word "long" is a bit too subjective for inclusion in a
protocol spec. Can you find a better term?
----
Section 3
There is various 2119 notation in this section. I think the
section is not a normative protocol definition so all uses
should go to lower case. But if I am wrong, then the many
lower case uses need to be changed.
----
Section 3.2 - Connection mode
s/objects/messages/
----
Section 3.3 page 13 3rd para
  These updates may be done in separate documents as is
  the case for the base GIST specification, as described
  in Section 7.2.2.
s/base/NAT traversal/
s/7.2.2./7.2.2 and [40]./
----
Section 3.3 page 13 4th para
s/enforce/allow/
----
Section 3.4
  The Data message is used purely to encapsulate signaling
  application data.
Not to deliver it? :-)
----
Section 3.7 point 3
s/towards/to/
----
Section 3.7 point 8
There is a reference to step 6.B, but step 6 has no such
labeling.
----
Section 4, para 1
Delete "in the first place"
----
Section 4.1.1, para 2
Delete "directly"
----
Section 4.1.2 para 1
s/security related/security-related/
----
Section 4.3.4
s/MUST never/MUST NOT/
----
Section 4.4.1
Missing reference in empty square brackets "[]"
----
Section 4.4.2 bullet 1
"appropriate" should be replaced with something more
specific.
----
Section 4.4.3 bullet 2, para 2
s/retain/create/
----
Section 5.2.1
It might be nice to order the fields described here in the
same order as they appear in the message. See A.1
----
Section 5.2.2 GIST-Error-Data
s/determine/report/
----
Section 5.8.1.2
s/vital/essential/
----
Section 6.3 Rule 2 and 8
s/piggybacked/NSLP/
----
Section 9 - MA Protocol IDs
You say "upper layer protocol", but I think "transport
protocol" would be more appropriate.
----
Section 11.2
I think [26] and [27] might usefully be normative.
----
Section A.2.1
s/containing and/containing an/
----
Section A.3.1.1 - P flag
s/IP Protocol/Protocol field/
---- Section A.3.1.2 - D flag
Need to back-reference A.3.1.1 for the definition
----
Section A.3.3
Odd ordering to the field descriptions.
----
Section A.4.10 para 1
s/packet/message/
----
Section D.
Suggest adding an RFC Editor note to have this appendix
deleted before publication as an RFC.

[Ballot discuss]
Overview of DISCUSS: Some of the introductory text in this document is so confusing as to mislead people into believing opposing facts about GIST.  The most definite point of confusion I've identified is whether each signaling node has messaging associations only with its upstream and downstream peers, or whether a signaling node creates a messaging association with the querying node.  Discussion of peers creates the first impression, while discussion of the "responding node" creating a MA with the "querying node" creates the second impression.

I plan on extending this DISCUSS further as I learn more, as I'm sure this document will see considerable discussion in the IESG.  For now, the rest of these points are editorial, but I predict that editorial improvements in the GIST introduction will be key to seeing successful implementations outside the WG participants.

Figure 2: The diagram shows TLS being used to secure TCP and CDDP.  This should show DTLS for those cases instead.  All you need to do is add "D/" to have "D/TLS".

Section 3.7: This walkthrough should indicate that the message in question is a Query.  Step 1, "appropriate for the flow" -- what flow? Where did the NSLP get the message from -- I thought the NSLP would likely create the new message, not process it?

Over the course of reading up to section 4.3, I discovered:
- There is such a thing as a flow (mentioned in the abstract, defined in section 2)
- There is such a thing as a session (mentioned in the introduction, defined in section 2)
- There is such a thing as a Messaging Association or MA (defined in section 2)
- Flow != Session (may be one-one, one-many or many-one, according to 3.5)
- MA != Flow (section 4.2.2)
At this point I'm still confused.  Isn't at least one of these totally up to the NSLP?  That one should be nearly removed from mention in the document, and the relationship of all three discussed all together up front.

Figure 3: Q-mode is first mentioned in this figure.  It would be better to introduce it along with D-mode and C-mode.

Section 4.3.2:  The paragraph beginning "For all other message types" is very confusing to me and I still don't understand it.  The first sentence sounds like it's relegating all further information on message processing to another section, but then the paragraph continues to talk about the rest of the message.  I can't see whether these four sentences in the paragraph are four random facts put together spatially or somehow relate together semantically as well.

Section 4.3.3, last three bullet points.  This is an example of the need to use the "Q-mode" terminology consistently.  I can't tell if the first bullet point means "use Q-mode", or the second bullet point, as well as the third.

Section 4.3.4.  Please be consistent also about the use of RAO Value vs. NSLPID.  (What is their relationship to one another, also needs to be defined.) The first paragraph in this section uses NLSPID, while point 1 immediately following uses RAO value and NSLPID.)

Section 4.4.1.  The term "Q-node" appears in a diagram.  I thought for quite a while this actually read "Q-mode" then for a while I thought it was an overlooked typo.  Very confusing visually. If you can't think of a better term, at least add another line to the boxes at the top:

            +----------+                    +----------+
            |  Q-node: |                    |  R-node: |
            | Querying |                    |Responding|
            |  Node  |                    |  Node  |
            +----------+                    +----------+


Section 4.4.3.  At first it seems that to stop the MA from timing out, the Querying node sends another Query.  But later it says that a node can send an MA-HELLO to cause the MA to be retained. Which is it?

[Ballot discuss]
Figure 2 shows TLS being used over UDP.  DTLS can be used with UDP,
  but that dos not seem to be needed here.  UDP seems to be used for
  D-mode, and D-mode is used when security is not needed.  C-mode is
  used when security is needed.  Much later in the document we learn
  that support for other security protocols is also envisioned,
  including IPsec and SSH.  These offer significantly different
  security services.  Some clue about the security and where it fits
  in the overall architecture and what security services are required
  needs to be introduced earlier in the document.

  Section 5.7.3 says:
  >
  > For use with TCP, implementation of TLS1.0 [7] is REQUIRED and
  > implementation of TLS1.1 [10] is RECOMMENDED.
  >
  While I agree with the goal here, the fact that this is determined
  by negotiation at the TLS layer is lost.  I think the intent is
  that TLS MUST be supported.  Implementations MUST NOT negotiate to
  protocol versions prior to TLS 1.0.  Implementations MUST use the
  highest protocol version supported by both peers.

  Section 5.7.3 also says:
  >
  > ...MUST be able to negotiate the TLS ciphersuite
  > TLS_RSA_WITH_3DES_EDE_CBC_SHA and SHOULD be able to negotiate the
  > TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA.
  >
  This structure is odd, because the preferred ciphersuite is in the
  SHOULD statement.  In the IPsec WG, this situation was handled with
  the "MUST-" and "SHOULD+" key words.  See RFC 4307 for a definition
  of these words.  I suspect that you also want a MAY statement,
  perhaps: "... MAY netotiate any mutually acceptable ciphersuite
  that provides authentication, integrity, and confidentiality."

  The second paragraph of Section 5.7.3 deals with TLS authentication.
  However, the paragraph does not indicate how to determine whether
  the identity in the certificate is acceptable.  Some form of
  identity checking must be included for the certificate to provide
  the expected authentication.

[Ballot comment]
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". Thus my inclination would be to prefer "experimental" status at first.

That said, I don't really like to put a "defer" on a document since this slows down an already excessively slow process, but I nonetheless feel that I need a couple of weeks to review this properly. My apologies.

[Ballot discuss]
>  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.  There is a dual problem of
>  whether the GIST peers either side of the boundary can work out
>  how to address each other, and whether they can work out what
>  translation to apply to the signaling packet payloads.  The
>  fundamental problem is that GIST messages contain three or four
>  interdependent addresses which all have to be consistently
>  translated, and existing generic NAT traversal techniques such as
>  STUN [23] or TURN [24] can process only two.  Appropriate
>  behaviour for a GIST-aware NAT is discussed in Section 7.2.
...
>  GIST messages must carry packet addressing and higher layer
>  information as payload data in order to define the flow signalled
>  for.  (This applies to all GIST messages, regardless of how they are
>  encapsulated or which direction they are travelling in.)  At an
>  addressing boundary the data flow packets will have their headers
>  translated; if the signaling payloads are not translated
>  consistently, the signaling messages will refer to incorrect (and
>  probably meaningless) flows after passing through the boundary.  In
>  addition, GIST handshake messages carry additional addressing
>  information about the GIST nodes themselves, and this must also be
>  processed appropriately when traversing a NAT.

I do not understand all the implications of
running GIST over a non-modified NAT. If the
implications are benign, please explain why
that is the case. If they are serious, the
protocol should fail gracefully upon detecting
a NAT. Without additional information I
worry that the design is brittle enough that
it may cause harm to the senders, receivers,
GIST nodes, or worse, outsiders when a GIST
unaware NAT causes the address information
to become invalid.

[Ballot comment]
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.
...
  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.

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?

[Ballot discuss]
I am concerned that the peer discovery process is scattered throughout the document in ways that will make it difficult for implementors.  The document says:

[Adjacent] Peer:      The next node along the data path, in the upstream
      or downstream direction, with which a GIST node explicitly
      interacts.  The GIST peer discovery mechanisms implicitly
      determine whether two nodes will be adjacent.  It is possible for
      adjacencies to skip over intermediate nodes which decide not to
      take part in the signaling exchange at the NTLP layer; even if
      such nodes process parts of the signaling messages, they store no
      state about the session and are never visible at the GIST level to
      the nodes on either side.

and

    GIST defines a three-way handshake which
  probes the network to set up the necessary routing state between
  adjacent peers, during which signaling applications can also exchange
  data.

but the details are fairly well distributed in different sections.  That means some
related questions (such as whether an on-path node that was not initially
part of the GIST layer interaction could insert itself later as a peer) are hard
to work through.

I am willing to drop this request if there is significant push back, but I do believe
that a gathered description of this would be a help to readers and implementors.

[Ballot discuss]
First, thanks for a well written protocol writeup.  While I'm bringing
up serious concerns, I think that we'll be able to address them and
move forward relatively quickly.


How does GIST deal with lost response packets in the case where there
are multiple responders.  The discussion in section 5.3.3 presents an
argument that a node will get at least one query response.  However,
it seems that there could be multiple GIST nodes wishing to
participate in signaling between the querying node and the destination
of the data flow (assuming path-coupled MRM).
How will you know if there was a GIST peer who wanted to set up routing state but whose response was lost?

GIST raises significant architectural concerns about the end-to-end
service model of the Internet.  In particular there are multiple cases
having to do with q-mode encapsulation where GIST nodes consume,
generate and modify packets that are neither sourced nor destined for
them.  The advice in section 7.2 goes against the requirements of
section 7 of draft-ietf-behave-nat-udp (an approved BCP).  Even so, I
think it is necessary for GIST to do these things but I think we need
to be very careful about the interactions with other things deployed
on the Internet.  We also want to discourage general applications of
this form and I think it critical that we establish architectural
requirements so that future proposals work with GIST.  I don't think
it necessary to block GIST on that architectural work.

I propose that:

1) A section of the GIST document be added clearly indicating when a
GIST implementation can modify a packet not targeted for itself and
when it is expected to intercept such packets.  That is currently
scattered too much throughout the document.  Specific care should be
given to cases where a GIST node will not forward traffic for which it
would normally act as a router.  In particular, I think it would be
harmful if traffic that happened to be on the GIST UDP port were
discarded if it clearly had no relation to GIST.


2) Discuss interactions with AH and other mechanisms that might be
added (especially by intermediate routers) that could cause problems
when packets are modified.


3) Explicitly call out this document's divergence from draft-ietf-behave-nat-udp.

4) Send a more general architectural question to the community and IAB.


Would it be possible to add a MAC (message integrity code) based on a
negotiated secret to D-mode packets using an extensibility mechanism?
If so, how would this be done?  I don't think we need require this
now, but I do think we need to make sure that if modification of
D-mode packets becomes a problem we have a solution we can specify.


The discussion of TLS needs to describe what names certificates need
to use.

Section 8.3 claims that authenticated peers can be trusted not to
claim they are on-path when they are off-path.  Authentication is not
the same as authorization.  The discussion of when this assumption is
reasonable needs to be significantly expanded.


There does not seem to be a discussion of extensibility in the main
body of the document.

[Ballot comment]
COMMENT:

  Nit: Mixes US and British English (e.g., signalling vs. signaling,
  etc.) - pick one.


Section 3.1., paragraph 7:
>              Figure 2: Protocol Stacks for Signaling Transport

  Nit: TLS doesn't currently operate over DCCP, and there are some
  issues with operating over some variants of SCTP.



Section 3., paragraph 0:
>        a messaging association.  The Query is encapsulated in a UDP
>        datagram and injected into the network, addressed towards the
>        flow destination and with an IP Router Alert Option (RAO)
>        included.

  Some IP options force packets onto a router's slow path, which may
  contribute to resource exhaustion. I assume that the authors have
  verified that Router Alert Options are safe to use in this regard?


Section 4., paragraph 0:
>    4.  The Query passes through the network towards the flow receiver,
>        and is seen by each router in turn.  GIST-unaware routers will
>        not recognise the RAO value and will forward the message
>        unchanged; GIST-aware routers which do not support the NSLP in
>        question will also forward the message basically unchanged,
>        although they may need to process more of the message to decide
>        this.

  Many middleboxes drop packets with IP options (Alberto Medina, Mark
  Allman, Sally Floyd. Measuring the Evolution of Transport Protocols in
  the Internet. ACM Computer Communication Review, 35(2), April 2005.)
  Although I assume that this will mostly occur on the first or last
  couple of hops, this can still interfere with end-to-end NSIS
  operation.


Section 4.1.2., paragraph 2:
>    Reliability:  This attribute may be 'true' or 'false'.  When 'true',
>      messages MUST be delivered to the signaling application in the
>      peer exactly once or not at all;

  "Once or not at all" isn't exactly the typically definition of
  reliability. Is there a better term for what is meant here?


Section 4.1.2., paragraph 3:
>      TCP is considered in Section 5.7.2.  Messages with the same SID to
>      the same peer MUST be delivered in order.

  ...unless they are not delivered at all.


Section 4.1.2., paragraph 4:
>      When 'false', a message
>      may be delivered, once, several times or not at all, with no error
>      indications in any case.

  What about reordering when "false" - are duplicates of a message
  allowed to arrive after later messages have arrived?


Section 4.1.2., paragraph 6:
>      intermediate nodes.  An NSLP may also indicate that reverse path
>      routing state will not be needed for this flow, to inhibit the
>      node requesting its downstream peer to create it.

  s/may/MAY/


Section 4.3.2., paragraph 1:
>    prevent looping, MUST be checked and decremented immediately the
>    message has been received.  Further processing depends on the message

  Nit: s/immediately the/immediately after the/


Section 5.2.2., paragraph 10:
>      The setting and interpretation of the IP-TTL field depends on the
>      message direction (upstream/downstream as determined from the MRI
>      as described above) and encapsulation.

  Routers may decrement the IP TTL by more than than 1, and there is no
  requirement that routers use the same decrement value on all
  interfaces. Is this mechanism robust under these conditions?


Section 5.3.3., paragraph 2:
>    Query messages which do not receive Responses MAY be retransmitted;
>    retransmissions MUST use a binary exponential backoff.  The initial
>    timer value is T1, which the backoff process can increase up to a
>    maximum value of T2 seconds.  The default value for T1 is 500 ms.  T1
>    is an estimate of the round-trip time between the querying and
>    responding nodes.  Elements MAY use smaller values of T1 if it is
>    known that the Query should be answered within the local network.  T1
>    MAY be chosen larger, and this is RECOMMENDED if it is known in
>    advance (such as on high latency access links) that the round-trip
>    time is larger.  The default value of T2 is 64*T1.

  500ms seems short. TCP uses T1=3sec for SYN retransmissions and DNS
  uses T1=5sec. (However, I think SIP uses 500ms, too?)



Section 2., paragraph 2:
>    It can be seen that all of these transport protocol options can be
>    supported by the basic GIST message format already presented.  GIST
>    messages requiring fragmentation must be carried using a reliable
>    transport protocol, TCP or SCTP.  This specification defines only the
>    use of TCP, but other possibilities could be included without
>    additional work on message formatting.

  This paragraph should be moved to 5.1 or even earlier, as it is not
  specific to C-mode. It would also be good to discuss in more detail
  what "require fragmentation" means, i.e., GIST message > path MTU (or
  512 bytes, if path MTU is unknown). Additionally, because some
  messages MUST be carried in D- or Q-mode - is it guaranteed that their
  payloads are always less than 512 bytes?

  Also, s/must/MUST/.


Section 5.4.2., paragraph 0:
>    5.4.2.  Encapsulation Format

  Move up, section is not specific to C-mode. Section 5.4 should
  probably be restructured after these changes.


Section 5.7.1., paragraph 1:
>    A key attribute of GIST is that it is flexible in its ability to use
>    existing transport and security protocols.  Different transport
>    protocols may have performance attributes appropriate to different
>    environments; different security protocols may fit appropriately with
>    different authentication infrastructures.

  All protocols defined in the subsections of this section are for
  C-mode - what about D-mode?


Section 5.8.1.3., paragraph 0:
>    5.8.1.3.  Upstream Q-mode Encapsulation

  No restriction on message size. See DISCUSS.


Section 6.2., paragraph 20:
>    Rule 4:

  Nit: Pseudocode not indented.


Section 7.2., paragraph 0:
>    7.2.  NAT Traversal

  Are any GIST-aware NATs in existence? It seems that this section is
  mostly about a hypothetical mechanism.


Section 7.3., paragraph 0:
>    7.3.  Interaction with IP Tunnelling

  This subsection doesn't really belong under "Advanced Protocol
  Features."

[Ballot discuss]
DISCUSS: For anything sent over UDP, i.e., D- and Q-mode, it must be
  made clear that messages must have payloads smaller than the PMTU
  (minus headers) or 512 bytes if the PMTU is unknown, to avoid
  fragmentation. (Section 5.4.1 and 5.8.1.2 do so, but other sections do
  not.) Because some messages MUST be transmitted in D- or Q-mode, are
  such messages guaranteed to be less than this limit in all cases?
  Furthermore, a suitable rate control mechanism for the use with UDP
  must also be described. The token bucket in section 5.3.3 is
  insufficient, see below.


Section 3.5., paragraph 8:
>    o  Messages with the same SID that are to be delivered reliably
>      between the same GIST peers are delivered in order.

  DISCUSS: If messages with the same SID go over different messaging
  associations, there is a possibility that they reach the peer out-of
  order, even if each messaging association guarantees in-order
  delivery. I don't see this case addressed in the document.


Section 2., paragraph 4:
>    The basic rate-control requirements for D-mode traffic are
>    deliberately minimal.  A single rate limiter applies to all traffic,
>    for all interfaces and message types.  It applies to retransmissions
>    as well as new messages, although an implementation MAY choose to
>    prioritise one over the other.  Rate-control applies only to locally
>    generated D-mode messages, not to messages which are being forwarded.
>    When the rate limiter is in effect, D-mode messages MUST be queued
>    until transmission is re-enabled, or an error condition MAY be
>    indicated back to local signaling applications.  The rate limiting
>    mechanism is implementation-defined, but it is RECOMMENDED that a
>    token bucket limiter as described in [31] be used.  The token bucket
>    MUST be sized to ensure that a node cannot saturate the network with
>    D-mode traffic, for example when re-probing the network for multiple
>    flows after a route change.  A suitable approach is to restrict the
>    token bucket parameters so that the mean output rate is a small
>    fraction, such as 5%, of the node's lowest-speed interface.

  DISCUSS: "Node cannot saturate the network" is a very weak statement
  when it comes to congestion control, because it does not take
  concurrent traffic into account. Furthermore, bandwidth limits of, for
  example, "5% of the node's lowest-speed interface" also don't have the
  desired effect. Consider a router with only Gigabit Ethernet
  interfaces. By the definition above, it'd be allowed to send at a rate
  of 50Mb/s. If one of those links connects to a layer-2  switch that
  connects to the next router using 10Mb/s Ethernet, those 50Mb/s will
  overload the link. A similar case exists when a non-NSIS router is
  located between two NSIS routers. Even worse, fixed rate limits do not
  take concurrent network traffic along the link/path into account.
  Along a fully loaded link/path, adding 5% traffic can significantly
  impact concurrent flows. What an appropriate mechanism could be
  deserves some more discussion. There are several options, such as
  limiting each MA to a single outstanding D-mode request, which limits
  the additional traffic to be proportional to the number of MAs/flows,
  or more complex schemes if that is too limiting (AIMD, etc.)

IANA Last Call Comments:

IANA has questions regarding this document.

Upon approval of this document several new registries are to be created for the NSIS protocol suite. IANA would like to know if these should be located within a single registry for the NSIS protocol or if the registries and codepoints should be separate, individual registries?

This document requests a well-known UDP port be established for Q-mode
encapsulated GIST messages. IANA would like to know if a port number from the User Registered Port number range is sufficient?

This document requests that several new registries be established. Among them, the GIST Message Types registry, the GIST Message Routing Method Identifier registry, the MA-Protocol Identifier registry and the error code/subcode
registry have similiar allocation policies. In each, the allocation policy for the number range 64 through 119 requires expert review. Has an expert(s) been identified for future allocation of numbers in these registries for the identified range?

This document requests that a new registry for MA-Protocol-IDs be established.
Was the value 0 (zero) left out of the registry on purpose? What should the allocation policy be for the value 0 (zero) in this registry?

Once this has been established, IANA understands that the following actions (summarized first) should take place.

1) allocation of a UDP port as the destination port for Q-mode encapsulated GIST messages;
2) creation of a registry for NSLP Identifiers;
3) creation of a registry for GIST Message Types;
4) creation of a registry for Object Types;
5) creation of a registry of GIST Message Routing Methods;
6) creation of a registry of MA-Protocol-IDs; and,
7) creation of a registry for Error Codes/Subcodes.

IANA requests that the authors confirm that all required actions have been
identified in the list above. Upon approval of the document, IANA will take the following actions:

1) allocation of a UDP port as the destination port for Q-mode encapsulated GIST messages

IANA will allocate a UDP port number (tbd) as the destination port for Q-mode encapsulated GIST messages in the registry located at:
http://www.iana.org/assignments/port-numbers.

2) creation of a new registry for NSLP Identifiers

IANA will create a new registry for NSLP Idenfitiers. There will be a single initial value in the registry:

VALUE Application
------------------------------------------------------------------------
0 Used for GIST messages not related to any signaling application.

Future values in this registry will have the following allocation policies:

1-32703: IESG Approval

32704-32767: Private/Experimental Use

32768-65536: Reserved

3) creation of a registry for GIST Message Types

IANA will create a new registry for GIST Message Types. There will be six
intial values in the registry

MType Message
--------------------------------------------
0 Query
1 Response
2 Confirm
3 Data
4 Error
5 MA-Hello

Future values in this registry will have the following allocation policies:

6-63: Standards Action

64-119: Expert Review

120-127: Private/Experimental Use

128-255: Reserved

4) creation of a registry for Object Types;

IANA will create a new registry for Object Types. There will be 10 initial
values in the registry:

OType Object Type
-------------------------------------------
0 Message Routing Information
1 Session ID
2 Network Layer Information
3 Stack Proposal
4 Stack Configuration Data
5 Query Cookie
6 Responder Cookie
7 NAT Traversal
8 NSLP Data
9 Error

Future values in this registry will have the following allocation policies:

10-1023: Standards Action

1024-1999: Specification Required

2000-2047: Private/Experimental Use

2048-4095: Reserved

5) creation of a registry of GIST Message Routing Methods

IANA will create a new registry for Message Routing Method Identifiers. There will be two initial values in this registry:

MRM-ID Message Routing Method
-------------------------------------------------
0 Path Coupled MRM
1 Loose End MRM

Future values in this registry will have the following allocation policies:

2-63: Standards Action

64-119: Expert Review

120-127: Private/Experimental Use

128-255: Reserved

6) creation of a registry of MA-Protocol-IDs

IANA will create a new registry for MA Protocol Identifiers. There will be two
initial values in this registry.

MA-Protocol-ID Higher Layer Protocol
-----------------------------------------------------------
1 TCP opened in the forwards direction
2 TLS initiated in the forwards direction

Future values in this registry will have the following allocation policies:

3-63: Standards Action

64-119: Expert Review

120-127: Private/Experimental Use

128-255: Reserved



7) creation of a registry for Error Codes and Subcodes.

IANA will create a new registry for Error Codes and Subcodes There will be 12 initial values in this registry. Error code number 1 will have 4 subcodes.
Error code number 9 will have 6 subcodes. Error code 10 will have six subcodes.
Error code 12 will have three subcodes.

Error Codes Error Class
--------------------------------------------
1 Common Header Parse Error
2 Hop Limit Exceeded
3 Incorrect Encapsulation
4 Incorrectly Delivered Message
5 No Routing State
6 Unknown NSLPID
7 Endpoint Found
8 Message Too Large
9 Object Type Error
10 Object Value Error
11 Invalid IP layer TTL
12 MRI Validation Failure

Future values in this registry are allocated on a first come - first served basis.

Error Code 1 [ Common Header Parse Error ] - Error Subcodes

Error Subcode Error Class
--------------------------------------------
0 Unknown version
1 Unknown type
2 Invalid R-flag
3 Incorrect Message Length

Error Code 9 [ Object Type Error ] - Error Subcodes

Error Subcode Error Class
--------------------------------------------
0 Duplicate Object
1 Unrecognized Object
2 Missing Object
3 Invalid Object Type
4 Untranslated Object
5 Invalid Extensibility Flags

Error Code 10 [ Object Value Error ] - Error Subcodes

Error Subcode Error Class
--------------------------------------------
0 Incorrect Length
1 Value not supported
2 Invalid Flag-Field Combination
3 Empty List
4 Invalid Cookie
5 Stack Proposal

Error Code 12 [ MRI Validation Failure ] - Error Subcodes

Error Subcode Error Class
--------------------------------------------
0 MRI Too Wild
1 IP Version Mismatch
2 Ingress Filter Failure

Future values in these subcode registries are allocated on a first come - first served basis.

PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes.

2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

Yes. The ID has passed working group last calls, has had good reviews
during the process, including an early reviews by Bob Braden and Brian
Carpenter prior to acceptance as a working group document.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, etc.)?

No concerns. The document has undergone extensive Working Group review,
and has several (at least 6) interoperable implementations.


4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

No

5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?

There is a strong consensus in the WG supporting this work, at this
point there is no disenting voices about the protocol in the WG.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

Yes, I reviewed them personally, and ran the idnits checker on them:

idnits 1.85

nsis/draft-ietf-nsis-ntlp/draft-ietf-nsis-ntlp-09.txt:


Checking nits according to http://www.ietf.org/ID-Checklist.html:

Checking conformance with RFC 3978/3979 boilerplate...

the boilerplate looks good.

No nits found.

Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
Nothing found here (but these checks do not cover all of
1id-guidelines.txt yet).

Miscellaneous warnings:
None.

No nits found.

8) Does the document a) split references into normative/informative,
and b) are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(Note: the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)

The document does split references into normative and informative ones.

9) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:

- Technical Summary

This draft proposes a general signaling transport protocol. It is based
on the use of existing transport and security protocols under a common
messaging layer. GIST does not handle signaling application state
itself; in that crucial respect, it differs from application signaling
protocols such as SIP, RTSP, and the control component of FTP, but this
follows the basic NSIS 2-layer signaling model defined in RFC 4080.

- Working Group Summary

There have been 1 WGLC on the document, plus several pre-WGLCs on the
document.
The editors have gotten extensive feedback from implementors and have
clarified text based upon the feedback. There are 6 or more independent
implementations of GIST, and there was an interop event prior to the
Paris IETF meeting.

- Protocol Quality

This document was reviewed by the working group chair as well as the WG.
I feel that this document is ready, and implementors feel that the
specification is implementatble.