[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FYI: NLSP comments...
All,
Here is a copy of the NLSP comments which I have submitted to ANSI.
Jim Zmuda
______________
Date: 4/20/93 2:55 PM
To: Dale Walters
From: Jim Zmuda
Subject: NLSP spec comments updated...
Dale,
Here are my comments on the latest NLSP DIS: (Mine is dated
November 29th, 1992.)
Jim Zmuda
______________________________________________________
Comment Number: 1
Comment Type: Major Editorial
Section: Figure 9.7 and section 13.4.2.1
Concern: The description of the content length field in section
13.4.2.1 states that this field is the length of the Unprotected Octet
string as well as everything up to, but not including the ICV. Figure
9.7 erroneously labels this field "Unprotected Length Indicator".
This implies that the field includes only the length of the Uprotected
Octet string. This is a direct contradiction to section 13.4.2.1.
Proposed Solution: Change the name of field in Figure 9.7 from
"Unprotected Length Indicator" to "content length field" to match the
text in section 13.4.2.1. Or in some manner reconcile the picture to
the words in section 13.4.2.1. (See also section 13.3.1, as it
indicates there is, in addition to the Protected Data Length Indicator,
an Unprotected Octet String Length field as well that follows it. This
is not reflected in the figure.)
______________________________________________________
Comment Number: 2
Comment Type: Major Technical
Section: Section 9.3
Concern: The NLSP specification as it now stands does not provide
any "word pad" field. "Word pad" may be used to align the
beginning of the data field on a convenient boundary, for example a
computer word. The CLNP prototocol specification, IS 8473
contains a "word pad" function (see IS 8473, clause 6.12 and 7.5.2)
that provides precisely this function. It is the responsibility of the
NLSP protocol to not degrade the service provided by the network
layer by not also supporting this service. Therefore, the NLSP
specification requires a "word pad" capability specifically to allow
the alignment of the first byte of the NLSP User Data field to be
adjusted.
Proposed Solution: Provide a "word pad" field expressly for the
purpose of supporting the alignment of the first byte of the NLSP
User Data field.
______________________________________________________
Comment Number: 3
Comment Type: Major Technical
Section: Section 9.3.2.2.1
Concern: The NLSP Userdata field as it now stands is a type-
length-value (TLV) encoded field. It is also capable of being placed
anywhere within the NLSP unprotected contents. A significant
simplification would result by using a simple field instead of a TLV
encoded field, and placing it at the end of the other parts of the
NLSP protected data. The justification for this is that it would
significantly simplify any operation on the Userdata field, in
particular it would make the computation of the word pad field
mentioned in comment 2 above much simpler.
Proposed Solution: Utilize a plain field for the NLSP Userdata and
place it at the end of the protected data. I.E., after the ICV pad.
This is, in effect, bringing back the former division of the NLSP
PDU into three parts: 1) Unprotected Header, 2) Protected Header,
and 3) Userdata, instead of the two part form it is in now: 1)
Unprotected Header, and 2) Protected Contents.
______________________________________________________
Comment Number: 4
Comment Type: Major Technical
Section: Section 9.3.1
Concern: The NLSP unprotected header as it now stands has the
Length Indicator field placed before the PDU type byte. A cleaner
separation of function would result from a format which places the
PDU type byte before the Length Indicator. In particular, it would
be conceivable to augment the NLSP specification with additional
PDU types which might require a completely different encoding
without conflicting with the current encodings if this change were
made.
Proposed Solution: Reverse the order of the Length Indicator and
the PDU Type Byte within the NLSP unprotected header..