Re: [Gen-art] Gen-ART review of draft-ietf-rserpool-common-param-16.txt

[Michael Tuexen <[e-mail]>]

Hi Suresh,

comments in-line.

Best regards
Michael

On Apr 15, 2008, at 10:53 PM, Suresh Krishnan wrote:

> I am the assigned Gen-ART reviewer for
> draft-ietf-rserpool-common-param-16.txt
>
> For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> 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?
The ID says:
The unrecognized parameter TLV is included as cause specific  
information.

This means 'the complete parameter. I've changed it to

The complete unrecognized parameter TLV is included as cause specific  
information.

>
> - 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?
This question does not make sense. The communication is end-to-end, so  
there are no nodes on the path.
>
>
> * 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.
This documents does not request any message type IDs. But IANA does  
not handle the upper bit
stuff. It is up to the requester of a message type or parameter type  
to specify the upper two
bits. That is why we request specific values to be assigned from IANA.

This is the same way as we handle it in SCTP.
>
>
> 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.
>
Good catch. Done.
>
> * 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.
This comes from a table 'RSerPool Policy Types' which is define in  
draft-ietf-rserpool-policies-09.txt.

I've added a reference here.
>
>
> * 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
Hmmm. This is how we show all the packets... The padding is there. Why  
no show it?
To make things clearer I have also added padding in section 3. I hope  
this clearyfies things.
>
>
> Editorial
> =========
>
> * Section 3.12 ENRP is misspelled as ENPR.
Fixed
>
A new version of the ID has been submitted which addresses the  
comments as
described above.
>
> Cheers
> Suresh
>
>

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art