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

From: Harrie Hazewinkel <[email-masked]>
Date: Sat, 30 Mar 2002 16:38:51 +0100

--On Friday, March 29, 2002 1:10 PM -0600 Qiaobing Xie 
<[email-masked]> wrote:
>>
>> 5)
>> -- 3.1 ENRP Parameter formats
>> Encoding seems not network efficient.
>> Also why does the parameter length include the
>> parameter type and the parameter length??
>> I suspect that while parsing or creating the
>> 'type-length-value' item the extra length of
>> 4 does not provide additional information
>> to an ENRP protocol entity.
>
> This is kind of a popular way of defining parameter length in many other
> IETF RFCs. We would like to keep it the same for consistence.

I don't believe this is an argument, because I have seen also
IETF RFCs which do NOT have that part included in the length.
So you are inconsistent with those where the only the data
is indicated. :-))

Again I suggest dropping the inclusion of the 4 bytes of the
type and length in the length-value. IMHO, it lowers CPU
cycles and that is not influenced by hardware or software.

>
>>
>> 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.

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??

Resulting the recipeint does not know that it needs to report the
unrecognized message in an 'Unrecognized Parameter Type'.

Therefore, I suggest

1) mentioning those bits in the drawing
or
2) move those bits into the message flag.

I even prefer 2) since you already do this for

3.2.1 PEER_PRESENCE message

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x1  |0|0|0|0|0|0|0|R|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's ID does not need to be included if the
    message is being multicasted.

    "Reply_required" (R) flag shall be set to '1' if response to this
    message is required, otherwise set to '0'.

The Reply required bit requires also an action upon receiving the
message type 0x1.

Harrie

Internet Management Consulting
tel: +39-3474932300 / +31-625357135
mailto: [email-masked]                  http://www.lisanza.net/
Key fingerprint = F232 4B68 2B89 3ED7 FF41  F892 BCC9 CE9C 2F6D 51D7   

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

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 30 Mar 2002 22:06:09 +0100

Harrie,

see my comments in-line.

Best regards
Michael

> cycles and that is not influenced by hardware or software.
In my opinion this is a matter of taste. Since SCTP and all the SIGTRAN
adaptation layers include the type/length field in the length field
I would like to have the RSerPool suite in tune with these protocols.
> 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.
> going to understand the '01' part that are the 2 highest
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.
> 3.2.1 PEER_PRESENCE message
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 30 Mar 2002 22:06:09 +0100

Harrie,

see my comments in-line.

Best regards
Michael