Subject: [NSIS] GIST WGLC comments

From: Andrew McDonald <[email-masked]>
Date: Thu, 03 May 2007 08:47:26 +0100

Hi all,

My review comments are below. Generally the document is readable, and 
provides a reasonable balance between background and detailed 
specification. My comments are mainly editorial or on minor issues of 
clarity. I don't believe there are any serious technical problems with 
the draft.

Andrew

 > 1.  Introduction
 >    (GIST).  GIST does not handle signalling application state itself; in
 >    that crucial respect, it differs from application signalling
 >    protocols such as SIP, RTSP, and the control component of FTP.
 >    Instead, GIST manages its own internal state and the configuration of
 >    the underlying transport and security protocols to ensure the
 >    transfer of signalling messages on behalf of signalling applications
 >    in both directions along the flow path.

I found the comparison/differentiation from application signalling
slightly confusing. I'm ot sure if it could be clarified. It is probably
the juxtaposition of the terms "signalling application" and "application
signalling" that are the problem.

 >    operation is captured in the form of state machine language in

possible reword:
state machine language -> state machines

 >    packets with IP options to probe the network, which leads to
 >    migration issues in networks with non-GIST nodes, especially in the
 >    case of IPv4, and these are discussed in Appendix C.

"networks with non-GIST nodes" is basically every existing deployed
networks. That sounds like a total roadblock to deployment. I don't
think the situation is really that bad!

 >    document, Section 9 gives the formal IANA considerations for the
 >    registries already defined by the GIST specification.

suggested reword:
registries already defined -> registries defined

 > 2.  Requirements Notation and Terminology
 >    GIST Node:  Any node along the data path supporting GIST, regardless
 >       of what signalling applications it supports.

Does this definition include GIST-aware NATs?

 >    Messaging Association (MA):  A single connection between two
 >       explicitly identified GIST adjacent peers, i.e. between a given
 >       signalling source and destination address.  A messaging
 >       association may use a specific transport protocol and known ports.
 >       If security protection is required, it may use a specific network
 >       layer security association, or use a transport layer security
 >       association internally.  A messaging association is bidirectional:
 >       signalling messages can be sent over it in either direction,
 >       referring to flows of either direction.

The phrase "may use a specific transport protocol and known ports"
seems a little odd? It made we wonder whether there was some
possibility of using "unknown ports" that was being deliberately
excluded. Use of the word 'specific' also seemed superfluous (on both
occasions).

 > 3.1.  Overall Design Approach
 >    To meet the routing requirement, one possibility is for the node to
 >    use local routing state information to determine the identity of the
 >    GIST peer explicitly.  GIST defines a three-way handshake which
 >    probes the network to set up the necessary routing state between
 >    adjacent peers, during which signalling applications can also
 >    exchange data.

The term 'routing state' is GIST-specific jargon which hasn't really
been introduced at this stage. Could it be reworded?

 >    (NTLP).  The strategy of splitting the transport problem leads to a
 >    layered structure for the NTLP, of a specialised GIST messaging layer

possible edit:
of a -> with a

[snip]
 >                  ========|===================|=====  <-- GIST API
 >                          |                   |
 >           ^^       +------------------------------------------------+
 >           ||       |+-----------------------+      +--------------+ |
 >           ||       ||         GIST          |      | GIST State   | |
 >           ||       ||     Encapsulation     |<<<>>>| Maintenance  | |
 >           ||       |+-----------------------+      +--------------+ |
 >           ||       | GIST: Messaging Layer                          |
 >           ||       +------------------------------------------------+
[snip]
 >       Figure 2: Protocol Stack Architecture for Signalling Transport

The term "GIST Encapsulation" seemed unclear to me. I suspect it is
meant to be deliberately vague. Could it be made differently vague?

 > 3.2.  Modes and Messaging Associations

 >    Connection mode (C-mode):  used for larger messages or where fast
 >       state setup in the face of packet loss is desirable, or where
 >       channel security is required.

Setup of what state? Signalling Application state?

 >    D-mode uses UDP, as a suitable NAT-friendly encapsulation which does

suggested edit:
remove ','

 >    not require per-message shared state to be maintained between the
 >    peers.  Long-term evolution of GIST is assumed to preserve the
 >    simplicity of the current D-mode design.  Extensions to the security
 >    or transport capabilities of D-mode can be provided equivalently by
 >    selecting a different protocol stack under the GIST messaging layer,
 >    which would then become another option within the overall C-mode
 >    framework.  This includes both the case of using existing protocols

