Subject: [imss] FC-NSM comments from Bob Nixon and proposed resolution

From: [email-masked]
Date: Tue, 22 Feb 2005 17:00:27 -0800

Bob Nixon:  First OBJECT on page 16, t11NsRegPortIdentifier having
MAX-ACCESS
not-accessible seems counterintuitive (this may only reflect a weakness in
my intuition).

Keith McCloghrie: Regarding t11NsRegPortIdentifier, non-accessible is
correct -- my favorite
analogy is that it would be redundant if "the colour of the blue car"
were to be accessible :-).

--
Bob Nixon: In t11NsRegFc4Type on page 18 and again more explicitly in
 t11NsRegFc4Features on page 20, an object that is defined in FC-GS-4 as a
 sequence of 32-bit words is represented in this MIB as an OCTET STRING. The
 order of placement of word fragments into the OCTET STRING needs to be
 specified. (Some other objects e.g., IP addresses and textual names,
 formally have the same problem, but not in fact, since they have
universally
 understood representations as OCTET STRINGs.)

Keith McCloghrie: Regarding t11NsRegFc4Type & t11NsRegFc4Features, I have
changed their
text to better emphasize that FC-GS-4 is the authoritative definition
of the format, and to include the relevant section number in FC-GS-4.
For t11NsRegFc4Type, the value is a 32-byte (256 bit) value, one bit for
each TYPE.  For t11NsRegFc4Features, I discovered that the length was
wrong!!  I've now corrected it (to be 128-bytes), and even though many
of the words that were present in the DESCRIPTION were copied
more-or-less directly from the GS-4 spec, I've also tried to clarify
them.  I hope I've succeeded!!

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