Re: [ippm] WGLC for STAMP Extensions

[Greg Mirsky <[e-mail]>]

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:
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.

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
>