I got slightly confused by the sentence "Extensions
... framework.". Could it be reworded?  Replacing 'equivalently' with
'alternatively' or 'instead' would probably have been enough for
me. (I think part of the point is that 'if you want to do this, do it
with C-mode, not D-mode').

 > 3.3.  Message Routing Methods

 >    Most of the details of GIST operation are independent of which is
 >    being used.  Therefore, the GIST design encapsulates the routing-
 >    dependent details as a message routing method (MRM), and allows

Which of what alternatives? My first read of this was that it was a
choice between 'predictive routing' and 'nat address
resverations'. Maybe change 'which is' to 'the message routing'.

 >    The content of a MRM definition is as follows, using the path-coupled
 >    MRM as an example:

suggested edit:
a MRM -> an MRM

 >    o  A specification of the IP-level encapsulation of the messages
 >       which probe the network to discover the adjacent peers.  A
 >       downstream encapsulation must be defined; an upstream
 >       encapsulation is optional.

Random thought: is it impossible to envisage an MRM that can only do
upstream routing? Or, is there some other reason for the constraint?

 >    The Query, Response and Confirm messages implement the handshake that
 >    GIST uses to set up routing state and messaging associations.  The
 >    handshake is initiated from the Querying node towards the Responding
 >    node.  The first message is the Query, which is encapsulated in a
 >    special way depending on the message routing method, in order to
 >    probe the network infrastructure so that the correct peer will
 >    intercept it and become the Responding node.  A Query always triggers

'probe the network' and 'intercept it' are true for current MRMs. Are
they true for all beyond-current-GIST MRMs?

 >    a Response in the reverse direction as the second message of the
 >    handshake.  As part of the defence against denial of service attacks,
 >    the Responding node can delay state installation until a return
 >    routability check, and require the Querying node to complete the

suggested reword:
"a return routability check" -> "a return routability check has been
performed"

 > 3.5.  GIST Peering Relationships
 >
 >    Peering is the process whereby two GIST nodes create message routing
 >    state which point to each other.

Something seemed a bit odd about this sentence. Does 'state' need to
be 'states'? (i.e. they each create some state; they don't jointly
create one piece of state)

 >    change.  As well as network level rerouting, changes could include
 >    modifications in NSIS signalling functions deployed at a node, or

suggested reword:
"modifications in" -> "modifications to"

 > 4.2.1.  Message Routing State

 >    o  The node is using other techniques to send the message.  For
 >       example, it can send it in Q-mode and rely on the peer to
 >       intercept it.

Possible reword:
"other techniques to send the message" -> "other techniques to route
the message" or "other techniques to address the message" or something
of that sort
It's only the 'how to get this to the next hop' question. The text
could (maybe) be read as broader than that.

 >
 >    In addition, if the node is a flow endpoint, GIST will refuse to
 >    create routing state for the direction beyond the end of the flow
 >    (see Section 4.3.3).

This isn't really 'in addition' since it overlaps with the 2nd bullet
above. Maybe "In particular," instead. And, maybe, "refuse to attempt
to create" rather than just "refuse to create".

 > 4.3.  Basic GIST Message Processing
 >
 >    This section describes how signalling application messages are
 >    processed in the case where any necessary messaging associations and
 >    routing state are already in place.  The description is divided into
 >    several parts.  Firstly, message reception, local processing and
 >    message transmission are described for the case where the node hosts
 >    the NSLPID identified in the message.  Secondly, the case where the
 >    message is handled directly in the IP or GIST layer (because there is
 >    no matching signalling application on the node) is given.  An
 >    overview is given in Figure 3.  This section concentrates on the GIST
 >    level processing, with full details of IP and transport layer
 >    encapsulation in Section 5.3 and Section 5.4.

"Firstly" and "Secondly" are slightly confusing, since the 'firstly'
actually covers sections 4.3.1 to 4.3.3, while 'secondly' is just 4.34.
Maybe reword to:
"Firstly (in sections 4.3.1 to 4.3.3)" and "Secondly (in section
4.3.4)"

 >        +---------------------------------------------------------+
 >        |        >>  Signalling Application Processing   >>       |
 >        |                                                         |
 >        +--------^---------------------------------------V--------+
 >                 ^                                       V
 >                 ^             NSLP Payloads             V
 >                 ^                                       V
 >        +--------^---------------------------------------V--------+
 >        |                    >>    GIST    >>                     |
 >        |  ^           ^  ^     Processing      V  V           V  |
 >        +--x-----------N--Q---------------------Q--N-----------x--+

