Re: Packet format in ENRP

Michael,

I did send Randy the latest xml after my last update on ENRP. To be safe, you still probably 
want to double check that the version on the top of CVS matches the current I-D before doing 
editing.

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