Re: Packet format in ENRP

I also agree w/Q and Michael on this... Trying to align the 8 bits
across all exisiting and possible future messages may impose a severe
limitation later.  I'd prefer that the flags be contextual based on
the specific messages, than global across the protocol.

Aligning them where possible does make sense though, such as the
"R"-bit in PEER_NAME_TABLE_RESPONSE and PEER_LIST_RESPONSE as suggested.

thanks,
--peter

> As to the several follow-up suggestions on further re-aligning the flag 
> bits, I am a little hesitant to support it (but I won't violently oppose 
> it either). We do not want to overdo it, since after all there is only 8 
> bits available and if one insists on using "one-bit-one-meaning" 
> arrangement, we will not be able to go very far before we have to 
> abandon the approach.
> 
> In coding, the differece is no more than:
> 
>  if(flag_field & 00001000) { ... }
> 
> vs.
> 
>  if(flag_field == 0x08) { ... }
> 
> regards,
> -Qiaobing
> 
> Michael Tuexen wrote:
> 
>> Aron,
>>
>> possibly we could update the ENRP ID before the IETF deadline. This
>> is still one week away. Qiaobing, if the .xml source is in Randalls
>> CVS, I can do the editing, if you want.
>>
>> I can also update the ethereal dissector and Thomas can update
>> the rsplib.
>>
>> Best regards
>> Michael
>>
>> On Jul 7, 2004, at 10:40 PM, Silverton Aron-C1710C wrote:
>>
>>> Michael,
>>>
>>> The rest of here at Motorola discussed your comments this morning and 
>>> we, too, agree on all accounts.  Do we need to wait for further 
>>> agreement, or should we proceed with updating our documentation and 
>>> implementations?
>>>
>>> Regards,
>>>
>>> Aron
>>>
>>> Qiaobing Xie <> wrote:
>>>
>>>> Michael,
>>>>
>>>> Michael Tuexen wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> while writing the ethereal dissector for ENRP I found some things I
>>>>> would like to change:
>>>>>
>>>>> Section 3.1
>>>>>
>>>>> The length field is shown as 'Message Length = 0xC' which
>>>>> is not correct because there can be some parameters.
>>>>
>>>>
>>>>
>>>> good catch.
>>>>
>>>>>
>>>>> Section 3.3
>>>>>
>>>>> Could we exchange the R and M bit? This would align the
>>>>> R bit position with the reject bit in a PEER_LIST_RESONSE message.
>>>>
>>>>
>>>>
>>>> I agree. Better alignment is always good :-)
>>>>
>>>>>
>>>>> Section 3.4
>>>>>
>>>>> To have a similar layout of the packets i would suggest to change it
>>>>> to:
>>>>>
>>>>>         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 = 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>>>>> Sender Server's ID                       |
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>>>>> Receiver Server's ID                      |
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>>>>> Update Action          |        (reserved)             |
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
>>>>> Pool handle                            :
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
>>>>> Pool Element                           :
>>>>>
>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>>
>>>>
>>>> Makes sense to me. I agree.
>>>>
>>>> regards,
>>>> -Qiaobing
>>>>
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>
>>>>> PS.: ethereal version 0.10.5 will support both ASAP and ENRP...
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rserpool mailing list
>>>>> [email protected] https://www1.ietf.org/mailman/listinfo/rserpool
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rserpool mailing list
>>>> [email protected] https://www1.ietf.org/mailman/listinfo/rserpool
>>>
>>>
>>>
>>
> 
> 
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>

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