RE: Packet format in ENRP

Johnson Walter-CWJ002 <[email protected]>
Newsgroups gmane.ietf.rserpool
Message-ID <6F8DFFA2C996D711945800065BFC9E4A0CABD53D@il02exm11>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.