It's not clear what the 'NSLP Payloads' in this diagram is.

Having made a guess about what it is trying to say, I'd suggest either
changing it to:
        +---------------------------------------------------------+
        |        >>  Signalling Application Processing   >>       |
        |                                                         |
        +--------^---------------------------------------V--------+
                 ^   NSLP                         NSLP   V
                 ^ Payloads                     Payloads V
                 ^                                       V
        +--------^---------------------------------------V--------+
        |                    >>    GIST    >>                     |

Or get rid of the 'NSLP Payloads' text altogether.

 > 4.3.1.  Message Reception

 >    Normal encapsulation:  Normal messages arrive UDP-encapsulated and
 >       addressed directly to the receiving signalling node, at an address
 >       and port learned previously.  Each datagram contains a single

"port learned previously" sounds like some special discovery mechanism
has been used. Actually it is just "GIST well known port" or "the UDP
port we got a message from". Could it be reworded?

 >       message which is passed to the GIST layer for further processing,
 >       just as in the C-mode case.
 >
 >    Q-mode encapsulation:  Where GIST is sending messages to be
 >       intercepted by the appropriate peer rather than directly addressed
 >       to it (in particular, Query messages), these are UDP encapsulated,
 >       and MAY include an IP router alert option (RAO) if required by the
 >       MRM.

I think this should be a 'may' rather than a 'MAY'. The RFC2119
language would be in the relevant MRM description.

 > 4.3.3.  Message Transmission
 >
 >    Signalling applications can generate their messages for transmission,
 >    either asynchronously, or in reply to an input message, and GIST can

I assume 'input message' means a message received by the signalling
app from GIST, rather than an 'input message' received through some
other API on the signalling app. Is it worth making clearer?

 >    If a messaging association is not required, the message is sent in
 >    D-mode.  The processing in this case depends on the message type and
 >    whether routing state exists or not.

Is 'not required' the best wording? It suggests that there are some
circumstances where it is required, but the default fall-back position
is to use D-mode. Would 'not appropriate' be better?

 > 4.3.4.  Nodes not Hosting the NSLP

 >    1.  A message contains an RAO value which is relevant to NSIS, but it
 >        does not exactly match the Q-mode encapsulation rules of
 >        Section 5.3.2.  The message MUST be transparently forwarded at
 >        the IP layer.

This says 'at the IP layer', but the Q-mode checks require GIST
involvement. So, is it 'at the IP layer'?

Should there be mention in this (otherwise fairly comprehensive) list
of what to do with an RAO value which is not relevant?

 >    2.  A Q-mode encapsulated message contains an RAO value which is
 >        relevant to NSIS but not to the specific node, but the IP layer
 >        is unable to recognise whether it needs to be passed to GIST for
 >        further processing or whether the packet should be forwarded just
 >        like a normal IP datagram.
 >
 >    3.  A Q-mode encapsulated message contains an RAO value which is
 >        relevant to the node, but the specific signalling application for
 >        the NSLPID in the message is not processed there.

I found these two points a little unclear. There seemed to be some
overlap between the two points.

Actually, on reading (2) again, I'm not sure what it really is
saying. It feels like it overlaps with (3), but I'm no longer sure.

 >    In cases (2) and (3), the role of GIST is to forward the message
 >    essentially as though it were a normal IP datagram, and it will not
 >    become a peer to the node sending the message.  Forwarding with
 >    modified NSLP payloads is covered above in Section 4.3.2.  However, a
 >    GIST implementation MUST ensure that the IP-layer TTL field and GIST
 >    hop count are managed correctly to prevent message looping, and this
 >    should be done consistently independently of whether the processing
 >    takes place on the fast path or in GIST-specific code.  The rules are
 >    that in cases (2) and (3), the IP-layer TTL MUST be decremented just
 >    as if the message was a normal IP forwarded packet; in case (3) the
 >    GIST hop count MUST be decremented as in the case of normal input
 >    processing, which also applies to cases (4) and (5).

