From: Randy Turner (rturner@amalfisystems.com)
Date: Fri Oct 17 2008 - 02:28:41 EDT
Hi All,
Just so we're clear, the software version numbers (major, minor, build
#, service pack #s) are
octets, but they would be encoded in "binary", so these values are
allowed to grow to very large numbers...
The major, minor, and build numbers can be 0 to 2^32 - 1 and the
service pack numbers can be 0 to 2^16 - 1.
There was an earlier question about version numbers "not fitting" into
these fields, but as described in the
existing NEA PA-TNC "Numeric Version" attribute type, they tried to
make sure to cover the worst case.
Best Regards,
Randy
On Oct 16, 2008, at 9:34 PM, William A Wagner wrote:
> 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 - 02:28:49 EDT