From: William A Wagner (wamwagner@comcast.net)
Date: Fri Oct 17 2008 - 00:34:46 EDT
Yoshimura-san and list,
Thank you for your comments. The feedback from readers allows the Working
Group to improve the clarity of the specfication
Supplementing Randy's general observations, I will attempt to answer your
questions based upon the information in the document. I request that WG
members that see errors in my analysis please correct them, and perhaps take
this as an opportunity to make the spec a little better.
> Q1. Section 4.4 HCD Attribute Encoding
> C. VALUE FIELD is fixed size (4octet) or variable size ?
> 2. SUB-TLV FIELD is fixed size (8bit) or variable size ?
><WW>< SUB-TLV FIELD is of variable size. Section 4.4 describes the format
used to encode the HCD attributes, basically embedding a Sub-TVL field
specific to the attribute within the Value field of a fixed format TLV
structure. The size of the sub-TLV fields are identified with the
descriptions of the attributes formats in paragraphs 4.5, 4.6 and 4.7. The
lengths of the sub TLV fields vary significantly among attributes and are in
themselves variable for certain attributes.
> Q2. Section 4.6.4 HCD DOWNLOADABLE AP NAME SUB-TLV (Sub-Type = 7,
> Sub-Length =variable)
> 2.Downloadable Application Name (4 octets)
> We suppose the length of Downloadable Application Name should be
> variable.
><WW>< I agree that this is confusing. The length of the sub TLV is
indicated as variable, but the constituent parts are defined as of fixed
length. What are we missing here?
>
> Q3. Section 4.6.12 HCD CERTIFICATION STATE SUB-TLV (Sub-Type =
> 14, Sub-Length = 4octets)
>
> In wd-idsattributes10-20081013, Section 4.1 General Attribute
> Definitions
> HCD_Certification_State
> "Since it is being deferred to Phase 2 of the IDS definition process."
>
> This attribute is not yet defined clearly and being deferred to
> Phase2.
> Could you let us know when this attribute will be defined ?
><WW>< This depends upon the progress in phase 1, as well as the perceived
need for this attribute. I am not aware of a strong demand for it at this
time.
> Q4. 4.7.1 HCD CONFIGURATION STATE SUB-TLV (Sub-Type = 15, Sub-
> Length = 4octets)
> This attribute is not yet defined clearly.
> Could you let us know when this attribute will be defined ?
><WW>< As is indicated in the spec, this is a vendor specific value and will
not be defined in the standard. This could be a bit map indicating the value
of a group of settings or it could be derived by some complex algorithm.
However, it is necessary that a given value always refer to a given set of
configuration settings (considering the configuration elements included in
the attribute). The primary intent of the value is to indicate that some
setting has been changed, not necessarily to identify what the setting was
for or what the value was.
> Q5. 4.6.1 HCD FIRMWARE VERSION SUB-TLV (Sub-Type = 5, Sub-Length =
> 16 octets)
> 4.6.5 HCD DOWNLOADABLE AP VERSION SUB-TLV (Sub-Type = 8, Sub-Length
> = 20 octets)
> 4.6.9 HCD RESIDENT AP VERSION SUB-TLV (Sub-Type = 11, Sub-Length =
> 16 octets)
> The format of VERSION is defined as fixed format.
> 1. Major Version Number (4 octets)
> 2. Minor Version Number (4 octets)
> 3. Build Number (4 octets)
> 4. Service Pack, Major Number (2 octets)
> 5. Service Pack, Minor Number (2 octets)
>
> However, some firmware or applications version numbers may not fit
> to the specified format.
> In such case, is it possible to apply the following rules ?
> If the version number is longer than 16 octets, use only the first
> 16 octets.
> If the version number is shorter than 16 octets, the rest of data
> are filled with 0x00.
><WW>< Note the comment for each of the attributes you identify that "This
attribute MUST be included only if the HCD [FIRMWARE] String SUB-TLV is not
present.". My understanding is that, if the firmware has a name and complex
version identification, it can be entered in the HCD FIRMWARE VERSION STRING
SUB-TLV, DOWNLOADABLE AP NAME SUB-TLV or HCD RESIDENT AP NAME SUB-TLV
variable length strings. The specified fixed format for the version could be
used as an alternative. And to the extent that the manufacturer can identify
this firmware as he wishes, he could modify the version identification to
follow this format. But as Randy indicated, the version identification must
be unique to a given version of code.
Hope this helps.
Bill Wagner
-----Original Message-----
From: owner-ids@pwg.org [mailto:owner-ids@pwg.org] On Behalf Of Randy Turner
Sent: Thursday, October 16, 2008 1:44 AM
To: Tomonari Yoshimura
Cc: ids@pwg.org
Subject: Re: IDS> Revised HCD-NAP Binding Document Available
Hello Yoshimura-san and list,
Since the Microsoft SOH is one of two possible ways to carry
attributes (the other being the pure TNC/NEA protocol), it seems like
the IETF or TCG will have to provide
a mapping document to make sure that the two protocols are able to
convey the attributes (and their corresponding datatypes) in an
interoperable fashion. Which means
there may be a "mapping document" like the one the IDS is working on
that will be coming from "somewhere", possibly a separate document, or
an informational appendix
in one of the two transport documents (MS-SOH or NEA )
Also, since the NEA working group did not reach consensus on the HCD
CONFIGURATION STATE attribute, we will need to reserve a place for
this in our own PWG/IDS
extensible attribute list that we should be building. (These will
have to be under the PWG SMI tree)
On the question of version numbers, a vendor can choose whatever
method of version logic is required, just so it fits within the data
types specified. The only operational
requirement is that the "version logic" should allow a device to
UNIQUELY express software module version numbers, and that these
version numbers are UNIQUE-enough
to allow remediation - so the remediation system must understand the
same vendor-specific version logic.
Because of the unique-ness requirement, if you only use the first 16
octets of a version number, then these 16 octets MUST be unique across
all past and future software
releases. At least that's the only way I know to allow robust
remediation.
Best Regards,
Randy
On Oct 15, 2008, at 9:58 PM, Tomonari Yoshimura wrote:
> Dear PWG-IDS Members,
>
> We have read through "wd-ids-napsoh10-20081008.pdf" and
> would like to confirm the items listed below.
> Could you kindly let us know answers or comments on our questions ?
>
> Q1. Section 4.4 HCD Attribute Encoding
> C. VALUE FIELD is fixed size (4octet) or variable size ?
> 2. SUB-TLV FIELD is fixed size (8bit) or variable size ?
>
> Q2. Section 4.6.4 HCD DOWNLOADABLE AP NAME SUB-TLV (Sub-Type = 7,
> Sub-Length =variable)
> 2.Downloadable Application Name (4 octets)
> We suppose the length of Downloadable Application Name should be
> variable.
>
> Q3. Section 4.6.12 HCD CERTIFICATION STATE SUB-TLV (Sub-Type =
> 14, Sub-Length = 4octets)
>
> In wd-idsattributes10-20081013, Section 4.1 General Attribute
> Definitions
> HCD_Certification_State
> "Since it is being deferred to Phase 2 of the IDS definition process."
>
> This attribute is not yet defined clearly and being deferred to
> Phase2.
> Could you let us know when this attribute will be defined ?
>
> Q4. 4.7.1 HCD CONFIGURATION STATE SUB-TLV (Sub-Type = 15, Sub-
> Length = 4octets)
> This attribute is not yet defined clearly.
> Could you let us know when this attribute will be defined ?
>
> Q5. 4.6.1 HCD FIRMWARE VERSION SUB-TLV (Sub-Type = 5, Sub-Length =
> 16 octets)
> 4.6.5 HCD DOWNLOADABLE AP VERSION SUB-TLV (Sub-Type = 8, Sub-Length
> = 20 octets)
> 4.6.9 HCD RESIDENT AP VERSION SUB-TLV (Sub-Type = 11, Sub-Length =
> 16 octets)
> The format of VERSION is defined as fixed format.
> 1. Major Version Number (4 octets)
> 2. Minor Version Number (4 octets)
> 3. Build Number (4 octets)
> 4. Service Pack, Major Number (2 octets)
> 5. Service Pack, Minor Number (2 octets)
>
> However, some firmware or applications version numbers may not fit
> to the specified format.
> In such case, is it possible to apply the following rules ?
> If the version number is longer than 16 octets, use only the first
> 16 octets.
> If the version number is shorter than 16 octets, the rest of data
> are filled with 0x00.
>
> Thanks in Advance.
>
> ________________________________
>
> From: owner-ids@pwg.org [mailto:owner-ids@pwg.org] On Behalf Of
Ron.Bergman@ricoh-usa.com
> Sent: Thursday, October 09, 2008 2:26 AM
> To: ids@pwg.org
> Subject: IDS> Revised HCD-NAP Binding Document Available
>
>
>
> The latest version can be found at:
>
> ftp://ftp.pwg.org/pub/pwg/ids/wd/wd-ids-napsoh10-20081008.pdf (.doc)
>
> A version with the changes highlighted is also available at:
>
> ftp://ftp.pwg.org/pub/pwg/ids/wd/wd-ids-napsoh10-20081008-rev.pdf
>
> We will discuss the changes and open issues at the Face to Face
> meeting in Lexington.
>
> Items for discussion:
>
> 1. The Conformance section (5) needs work.
> 2. Joe Murdock will provide information regarding the required NAP
> protocols.
>
>
>
This archive was generated by hypermail 2.1.4 : Fri Oct 17 2008 - 00:36:24 EDT