Guidance of generating token

[mcd500]

It would be good to have a recommendation of generating token in the draft at the section bellow.

  token: uint,

token : The value in the token parameter is used to match responses to requests. This is particularly useful when a TAM issues multiple concurrent requests to a TEEP Agent.

The way to generate the initial token in the TAM.
The estimate of length of token to make the implementation easier for resource constraint devices.

[dthaler]

Discussion of Issue #40 might affect this issue as well.

[mcd500]

This is example in RFC5280 generating Serial Number for x.509.

The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).  CAs MUST force the serialNumber to be a non-negative
   integer.
   Given the uniqueness requirements above, serial numbers can be
   expected to contain long integers.  Certificate users MUST be able to
   handle serialNumber values up to 20 octets.  Conforming CAs MUST NOT
   use serialNumber values longer than 20 octets.
   Note: Non-conforming CAs may issue certificates with serial numbers
   that are negative or zero.  Certificate users SHOULD be prepared to
   gracefully handle such certificates.

[mcd500]

Discussion is related to #83

[mcd500]

I made the PR #106 related to this issue.
It still do not have instruction of how to generate random value, but the length and when to change.

[dthaler]

Addressed in draft -05 but issue #83 is still open and covers remaining token discussion