-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
1. Section 5.1.1, structure definition
The structure in the document is mangled, but should not this be better:
enum { (2^16-1) } DiagnosticExtensionRequestType;
struct {
DiagnosticExtensionRequestType type;
opaque diagnostic_extension_contents<0..2^32-1>;
} DiagnosticExtension; // the ";" was missing
struct {
uint64 expiration;
uint64 timestampInitiated;
uint64 dMFlags;
DiagnosticExtension diagnostic_extensions<0..2^32-1>; // the length is
already here.
} DiagnosticsRequest;
Also the authors should choose between the CamelCase convention
(timestampInitiated) or the underscore convention
(diagnostic_extension_contents) but not mix the two.
2. Section 5.1.1, first and second field definitions
This fields uses the NTP timestamp format, which is different from the format
used by RELOAD (milliseconds since the epoch). Is there really a need for
microseconds here?
3. Section 5.1.1, third field definition
Is the request really allowed to set all dMFlags to '1', and so requesting
diagnostics types that are not yet defined?
4. Section 5.1.3
I would add an additional diagnostic kind that provide the OS (or modify
SOFTWARE_VERSION to provide the OS), for the purpose of evaluating if an overlay
as enough OS diversity to handle a bug in a specific OS.
5. Section 5.1.3, MEMORY_FOOTPRINT
A "kilo byte" of 1024 bytes is called kibibyte.
6. Section 5.3.1: structure definition
The request type should be DiagnosticsRequest instead of DiagnosticRequest.
7. Section 5.4
This section should define the content of error_info for error codes 102 to 106
(probably UTF-8 text, but -base does not explicitly says what the default format
is for error_info, so it need to be explicitly defined in each extension).
For error code 101, why using a fixed-length text string, instead of a "opaque
suberror<0..32>"
8. Section 8.1
This section should define the name of the new IANA registry
9. Section 8.2
This section should define the name of the new IANA registry
Nits
- ----
- - Section 1
s/compliment/complement/
- - Section 3
s/from the overlay ./from the overlay./
- - Section 4.1
s/the RELOAD ping/the RELOAD Ping/
- - Section 4.3
s/-- one/- one/
- - Section 5.1
s/are defined. DiagnosticRequest/are defined, DiagnosticRequest/
- - Section 5.3
s/New Reqeust/New Request/
- - Section 5.1.1, first paragraph
s/Ping message or with/Ping message with/
- --
Marc Petit-Huguenin
Personal email: [email protected]
Professional email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk62tewACgkQ9RoMZyVa61e/3ACgqlLAmnDTLZGG78QU0kT8shzL
p0kAnjEhQ741c+07Gn5gAhY6j4j+FtGY
=i+f1
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
