Subject: Re: [Rserpool] comments on draft-ietf-rserpool-enrp-02.txt

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 01 Apr 2002 20:49:11 +0200

--On Saturday, March 30, 2002 10:06 PM +0100 Michael Tuexen 
<[email-masked]> wrote:
>>>
>>>>
>>>> Why are the 2 highest order bits of the type not
>>>> specifically drawn in the packet layout above??
>>>
>>> Doing that may mislead people to think the 2 bits are not part of the
>>> type field.
>>
>> I disagree. The text also suggests they are not part of the
>> type. Also they are not used for the type of the message, but
>> for the action that a receiving entity is allowed to take upon
>> reception of a not recognized type.
> The first two bits ARE part of the type. Two type with different
> two high order bits ARE different.

The wording says it specifies 'an action' if the receiving side
does not understand the type. Then it would neither understand these
two 'action' bits.

--- Quote from draft ------
   The Parameter Types are encoded such that the highest-order two bits
   specify the action that must be taken if the processing endpoint does
   not recognize the Parameter Type.

   00 - Stop processing this ENRP message and discard it, do not process
        any further parameters within it.

   01 - Stop processing this ENRP message and discard it, do not process
        any further parameters within it, and report the unrecognized
        parameter in an 'Unrecognized Parameter Type' error.

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but report the
        unrecognized parameter in an 'Unrecognized Parameter Type'
	       error.
----------------------------

>>
>> Now I come with some weird case:
>> A message type of binary value 01000001 is received.
>> The recepient does not understand this type, but how is he
>> going to understand the '01' part that are the 2 highest
>> order bits??
> This is exactly the same as in SCTP and it is working fine. So I
> would suggest to do it the way it is described in the ID.

Sorry, like the type/value length issue, this is is no reasoning.
Others do it this way and there it is fine. Maybe it is broken
at the others specification, but they cannot fix it anymore. :-))

Harrie

Internet Management Consulting
tel: +39-3474932300 / +31-625357135
mailto: [email-masked]                   http://www.lisanza.net/  

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 01 Apr 2002 20:49:11 +0200

--- Quote from draft ------

Harrie