Re: [ippm] WGLC for STAMP Extensions

[Greg Mirsky <[e-mail]>]

Hi Yali,
thank you for your quick response and thoughtful consideration of the
proposal. Please find my notes in-line tagged GIM>>.

Regards,
Greg

On Wed, Jun 17, 2020 at 11:41 PM wangyali <[e-mail]> wrote:

> 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.
>
GIM>> Thank you for accepting the idea in general. I think that requiring
that implementation controls whether the Session-Sender stops or doesn't
stop the test session upon receipt of the zeroed SSID field in the
reflected packet is necessary and sufficient. As for the exact behavior of
the Session-Sender, if it was configured to continue running the test
session, I think that we can leave space for implementors to innovate
within bounds of RFC 8762 and this specification. I agree that sending the
base STAMP packet is one of the options. Perhaps it can be provided as an
example without the use of normative language. "If the test session is not
stopped, the Session-Sender, can, for example, send a base STAMP packet
[RFC8762]." What do you think?

>
>
> 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]> 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]] *On Behalf Of *Ian Swett
> *Sent:* Saturday, May 23, 2020 5:26 AM
> *To:* IETF IPPM WG ([e-mail]) <[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] with your reviews and comments.
>
> Thanks,
> Ian & Tommy
>
>