Re: [ippm] WGLC for STAMP Extensions

[Greg Mirsky <[e-mail]>]

Hi Yali,
I wanted to point that TLVs may be enclosed, i.e., used as sub-,
sub-sub-TLV. If it came across in a confusing manner, I'm all open for
better wording.

Regards,
Greg

On Thu, Jun 11, 2020 at 11:26 PM wangyali <[e-mail]> wrote:

> Hi Greg,
>
>
>
> Glad to receive your reply. Just a minor question. Please see inline
> <Yali>.
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Friday, June 12, 2020 5:42 AM
> *To:* wangyali <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [ippm] WGLC for STAMP Extensions
>
>
>
> Hi Yali,
>
> my apologies for the delayed response. Please find my answers below tagged
> GIM>>. Attached, please find the updated working version and the diff. I
> hope that the proposed updates address your concerns.
>
>
>
> 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.
>
> GIM>> Great catch, thank you!
>
>
>
>
>
> 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.
>
> GIM>> You are absolutely correct, multiple TLVs can be used in the same
> test packet either sequentially or enclosed. I've added a new text in the
> first paragraph of Section 4:
>
> OLD TEXT:
>
>    Type-Length-Value (TLV) encoding scheme provides flexible extension
>
>    mechanism for optional informational elements.  TLV is an optional
>    field in the STAMP test packet.
>
> NEW TEXT:
>
>    Type-Length-Value (TLV) encoding scheme provides a flexible extension
>    mechanism for optional informational elements.  TLV is an optional
>    field in the STAMP test packet.  Multiple TLVs MAY be placed in the
>    STAMP test packet.  A TLV MAY be enclosed in a TLV.
>
>
>
> <Yali> what do you mean ‘A TLV MAY be enclosed in a TLV’?
>
>
>
> Also, I've updated captions for Figure 1 and Figure 2 to indicate that
> they present an example of an extended STAMP test packet.
>
>
>
> 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
>
>