I'm unclear on why there is a difference between handling (2) and
(3). I suspect my confusion over (2) and (3) itself probably doesn't
`help. In fact, (2) doesn't identify messages that need to be forwarded
- it just says "GIST needs to look at it harder and decide". So, I'm
not sure why GISTs role is to forward these messages regardless.

Is any further guidance needed on preserving the original IP
headers, e.g. with respect to DSCPs or ECN marking?

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

Although this last point is a 'MAY', I think that's the only way to do
it if you are going to fully obey the 'MUST NOT', since the 'MUST NOT'
means that you have to forward errored data that you would be unable
to parse.

 > 4.4.  Routing State and Messaging Association Maintenance

 >    The initial message in any routing state maintenance operation is a
 >    Query, sent from the querying node and intercepted at the responding

suggested reword:
"intercepted at the" -> "intercepted by the node that will become the"
since it you know that it is going to be the responding node at the
time of interception

 > 4.4.2.  GIST Peer Authorisation

 >    This specification models the decision as verification by the
 >    authorising node of the peer's identity against a local list of
 >    peers, the authorised peer database (APD).  The APD is a abstract

"a abstract" -> "an abstract"

 > 4.4.3.  Messaging Association Multiplexing

 >       For routers, the Router-ID [2], which is one of the router's IP
 >       addresses, MAY be used as one possible value for the Peer-
 >       Identity.  In scenarios with nested NATs, the Router-ID alone may
 >       not satisfy the uniqueness requirements, in which case it MAY be
 >       extended with additional tokens, either chosen randomly or
 >       administratively coordinated.

I don't believe the RFC1812 (i.e. ref [2]) Router-ID is
appropriate. It only appears to be defined for unnumbered links. More
importantly: "Routers with multiple unnumbered interfaces MAY have
multiple router-id's.". This doesn't meet the interface independence
requirement.

 > 4.4.4.  Routing State Maintenance
 >
 >    Each item of routing state expires after a lifetime which is
 >    negotiated during the Query/Response/Confirm handshake.  The Network
 >    Layer Info (NLI) object in the Query contains a proposal for the
 >    lifetime value, and the NLI in the Response contains the value the
 >    Responding node requires.

What routing state lifetime value is carried in the Confirm?

 > 4.4.5.  Messaging Association Maintenance

 >       Because the Responding node can choose not to create state until a
 >       Confirm, an abbreviated Stack-Configuration-Data object containing
 >       just this information MUST be repeated by the Querying node in the
 >       first Confirm sent on a new MA.  If the object is missing in the
 >       Confirm, an "Object Type Error" message (Appendix A.4.4.9) with
 >       subcode 2 ("Missing Object") MUST be returned.

Should it be made clearer that this is the SCD from the Query that is
repeated (i.e. not the one from the Response being reflected back).

 > 5.1.  GIST Messages

 >    GIST-Message: The primary messages are either one of the stages in

suggested reword:
"one of the stages in" -> "part of"

 >    indicate if a reply of some sort is requested.  The objects following
 >    the common header MUST be carried in a fixed order, depending on
 >    message type.  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).

Since the ordering of objects is a MUST, a compliant implement does
not need to cope with receiving messages with objects in a different
order (though Postel's Law suggests it would be good if it did).
However, if it doesn't like it, what should it do? What error message
should it send? Possibly an Object Type Error with subcode 3 (Invalid
Object Type) would be reasonable.

 >    Network-Layer-Information.  If the message exchange relates to setup
 >    of a new messaging association, which MUST be carried out in D-mode,

This phrase is possibly ambiguous. In particular, the Confirm must be
carried over the MA, which isn't D-mode. It probably ought to be made
clearer that it is the Response that must be sent in D-mode in this
scenario.

 >    MA-Hello: This message MUST be sent only in C-mode.  It contains the
 >    common header, with a NSLPID of zero, and a message identifier, the
 >    Hello-ID.  It always indicates that a node wishes to keep a messaging
 >    association open, and if sent with R=0 and null Hello-ID this is its

suggested reword:
"null Hello-ID" -> "a Hello-ID of zero" or "zero Hello-ID"

 >    only function.  A node MAY also invoke a diagnostic request/reply
 >    exchange by setting R=1 and providing a non-zero Hello-ID; if this
 >    case, the peer MUST send another MA-Hello back along the messaging
 >    association echoing the same Hello-ID and with R=0.  Use of this
 >    diagnostic is entirely at the discretion of the initiating node.

By "initiating node" do you mean the node sending the MA-Hello that
requests a response?

 > 5.2.1.  The Common Header

 >    Note that in D-mode Section 5.3, there is a 32-bit magic number

suggested comma:
"D-mode Section 5.3," -> "D-mode, Section 5.3,"

 > 5.2.2.  TLV Objects
 >
 >    All data following the common header is encoded as a sequence of
 >    type-length-value objects.  Currently, each object can occur at most

Why "Currently"? Is there a particular extensibility issue being
hinted at here? (Should it be made more explicit?)

 >       The interface-address must be routable, i.e. it MUST be usable as
 >       a destination IP address for packets to be sent back to the node
 >       generating the signalling message, whether in D-mode or C-mode.
 >       If this object is carried in a message with the source addressing
 >       mode flag S=1, the interface-address MUST match the source address
 >       used in the IP encapsulation, to assist in legacy NAT detection
 >       (Section 7.2.1).  If this object is carried in a Query or Confirm,
 >       the interface-address MUST specifically be set to an address bound
 >       to the interface associated with the MRI, to allow its use in

suggest:
"to the interface" -> "to an interface"
The subsequent text suggests how to pick a suitable interface - which
means there is (likely to be) more than one to choose from.

 >    GIST-Error-Data:  This contains all the information to report the
 >       cause and context of an error.

"all the information": _all_ sounds a bit strong to me

 > 5.3.2.3.  Upper Layer Encapsulation and Overall Interception
 >           Requirements

 >    packets intercepted within the networ which does not match both the

"networ" -> "network"

 > 5.3.2.4.  IP Option Processing
 >
 >    For both IPv4 and IPv6, for Q-mode packets with IP options allowed by
 >    the above requirements, IP options processing is intended to be
 >    carried out independently of GIST processing.  Note that for the
 >    options allowed by the above rules, the options semantics are
 >    independent of the payload: UDP payload modifications are not
 >    prevented by the options and do not affect the options content, and
 >    conversely the presence of the options does not affect the UDP
 >    payload.

Some of the "options" should be possesive "options'"

 >    On packets originated by GIST, IP options MAY be added according to
 >    node-local policies on outgoing IP data.  On packets forwarded by
 >    GIST without NSLP processing, IP options MUST be processed as for a
 >    normally forwarded IP packet.  On packets locally delivered to the
 >    NSLP, the IP options MAY be passed to the NSLP and equivalent options
 >    used on subsequently generated outgoing Q-mode packets.  In this
 >    case, routing related options on SHOULD be processed identically as
 >    they would be for a normally forwarded IP packet.

The last sentence doesn't make sense (i.e. not English).

 > 5.5.  Message Type/Encapsulation Relationships

 >    specification.  If a message arrives with an invalid encapsulation
 >    (e.g. a Query arrives over a messaging association), this MUST be
 >    rejected with an "Incorrect Encapsulation" error message
 >    (Appendix A.4.4.3).

This probably needs to be made clearer, particularly with the
reduction in differences between Q/D-modes. This relates in part to
issue 183, which notes that a receiver might not be able to tell
whether something was Q or D mode encapsulated. In particular, if a
receiver receives a Query and believes it is D-mode, not Q-mode, that
probably shouldn't be an error, particularly with the 5.3.2.1 and
Appendix C discussion on leaving off RAOs.

 > 5.7.1.  Overview

 >    A Query requesting association setup always contains a Stack-Proposal

suggested reword:
"requesting association" -> "requesting messaging association"

 >    and Stack-Configuration-Data object.  The Stack-Proposal MUST only
 >    include protocol configurations that are suitable for the transfer
 >    attributes of the messages that the Querying node wishes use the

suggested reword:
"wishes use" -> "wishes to use"

 >    o  The re-used messaging association MUST have equivalent or better
 >       transport and security characteristics as at least one of the
 >       protocol configurations that was offered in the Query.

I found it difficult to understand these bullets.

In the first one, changing "all of the options" to "any of the
options" would probably work for me.

For the second, is it really just saying "you MUST pick one of the
options from the Query"?

 > 5.7.3.  Protocol Definition: Transport Layer Security

 >    GIST nodes MAY negotiate other TLS ciphersuites.  In some cases, the
 >    negotiation of alternative ciphersuites is used to trigger
 >    alternative authentication procedures, such as the use of pre-shared
 >    keys [33].  The use of other authentication procedures may require
 >    additional specification work to define how they can be used as part
 >    of TLS within the GIST framework, and may or may not require the
 >    definition of additional MA-Protocol-IDs.

Following on from the previous paragraph, I read this as saying that
PSK was not covered in this document. However, 5.7.3.1 does discuss
use of identities in PSK.

 > 5.8.1.3.  Upstream Q-mode Encapsulation

 >    This section defines an upstream Q-mode encapsulation and validation
 >    checks for when it can be used.  The functionality to generate
 >    upstream Queries is OPTIONAL, but if received they MUST be processed
 >    in the normal way.  No special functionality is needed for this.

Although it says "in the normal way", there are some additional checks
(TTL) on upstream Queries.

 >    o  The DiffServ codepoint and (for IPv6) flow label MAY be set to
 >       match the values from the MRI as in the downstream case, and the
 >       UDP port selection is also the same.

Why "MAY"? It is "SHOULD" in the downstream direction.

 > 5.8.2.2.  Downstream Q-mode Encapsulation

 >    o  By default, the IP source address is the source address, again
 >       from the MRI (S=0).  However, the use of the signalling source
 >       address (S=1) is allowed as in the case of the path-coupled MRM.

suggested reword:
remove ", again"

 > 6.  Formal Protocol Specification

 >    4.  Messaging associations have their own lifecycle, represented by
 >        MA-SM, from when they are first created (in an incomplete state,

"by MA-SIM" -> "by an MA-SM"

 > 6.1.  Node Processing

 >    cause the creation of other state machines.  The only events that are
 >    processed by this state machine are incoming GIST messages (Query/
 >    Response/Confirm/Data) and API requests to send data; no other events
 >    are possible.

There are also some er_ events from receiving Error messages.

 >    Rle 5 (tg_NSLPData):

"Rle 5" -> "Rule 5"

 > 6.2.  Query Node Processing

 >    state, in which timeout-based retransmissions are handled.  Data
 >    messages (rx_Data events) should not occur in this state; if they do,
 >    this may indicate a lost Response and a node MAY also retransmit a
 >    Query for this reason.

suggested reword:
"MAY also retransmit" -> "MAY retransmit"

 > 6.3.  Responder Node Processing

 >    Rule 10:
 >   // can happen e.g. a retransmitted Response causes a duplicate Confirm
 >   silently ignore

Comment should be indented by one character.

 > 6.4.  Messaging Association Processing

 >    Rule 2:
 >    pass message to Node-SM
 >    if the NoHello timer was running, stop it

In some cases, shouldn't the message be passed to a R-SM (e.g. a
Confirm) or a Q-SM (e.g. a Response when reusing an MA) instead?

 > 7.1.2.  Route Change Detection Mechanisms

 >    GIST Probing:  According to the specification, each GIST node MUST
 >       periodically repeat the discovery (Query/Response) operation.
 >       Values for the probe frequency are discussed in Section 4.4.4.
 >       The querying node will discover the route change by a modification
 >       in the Network-Layer-Information in the Response.  The period can
 >       be negotiated independently for each GIST hop, so nodes that have
 >       access to the other techniques listed above MAY use long periods
 >       for the probing operation.

suggested reword:
"for the probing operation." -> "between probes."

 > 7.1.3.  GIST Behaviour Supporting Re-Routing

 >    routing state is considered Bad until the machine first enters the

suggested reword:
"the machine" -> "the state machine"

 > 7.1.4.  Load Splitting and Route Flapping

 >    statement that an SII handle no longer lies on the path.  Both can be

"SII handle" -> "SII-Handle"
(to follow standard form elsewhere)

 > 7.2.2.  GIST-aware NAT Traversal

 >    the contents of the MRI.  This makes the assumption that NATs only
 >    rewrite the header fields included in this payload, and not other

suggested reword:
"this payload" -> "the MRI"

 > 7.2.3.  Message Processing Rules

 >    A NAT will intercept D-mode messages with the normal encapsulation
 >    containing such echoed NAT-Traversal objects.  The NAT processing is
 >    a subset of the processing for the Q-mode encapsulated case:

I assume this applies to (most commonly) Responses, and also Data
messages. Could this be made clearer in some way?

 > 7.4.  IPv4-IPv6 Transition and Interworking

 >       mismatching versions MUST be rejected with a "MRI Validation
 >       Failure" error message (Appendix A.4.4.12) with subcode 1 ("IP

'a "MRI Validation' -> 'an "MRI Validation'

 > 8.6.  Security Protocol Selection Policy

 >    1.  The Response does not depend on the Stack-Proposal in the Query
 >        (see Section 5.7.1).  Therefore, tampering with the Query has no
 >        effect on the resulting messaging association configuration.

Is this still true when the responding node picks to reuse an existing
MA?

 > 9.  IANA Considerations

 >    NSLP Identifiers:  Each signalling application requires the
 >       assignment of one of more NSLPIDs.  The following NSLPID is

"of one of more" -> "of one or more"

 >       of GIST operation.  If the new MA-Protocol-ID can be used in
 >       conjunction with existing ones (for example, a new transport
 >       protocol option which could be used with Transport Layer

removing the word "option" would have made this clearer for me

 > A.1.  The GIST Common Header

 >    The rules governing the use of the R-flag depend on the GIST message
 >    type.  It MUST always be set (R=1) in Query messages, since these
 >    always elicit a Response, and never in Confirm, Data or Error
 >    messages.  It MAY be set in an MA-Hello; if set, another MA-Hello
 >    MUST be sent in reply.

Does the MA-Hello in reply have to have R=0?

 > A.2.1.  Object Extensibility

 >    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").
 >
 >    These extensibility rules define only the processing within the GIST
 >    layer.  There is no requirement on GIST implementations to support an
 >    extensible service interface to signalling applications, so
 >    unrecognised objects with AB=01 or AB=10 do not need to be indicated
 >    to NSLPs.  If a new GIST object is defined which requires such an
 >    interaction, it should be specified with AB=11.

I don't understand the last sentence (given the previous paragraph).

 > A.3.1.1.  Path-Coupled MRM

 >    T flag:  T=1 means that DiffServ field (DS-field) is significant.

"that DiffServ" -> "that the DiffServ"

 > A.4.4.1.  Common Header Parse Error

 >    0: Unknown Version:  The GIST version is unknown.  The (highest)
 >       supported version supported by the node can be inferred from the
 >       Common Header of the Error message itself.

I believe this error code relies on some assumptions about possible
'upgrades' of GIST. In particular, in order to avoid error storms
(from sending errors in response to errors) either:
- common header needs to remain mostly unchanged (in particular the
message type field)
- implementations of GIST version N, need to understand the common
header of GIST version N-1

 > A.4.4.10.  Object Value Error

Should there be a diagnostic error subcode for the situation where the
stack proposal in the confirm doesn't match that in the response?

 > B.4.  NetworkNotification

 >    NSLPID:  An identifier indicating which NSLP this is message is for.

"this is message" -> "this message"

 > Appendix C.  Deployment Issues with Router Alert Options

 >    function.  It is always possible for middleboxes to block specific
 >    traffic types; by using a normal encapsulation for Q-mode traffic at

What does "normal" mean?

 >    The IPv4 RAO is defined by [3], which defines the RAO format with a
 >    2-byte value field; however, only one value (zero) is defined and
 >    there is no IANA registry for further allocations.  It states that
 >    unknown values should be ignored (i.e. the packets forwarded as
 >    normal IP traffic); however, it has also been reported that some
 >    existing implementations simply ignore the RAO value completely (i.e.
 >    process any packet with an RAO as though the option value was zero).

Linux has a similar but slightly different problem when using the
"router alert" sockopt. In the IPv4 case it doesn't allow an
application to express 'interest' in a particular RAO value. However,
it is also hard-coded to only intercept packets with an RAO value of
zero.

 > Appendix D.  Example Routing State Table and Handshake

 >     -------------------------- Query ---------------------------->
 >     IP(Src=IP#A; Dst=IP#E; RAO for NSLP2); UDP(Src=6789; Dst=GIST)
 >     Q-mode magic number (0x4e04 bda5)
 >     GIST(Header(Type=Query; NSLPID=NSLP2; R=1; S=0)

In this (and the rest of this example), is it intended to replace
"Dst=GIST" with the actual port number once allocated?
Also, should the state of the "E" flag in the common header be shown?

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis