Subject: [ippm] Comments for draft-ietf-ippm-twamp-reflect-octets-05

From: [email-masked]
Date: Mon, 26 Apr 2010 12:21:21 -0400

Hi Al
Here are some comments on the latest draft.

 <!--  /* Style Definitions */  p.MsoNormal, li.MsoNormal, div.MsoNormal 	{mso-style-parent:""; 	margin:0in; 	margin-bottom:.0001pt; 	mso-pagination:widow-orphan; 	font-size:12.0pt; 	font-family:"Times New Roman"; 	mso-fareast-font-family:"Times New Roman"; 	mso-bidi-language:HE;} @page Section1 	{size:8.5in 11.0in; 	margin:1.0in 1.25in 1.0in 1.25in; 	mso-header-margin:.5in; 	mso-footer-margin:.5in; 	mso-paper-source:0;} div.Section1 	{page:Section1;} -->   - It will be best to explicitly indicate that both the control and test protocols can reflect octets in an independent manner even if it is indirectly stated in the introduction.  - The definition for the “Server octets” field shall indicate where those bits should appear in the Packet Padding (to be reflected) field.  - The spec should state that a zero value in the “Server octets” field means the Server does not desire these octets to be reflected.  - The spec should state that a non-zero value in the “Server octets” field means the Server desires these octets to be reflected. The actual position of these octets in the padding octets of the test packets shall be clarified.  - A defintion for Client octets field should be provided and indicates that is the equal to Octets to be reflected field (from Request-TW-Session).   - The spec should indicate when the Client octets field shall appear in the Packet Padding (to be reflected) field. Based on the example provided, it looks like the usage of this field is optional and/or implementation-specific when reflecting octets in test packets. If so, please indicate it.  
Thank you

Regards
Steve Baillargeon

---

From: Al Morton <[email-masked]>
Date: Mon, 26 Apr 2010 12:23:46 -0400

Thanks Steve, these are good comments, and
we'll resolve them as you suggest in the next draft.
Al

At 12:21 PM 4/26/2010, [email-masked] wrote:
>Content-type: multipart/alternative;
>  boundary="Boundary_(ID_NEJL3a72RdguL2k8r4BKBg)"
>Content-language: en
>
>Hi Al
>- It will be best to explicitly indicate that both the control and 
>test protocols can reflect octets in an independent manner even if 
>it is indirectly stated in the introduction.
>
>- The definition for the "Server octets" field shall indicate where 
>those bits should appear in the Packet Padding (to be reflected) field.
>
>- The spec should state that a zero value in the "Server octets" 
>field means the Server does not desire these octets to be reflected.
>
>- The spec should state that a non-zero value in the "Server octets" 
>field means the Server desires these octets to be reflected. The 
>actual position of these octets in the padding octets of the test 
>packets shall be clarified.
>
>- A defintion for Client octets field should be provided and 
>indicates that is the equal to Octets to be reflected field (from 
>Request-TW-Session).
>
>- The spec should indicate when the Client octets field shall appear 
>in the Packet Padding (to be reflected) field. Based on the example 
>provided, it looks like the usage of this field is optional and/or 
>implementation-specific when reflecting octets in test packets. If 
>so, please indicate it.
>
>Thank you
>
>Regards
>Steve Baillargeon
>_______________________________________________
>ippm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ippm