Subject: Re: [NSIS] Last Call: 'GIST: General Internet Signaling Transport'to Proposed Standard (draft-ietf-nsis-ntlp)

From: Christian Dickmann <[email-masked]>
Date: Thu, 10 Aug 2006 10:57:41 +0200

Hi,

I did a brief review of the GIST draft and here are my comments:

Issue 1) In Figure 11 of Appendix C the GIST Confirm has no Stack-
Configuration-Data object included. However, section 5.1 says: "The first
   message on an association MUST also repeat the Stack-Configuration-
   Data from the original Query in an abbreviated form, just containing
   the MA-Hold-Time."
As the example in Figure 11 builds a new MA, the SCD should be contained
in the Confirm. In addition, the MA-Hold-Time is not listed in the Query-SCD in
Figure 11. It would make sense to include it, to show the difference between
the full and abbreviated form of the SCD.

Issue 2) Section 5.3.2 defines that a Q-mode encapsulated message has to contain
a RAO. In contrast, a lot of other encapsulation details are part of the definition
of the Message-Routing-Method, e.g. section 5.8.1.2 for downstream Q-mode encapsulation
for path-coupled MRM. Moving the RAO decision to the MRM definition seems reasonable
to me, as that would allow a wider range of MRMs, but not change the semantics of the
current specification.

For example, one could define a MRM which build the interception of messages on 
a specific port number. Such a MRM should NOT contain a RAO. But such a MRM would
currently require changing the GIST specification instead of just defining a MRM.

Issue 3) In section 5.2.1 "The Common Header" the GIST draft defines, that the current
GIST version number is 1. However, this is not listed in the IANA Considerations. As far
as I can see, the IANA Considerations do not even cover how future versions of GIST 
can be defined. I am not sure, but shouldn't this be covered?

Issue 4) In Section 5.1 DATA messages are defined without the possibility to add 
a NAT-Traversal-Object (NTO). While this is reasonable for normal D-Mode or C-Mode 
DATA messages, I think Q-mode encapsulated DATA messages (those DATA messages, which
are used in the stateless GIST operation) should be translated in NATs and a 
NTO should be added. 

Issue 5) I am still confused by the D-Flag of the Loose-End-MRM (see other mail
on the mailing list). Some additional thoughts: Section A.3.1.2 "Loose-End MRM" defines:
"D flag: The direction flag.  The only valid value is D=0 (see Section 5.8.2)."
So what does section 5.8.2 say? It says, that only downstream Q-mode encapsulation
is defined for LE-MRM (and NOT upstream Q-mode encapsulation like in the PC-MRM case).
However, this only refers to Q-mode encapsulation and not to the normal D-Mode one,
right? Thus, I do not need an upstream Q-mode encapsulation to send a D-Mode message
upstream (like a RESPONSE). Therefore, I have no clue, why section 5.8.2 should
tell me, that the only possible value of the direction flag in LE-MRM is 0.

Regards,
Christian Dickmann

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 17 Aug 2006 14:06:23 +0100

hi christian,

please see inline.

> -----Original Message-----
> From: Christian Dickmann [mailto:[email-masked]] 
> Sent: 10 August 2006 09:58
> To: [email-masked]
> Cc: Hancock, Robert
> Subject: Re: [NSIS] Last Call: 'GIST: General Internet 
> Signaling Transport'to Proposed Standard (draft-ietf-nsis-ntlp)
> 
> 
> Hi,
> 

fair enough, this can be added to the example (as you suggest).
 
> currently require changing the GIST specification instead of 

i think this is a reasonable suggestion. we can modify the text
to place the responsibility for deciding to use the RAO in the
MRM definition, rather than making it instrinsic to Q-mode
encapsulation, and point at the extensibility document for more
details. (note that in the example you give, I would still say
an RAO is appropriate; if interception is based solely on port 
number, then routers have to inspect all packets up to the 
transport layer, which is what we are trying to avoid.)

further discussion about this at 
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue112
 
> can be defined. I am not sure, but shouldn't this be covered?

i don't think so - IANA doesn't allocate the version numbers.
(basically, i think the idea is that if you want IANA to provide
a codepoint management service you have to tell them exactly how
to; but if you don't, you don't tell them anything. anything not
explicitly delegated to IANA remains the responsibility of the
IETF.)

> are used in the stateless GIST operation) should be 

yep, right. actually, the text in 7.2 is already written this 
way. but then someone [ ;-) ] asked to include the NTO in 
the section 5.xx ABNF/text and i didn't do so consistently.

> tell me, that the only possible value of the direction flag 

see the separate answer on this.

cheers,

robert h.