RE: Packet format in ENRP

Michael is right. So how about the move the R flag to bit 12 for PEER_PRESENCE and maybe change R flag to X flag for reject to avoid confusion in PEER_NAME_TABLE_RESPONSE, PEER_LIST_RESPONSE and ASAP's REGISTRATION_RESPONSE with the R flag of PEER_PRESENCE. Resulting in the following:

PEER_PRESENCE  			0000R000
PEER_NAME_TABLE 			00000W00
PEER_NAME_TABLE_RESPONSE 	000000MX 
PEER_LIST_RESPONSE		0000000X 

REGISTRATION_RESPONSE		0000000X


Michael Tuexen <mailto:[email protected]> wrote:
> Dear all,
> 
> just one note:
> the R flag in the PEER_PRESENCE message means 'reply required' and in
> the PEER_NAME_TABLE_RESPONSE and PEER_LIST_RESPONSE it means
> 'reject'. So it is not just 'one bit'.  
> 
> 
> On Jul 8, 2004, at 12:12 AM, Johnson Walter-CWJ002 wrote:
> 
>> I agree with all the changes but would like to suggest another. Much
>> like Michael's suggestion in section 3.3 to align the R bit in
>> PEER_NAME_TABLE_RESPONSE with PEER_PRESENCE and PEER_LIST_RESPONSE.
>> How about the following for the 8 bit flag field. Define bit 15 to be
>> the R flag bit, bit 14 to be the M flag bit, and bit 13 to be W flag
>> bit as shown below the pertinent ENRP protocol messages. This would
>> allow a single mask at least until the time that more than 8 flags
>> were required. 
>> 
>> PEER_PRESENCE  			0000000R
>> PEER_NAME_TABLE 			00000W00
>> PEER_NAME_TABLE_RESPONSE 	000000MR (Change as suggested by Michael)
>> PEER_LIST_RESPONSE		0000000R 
>> 
>> This would also work for the ASAP protocol messages as currently
>> defined. 
>> 
>> REGISTRATION_RESPONSE		0000000R
>> 
>> Walter
>> 
>> 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