Re: [ippm] Fwd: New Version Notification for draft-ietf-ippm-stamp-option-tlv-09.txt

[Greg Mirsky <[e-mail]>]

Hi Yali,
thank you for your questions. Please find my answers and notes below under
GIM>> tag.

Regards,
Greg

On Mon, Aug 24, 2020 at 7:51 PM wangyali <[e-mail]> wrote:

> Hi Greg and all,
>
>
>
> May I have some questions and comments about the STAMP TLV Type Registry?
>
>
>
> First, as shown in the Table 1, code points in the range 252-254 is
> allocated for Private Use. Does it mean each Vendor/Enterprise can just
> define three kinds of STAMP TLV? What’s your consideration about the three
> code points allocation for Vendor Private Use ?
>
GIM>> My understanding of Section 4.1 RFC 8126
<https://tools.ietf.org/html/rfc8126#section-4.1> is that Private code
points MUST NOT be used ouside of an isolated local network domain, e.g.,
lab network.

>
>
> Second, if the TLV Type or sub-TLV Type is Experimental, similarly to
> Private Use, does it need to fill the vendor’s SMI Private Enterprise Code
> in the first four octets of Value field? Please give some clarifications
> any expected restrictions on experimental scope. Such as said in [RFC8126],
> whether it’s acceptable to run experiments using those code points over the
> open Internet or whether such experiments should be confined to more closed
> environments.
>
GIM>> True, the Experimental code points are similar to the ones
designeted to Private Use, as explained in Section 4.2. I've followed the
discussion on MPLS WG list
<https://mailarchive.ietf.org/arch/browse/mpls/?gbt=1&index=ewEzqMkkwwOxdChj_NfF_G_CZKo>that
dealt with the issues related to allocation of TLV and sub-TLV code points.
I couldn't find the issue of the experimental scope being reflected in the
latest version of the draft
<https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/?include_text=1>.
Persnally, I don't think that we need to restrict the scope of using the
experimental type. What do you think?

>
>
> Best regards,
>
> Yali
>
>
>
>
>
> ---------- Forwarded message ---------
>
> From: <[e-mail]> <&lt;[e-mail]&gt;>
>
> Date: Fri, Aug 21, 2020 at 1:01 PM
>
> Subject: New Version Notification for
>
> draft-ietf-ippm-stamp-option-tlv-09.txt
>
> To: Richard Foote <[e-mail]> <&lt;[e-mail]&gt;>om>, Greg Mirsky <
>
> [e-mail]> <[e-mail]&gt;>gt;, Henrik Nydell <[e-mail]> <&lt;[e-mail]&gt;>om>, Adi Masputra <
>
> [e-mail]> <[e-mail]&gt;>gt;, Ernesto Ruffini <[e-mail]> <&lt;[e-mail]&gt;>rg>, Xiao Min <
>
> [e-mail]> <[e-mail]&gt;>
>
>
>
>
>
>
>
> A new version of I-D, draft-ietf-ippm-stamp-option-tlv-09.txt
>
> has been successfully submitted by Greg Mirsky and posted to the
>
> IETF repository.
>
>
>
> Name:           draft-ietf-ippm-stamp-option-tlv
>
> Revision:       09
>
> Title:          Simple Two-way Active Measurement Protocol Optional
>
> Extensions
>
> Document date:  2020-08-21
>
> Group:          ippm
>
> Pages:          32
>
> URL:
>
> https://www.ietf.org/internet-drafts/draft-ietf-ippm-stamp-option-tlv-09.txt
>
> Status:
>
> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
>
> Htmlized:
>
> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-09
>
> Htmlized:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-option-tlv
>
> Diff:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-option-tlv-09
>
>
>
> Abstract:
>
>    This document describes optional extensions to Simple Two-way Active
>
>    Measurement Protocol (STAMP) that enable measurement of performance
>
>    metrics.  The document also defines a STAMP Test Session Identifier
>
>    and thus updates RFC 8762.
>
>
>