Subject: RE: [Rserpool] Packet format in ENRP

From: Silverton Aron-C1710C <[email-masked]>
Date: Wed, 7 Jul 2004 15:40:43 -0500

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-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: Michael Tuexen <[email-masked]>
Date: Thu, 8 Jul 2004 15:38:08 +0200

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 08 Jul 2004 15:28:28 -0500

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

---

From: Peter Lei <[email-masked]>
Date: Thu, 08 Jul 2004 23:15:35 -0500

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