Subject: RE: [Rserpool] Packet format in ENRP

From: Johnson Walter-CWJ002 <[email-masked]>
Date: Thu, 8 Jul 2004 09:44:32 -0500

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-masked]> 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-masked] https://www1.ietf.org/mailman/listinfo/rserpool
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> rserpool mailing list
>>> [email-masked] https://www1.ietf.org/mailman/listinfo/rserpool

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

---

From: Silverton Aron-C1710C <[email-masked]>
Date: Thu, 8 Jul 2004 10:07:07 -0500

No big deal if we make the deadline, I just wanted to see if this discussion qualified as consensus so that I could have our internal documents and implementation updated.  I don't mind if the IETF drafts lag behind.  This just happens to be a convenient time for us to change our stuff.

Aron

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