AD comments on draft-ietf-nsis-ntlp-14

Hi,

I am sorry for the long time this AD review has taken. I really liked to
read the document from first to last word before progressing it. I have
now done this and thinks the document is in pretty good shape. I would
appreciate an updated version as soon as we have resolved the questions.


1. Page 29:
"   2.  The signalling application does not wish to set up state with the
       Querying node and become its peer.  This includes the case where
       a node wishes to avoid taking part in the signalling for overload
       protection reasons.  GIST MUST propagate the Query, similar to
       the case described in Section 4.3.4.  No message is sent back to
       the Querying node.  The application MAY provide an updated NSLP
       payload for the same NSLPID, which will be used in the Query
       forwarded by GIST.  Note that if the node which finally processes
       the Query returns an Error message, this will be sent directly
       back to the originating node, bypassing any forwarders.  For
       these diagnostics to be meaningful, any GIST node forwarding a
       Query MUST NOT modify it except in the NSLP payload and GIST hop
       count; in particular, it MUST NOT modify any other GIST payloads
       or their order.  An implementation MAY choose to achieve this by
       retaining the original message, rather than reconstructing it
       from some parsed internal representation."

I can't quite understand "For
       these diagnostics to be meaningful, any GIST node forwarding a
       Query MUST NOT modify it except in the NSLP payload and GIST hop
       count; in particular, it MUST NOT modify any other GIST payloads
       or their order."

Why does a forwarding node may modify the NSLP payload? Can you please
explain this? GIST hop is clearly

2. Section 5.3.2.2:

"   The upper layer protocol MUST be UDP without intervening
   encapsulation layers.  Following the hop-by-hop option header, the IP
   header MUST NOT include any extension headers other than routing
   options or destination options, and for the last extension header
   MUST have a next-header field of UDP."

Here I must actually ask if this specification really can require that
other IP extensions not are used. This seem to have potential clashes
with other basic building blocks. So I would like to understand why the
WG thinks it is necessary to make these restrictions.

3. Section 5.3.3, page 59:

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

I think it should be made clear that the token bucket parameter for
bit-rate is "no larger than 5%" rather than suggesting that 5% is a
general good value.

4. Section 5.7.3.1:

"For
   example, *.example.com in the APD would match certificates for
   a.example.com, foo.example.com, *.example.com, etc., but would not
   match example.com.  Similarly, a certificate for *.example.com would
   be valid for APD identities of a.example.com, foo.example.com,
   *.example.com, etc., but not example.com."

Is it intentional to have two sentences saying the same thing, or am I
dense here. It looks very much like a repeat.

5. Section 9: NSLP ID

I actually wonder about the selection of IESG approval for new NSLP IDs.
 Isn't that kind of restricting? Sure, it can potentially be easier to
register than specification required. However, it does put load on the
IESG. It also assumes that the IESG will have enough clue in the future
to know what the correct way to handle a registration requests. Can
someone provide me with the WGs reasoning behind this policy?

6. Appendix A. I think the text about "reserved" and its meaning needs
to be moved from section A.2 to the front text for Appendix A. Otherwise
it is wrongly scoped and does not cover A.1 or any A.3...

7. Section A.1: There is no explicit mention of what values should be
listed in the version field for this spec. Earlier it says this is
Version 1 of GIST, but that could be encoded both a 0 and 1 in this
field based on previous protocols from IETF.

8. ID-nits warnings:

  == Unused Reference: '14' is defined on line 5231, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 2246 (ref.
     '15') (Obsoleted by RFC 4346)

  -- Obsolete informational reference (is this intentional?): RFC 2766 (ref.
     '18') (Obsoleted by RFC 4966)

  -- Obsolete informational reference (is this intentional?): RFC 2960 (ref.
     '19') (Obsoleted by RFC 4960)

I definitely like to know if the new versions are fine or not.


  == Outdated reference: A later version (-04) exists of
     draft-ietf-behave-turn-03

  == Outdated reference: A later version (-15) exists of
     draft-ietf-nsis-nslp-natfw-14

  == Outdated reference: A later version (-02) exists of
     draft-pashalidis-nsis-gist-legacynats-01

  == Outdated reference: A later version (-05) exists of
     draft-pashalidis-nsis-gimps-nattraversal-04

  == Outdated reference: A later version (-04) exists of
     draft-ietf-nsis-ntlp-statemachine-03

  == Outdated reference: A later version (-08) exists of
     draft-ietf-tcpm-tcpsecure-07

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------