[NSIS] NATFW message format

Matthias Friedrich <matt@mafr.de> Thu, 11 May 2006 11:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9n5-00026C-PE; Thu, 11 May 2006 07:57:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9n4-000252-HO for nsis@ietf.org; Thu, 11 May 2006 07:57:10 -0400
Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9n2-0005HM-52 for nsis@ietf.org; Thu, 11 May 2006 07:57:10 -0400
Received: from [84.163.3.253] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Fe9mw1UGp-0000jh; Thu, 11 May 2006 13:57:02 +0200
Received: by alanis.mafr.de (Postfix, from userid 1000) id AF53C5E8476; Thu, 11 May 2006 13:56:45 +0200 (CEST)
Date: Thu, 11 May 2006 13:56:45 +0200
From: Matthias Friedrich <matt@mafr.de>
To: nsis@ietf.org
Message-ID: <20060511115645.GA22784@mafr.de>
Mail-Followup-To: nsis@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.11
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: [NSIS] NATFW message format
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org

Hi,

while reading section 4 (NATFW NSLP Message Components), I noticed the
following minor issues:

 * The order the objects may appear in a message is not specified.
   If there is no fixed order, it should be stated explicitly. It
   could also be noted that only one object of a type may appear
   in a message.

 * It would be nice to have preliminary object type IDs to make sure
   experimental implementations are compatible. The message types
   already have IDs.

 * The "Forward" treatment is never used in the draft. Is there a use
   case where it is necessary?

 * The NATFW_LT object is named "session lifetime", but sections
   4.3.[123] just use "lifetime".

 * The NATFW_INFO object has a 16 bit object type, while the common 
   object header only allows for 12 bits.

 * The NATFW_DTINFO_IPv4 object seems to have a variable length, judging
   from text and diagram, but the length is specified as 3 words.

 * The NATFW_TRACE's hop count seems to be unnecessary. The number of
   hops can be derived from the number of IP addresses in this object.

 * Is the NATFW_CREDENTIAL's length field really necessary? A concrete
   credential type could still decide to use these bits as a length
   field to support padding. For other credential types it might not
   be needed. If the credential data is a multiple of 32 bit, the
   leading 16 bit could be used as padding.

 * Would a version number in the message header make sense?


Thanks for reading,
	Matthias

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis