Document: draft-ietf-rserpool-common-param-16.txt
Reviewer: Suresh Krishnan [suresh.krishnan@ericsson.com]
Review Date: 4/15/2008
IETF LC date: 14 Apr 2008

Summary: This draft is on the right track but there are a few issues that need to be fixed.

Major
=====

* The usage of the Operational Error parameter is not very well specified. Let's say I have an unrecognized parameter of type 0xdead.
- What is the actual content of the Unrecognized Parameter cause? Is it just the type code or is it the complete parameter?
- When multiple nodes along the path do not recognize a given parameter (say 0xdead - two MSBs are 11) will they each add an Unknown parameter error cause for the same parameter?

* IANA considerations

The semantics of the message type field described in this document are completely lost since there is no direction to IANA. If you look at the enrp document for example, it requests message types from IANA, but the IANA registry will not contain the semantics about the first two bits.

Minor
=====

* Section 3

"The value of 65535 is reserved for IETF-defined extensions"

This is not shown in the initial allocation request for the IANA. Please fix this.

* Section 3.9

What is the namespace that the "Policy Type" comes out of? I could not see a definition of this namespace anywhere. e.g. What does the value 3 mean in this field? This needs to be clarified.

* Section 3.15

PE Checksum parameter explicitly shows the padding while the other parameters do not. Please remove the explicit padding from this. I do realize this is the only parameter whose parameter value is not a multiple of 4 octets long

Editorial
=========

* Section 3.12 ENRP is misspelled as ENPR.