Re: Packet format in ENRP

Dear all,

I think aligning the bits through all ENRP (or ASAP) message is not
the right way. It restricts us to 8 bits per protocol, not 8 bits
per message and is not that simple to do. So I think it is not worth
the effort we have to do.

Nevertheless I suggest to use the rightmost bit in the
PEER_NAME_TABLE_RESPONSE and PEER_LIST_RESPONSE message as
the 'reject bit'. This cost nothing.

Regarding putting these changes in an ID: I think it is easy to
do and we have a document where you can look up the current
state of the discussion. If not some people may just forget it
while working on the next revision. From the experience with
earlier IETF work done, it was quite helpful to get the ethereal
dissectors (in the CVS) up to the current ID status. So I committed
the changes as soon as the IDd where published. But it is just
the way I handled that...

As said, I'm volunteering to do the simple editorial work...

Best regards
Michael

On Jul 8, 2004, at 5:14 PM, Silverton Aron-C1710C wrote:

> I think that the concept of a mask should apply to what bit you are 
> trying to read.  In one case, it's the 'reply required' bit and in the 
> other it is the 'reject' bit, so these are really two different 
> things.  A single mask should definitely apply to the PEER_NAME_TABLE 
> and PEER_NAME_TABLE_RESPONSE since it is the same flag.  Now I am not 
> so sure about the PEER_PRESENCE message since it is really something 
> different.
>
> My question is, does it makes sense to abandon bits in one message 
> because they are used in another?  Or put another way, are the flags 
> meant to be global across all ENRP messages, or contextual based on 
> the specific message?
>
> Aron
>
> Michael Tuexen <> 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
>>>
>>
>>
>> _______________________________________________
>> rserpool mailing list
>> [email protected] https://www1.ietf.org/mailman/listinfo/rserpool
>