Michael Tuexen | 5 Jul 19:20 2004
Picon

Packet format in ENRP

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.

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.

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                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Continue reading)

Michael Tuexen | 6 Jul 20:53 2004
Picon

draft-tuexen-rserpool-policies-00.txt

Dear all,

I just submitted a new ID, an individual submission
to the RSerPool WG regarding server pool policies.

The ID is also available from
http://www.sctp.de/internet-drafts.html

Best regards
Michael
Maureen.Stillman | 7 Jul 15:54 2004
Picon

Agenda for IETF #60

Please send any agenda items.  We are scheduled for Thursday afternoon in San Diego.

Thanks.

-- maureen
Qiaobing Xie | 7 Jul 21:28 2004

Re: Packet format in ENRP

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:
(Continue reading)

Silverton Aron-C1710C | 7 Jul 22:40 2004

RE: Packet format in ENRP

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
(Continue reading)

Johnson Walter-CWJ002 | 8 Jul 00:12 2004

RE: Packet format in ENRP

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
(Continue reading)

dreibh | 8 Jul 15:21 2004
Picon

RE: Packet format in ENRP

Zitat von Johnson Walter-CWJ002 <Walter.Johnson <at> motorola.com>:

> 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

This change is a good idea. I support this.

Best regards

Thomas Dreibholz

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Michael Tuexen | 8 Jul 15:36 2004
Picon

Re: Packet format in ENRP

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
>
(Continue reading)

Michael Tuexen | 8 Jul 15:38 2004
Picon

Re: Packet format in ENRP

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:
>>
(Continue reading)

Johnson Walter-CWJ002 | 8 Jul 16:44 2004

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:Michael.Tuexen <at> lurchi.franken.de> 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. 
(Continue reading)


Gmane