[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
- [NSIS] NATFW message format Matthias Friedrich
- Re: [NSIS] NATFW message format Martin Stiemerling