Re: [ippm] WGLC for STAMP Extensions

[wangyali <[e-mail]>]

Hi Greg,

Glad to receive your response. Please see inline <Yali>.

From: Greg Mirsky [mailto:[e-mail]]
Sent: Thursday, June 18, 2020 6:50 AM
To: wangyali <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [ippm] WGLC for STAMP Extensions

Hi Yali,
firstly, many thanks from all the authors for volunteering as the Shepherd for this document.
Secondly, I apologize for such a late proposal to refine the update to your question. You've asked:
1.      In the draft, I confused a sentence that said ‘The Session-Sender MUST NOT stop the session if it receives a zeroed  SSID field.’ If a STAMP Session-Reflector that does not support this specification and return the zeroed SSID field in the reflected STAMP test packet, the STAMP Session-Sender MUST stop the session. I assume there’s a edit error.
We've agreed to change s/MUST NOT/MUST/.
After more thoughts and discussions among the authors, we would ask you and the WG to consider the change that, in our view, will make the behavior of a Session-Sender in this scenario more flexible:

<Yali> In deed, it becomes more flexible in this scenario. I’d suggest to explicitly point out all of actions the Session-Sender should take when it does not stop the session, such as sending a base STAMP-Test packet [RFC8762], etc. Please take following Text into consideration.

OLD TEXT:
   The Session-Sender MUST stop the session if it receives a zeroed
   SSID field.
NEW TEXT:
   The Session-Sender MAY stop the session if it
   receives a zeroed SSID field.  An implementation of a Session-Sender
   MUST support control of its behavior in such a scenario.

<Yali> The Session-Sender MAY stop the session if it
   receives a zeroed SSID field. An implementation of a Session-Sender
   MUST support control of its behavior in such a scenario.
   If the session is not stopped, the Session-Sender MAY send a base STAMP-Test packet [RFC8762].

I greatly appreciate your comments, questions.

Regards,
Greg
On Mon, Jun 1, 2020 at 1:40 AM wangyali <[e-mail]<mailto:[e-mail]>> wrote:
Hi authors and IPPM,

I support its publication. But after reading, I have two questions and comments as follows:


1.       In the draft, I confused a sentence that said ‘The Session-Sender MUST NOT stop the session if it receives a zeroed  SSID field.’ If a STAMP Session-Reflector that does not support this specification and return the zeroed SSID field in the reflected STAMP test packet, the STAMP Session-Sender MUST stop the session. I assume there’s a edit error.



2.       Does the TLV field shown in figure 1 indicate that the STAMP Session-Sender test packet with TLV in unauthenticated mode can contains one or more TLVs defined in this draft? I suggest to give an illustration about the TLV field in the test packet and revise TLV field in figure 1 that is not very clear.

Best regards,
Yali



From: ippm [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Ian Swett
Sent: Saturday, May 23, 2020 5:26 AM
To: IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: [ippm] WGLC for STAMP Extensions

Hi IPPM,

At our virtual interim meeting, we decided draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts a two-week WGLC for this draft.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04

This last call will end on Monday, June 8th. Please reply to [e-mail]<mailto:[e-mail]> with your reviews and comments.

Thanks,
Ian & Tommy