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

From: Rakesh Gandhi <[email-masked]>
Date: Sat, 4 Jul 2020 10:04:08 -0400

Many thanks Greg for the updates and discussions. Changes look good to me.
One minor comment on the text below, why only copy the "remainder" and not
the entire TLV?

"The Session-Reflector MUST copy the remainder of the
   extended STAMP test packet into the reflected packet. "

Thanks,
Rakesh

On Fri, Jul 3, 2020 at 3:40 PM Greg Mirsky <[email-masked]> wrote:

> Hi Rakesh,
> many thanks for pointing the issue out. I agree with you that an
> authentication failure can be signaled using a STAMP TLV flag. I've updated
> the section and below is the difference:
> OLD TEXT:
>    If HMAC
>    verification by the Session-Reflector fails, then an ICMP Parameter
>    Problem message MUST be generated (with consideration of limiting the
>    rate of error messages).  The Code value MUST be set to 0 and the
>    Pointer identifying HMAC Type.  Also, both Session-Sender and
>    Session-Reflector SHOULD log the notification that HMAC verification
>    of STAMP TLVs failed.  The packet that failed HMAC verification MUST
>    be dropped.
> NEW TEXT:
> If HMAC
>    verification by the Session-Reflector fails, then the Session-
>    Reflector MUST stop processing the received extended STAMP test
>    packet.  The Session-Reflector MUST copy the remainder of the
>    extended STAMP test packet into the reflected packet.  The Session-
>    Reflector MUST set the A flag copy of the HMAC TLV in the reflected
>    packet to 1 before transmitting the reflected test packet.  Also,
>    both Session-Sender and Session-Reflector SHOULD log the notification
>    that HMAC verification of STAMP TLVs failed.
>
> The A flag's definition reads as:
>    o  A - a one-bit flag.  A Session-Sender MUST set the A flag to 0
>       before transmitting an extended STAMP test packet.  A Session-
>       Reflector MUST set the A flag to 1 if the STAMP extensions have
>       failed HMAC verification (Section 4.8).
>
> Attached are the working copy (including changes addressing comments from
> SecDir and GenART reviewers) and the diff to -06 version.
>
> Comments, questions and suggestions are always welcome and greatly
> appreciated.
>
> Regards,
> Greg
>
> On Mon, Jun 29, 2020 at 2:56 PM Rakesh Gandhi <[email-masked]>
> wrote:
>
>> Thank you Greg for considering my comments. The changes look good to me.
>> I have one additional comment. Wonder if the following ICMP error (only
>> one remained) can also be addressed with an error flag.
>>   "If HMAC
>>    verification by the Session-Reflector fails, then an ICMP Parameter
>>    Problem message MUST be generated (with consideration of limiting the
>>    rate of error messages).  The Code value MUST be set to 0 and the
>>    Pointer identifying HMAC Type.
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>> On Mon, Jun 29, 2020 at 4:38 PM Greg Mirsky <[email-masked]>
>> wrote:
>>
>>> Hi Rakesh,
>>> thank you for the great discussion. We've followed your suggestion to
>>> extend the number of error flags in STAMP TLV. Attached is the updated
>>> working version of the draft and its diff to -06 version.
>>>
>>> Best regards,
>>> Greg
>>>
>>> On Mon, Jun 29, 2020 at 5:21 AM Rakesh Gandhi <[email-masked]>
>>> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> Many thanks for your reply. Please see comments inline with <RG>...
>>>>
>>>> On Fri, Jun 26, 2020 at 3:22 PM Greg Mirsky <[email-masked]>
>>>> wrote:
>>>>
>>>>> Hi Rakesh,
>>>>> thank you for your helpful comments. Please find my answers, notes
>>>>> in-line tagged GIM>>.
>>>>>
>>>>> Regards,
>>>>> Greg
>>>>>
>>>>> On Fri, Jun 26, 2020 at 9:41 AM Rakesh Gandhi <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Thanks Greg for the updates.
>>>>>> The update covers the case when the TLV is not recognized by the
>>>>>> reflector.
>>>>>> The other cases, such as (1) TLV is recognized but not supported,
>>>>>>
>>>>> GIM>> Do you see this as a different case from the Not recognized?
>>>>> What could be the difference between these two cases from the test
>>>>> operator's point of view?
>>>>>
>>>>
>>>> <RG> Unsupported means recognized but software doesn't support some or
>>>> all aspects of the TLV.
>>>>
>>>>
>>>>> GIM>> I've compared how Type and Length error handling specified in
>>>>> Section 4. In the latter case processing of the extensions stopped. Should
>>>>> the same be done in the former case? Or a system might try to process the
>>>>> next TLV? And if the latter, what normative language to use - MAY, SHOULD
>>>>> or MUST? I think that continuing processing is a good approach but that be
>>>>> left as optional, i.e., use MAY. What do you think?
>>>>>
>>>>
>>>> <RG> Perhaps - SHOULD stop processing and return error? Not sure why
>>>> continue if there is a fatal error in length processing.
>>>>
>>>>
>>>>>
>>>>> (2) TLV has an error such as wrong length or value, are not covered by
>>>>>> the draft.
>>>>>>
>>>>> GIM>> I think that we have covered this case in the following part of
>>>>> Section 4:
>>>>>       fixed-size TLVs are verified that the Length field value equals
>>>>>       the value defined for the particular type.  If the values are not
>>>>>       equal, the processing of extension TLVs MUST be stopped.  Also,
>>>>> if
>>>>>       the system is the Session-Reflector, it MUST send the ICMP
>>>>>       Parameter Problem message with Code set to 0 and the Pointer
>>>>>       referring to the Length field of the TLV.
>>>>>
>>>>
>>>> <RG> Why use a different protocol (ICMP) for error handling while it
>>>> can be done within the same protocol (STAMP)? Makes it easier to implement
>>>> in the same protocol.
>>>>
>>>>
>>>>> This was part of the specification and, as I understand, the WG agreed
>>>>> to the procedure.
>>>>>
>>>>>> Wonder if a few bits can be reserved in the Type field to help with
>>>>>> future extensions. Maybe 1K-2K Types are plenty.
>>>>>>
>>>>>
>>>> <RG> Any thoughts on this?
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>>
>>>>>
>>>>>> thanks,
>>>>>> Rakesh
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 25, 2020 at 5:10 PM Greg Mirsky <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Martin, Rakesh, et al.,
>>>>>>> I've taken Martin's idea and made changes in the working version of
>>>>>>> the draft (attached along with the diff). I think that it provides the
>>>>>>> "soft" handling for the Unrecognized TLV case we've been trying to put into
>>>>>>> the protocol. I agree with Rakesh, that the Error Code TLV can be useful
>>>>>>> for other cases. But  I think that that work might be deferred for the new
>>>>>>> document.
>>>>>>> Please share your comments, questions, and suggestions.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Greg
>>>>>>>
>>>>>>> On Tue, Jun 23, 2020 at 3:16 PM Rakesh Gandhi <
>>>>>>> [email-masked]> wrote:
>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>> It would work for Unrecognized TLV Type Error Code. We may still
>>>>>>>> need Error Code TLV for the other generic error codes that we may define in
>>>>>>>> future, e.g. invalid SSID.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Rakesh
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jun 23, 2020 at 5:41 PM Martin Duke <
>>>>>>>> [email-masked]> wrote:
>>>>>>>>
>>>>>>>>> Speaking as an individual, another way to go would be to use only
>>>>>>>>> 15 bits for the type and have the first bit be an error indicator.
>>>>>>>>>
>>>>>>>>> On Tue, Jun 23, 2020 at 2:34 PM Rakesh Gandhi <
>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Greg,
>>>>>>>>>> Not sure if the following option was considered, i.e. using the
>>>>>>>>>> Reserved field. Also, text could be flexible to say truncate it if a
>>>>>>>>>> symmetrical packet is required or there is MTU limitation else no need to
>>>>>>>>>> truncate.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> | Error Code Type               | Length = Unrecognized TLV Len |
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> | Code          |      Sub-Code | Unrecognized TLV Type         |
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ~ Value field from Received Unrecognized TLV Truncated by 4 Bytes
>>>>>>>>>> ~
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> | Error Code Type               | Length = Unrecognized TLV
>>>>>>>>>> Len+4 |
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> | Code          |      Sub-Code | Unrecognized TLV Type         |
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ~ Value field from Received Unrecognized TLV                    ~
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Rakesh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 23, 2020 at 5:08 PM Greg Mirsky <
>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Rakesh,
>>>>>>>>>>> you're right, to keep packets symmetrical we must leave not four
>>>>>>>>>>> but eight octets out. Since several TLVs defined in the draft, e.g.,
>>>>>>>>>>> Timestamp Information, CoS, are only 8 octets long, that is a problem I've
>>>>>>>>>>> missed. Thank you for pointing that out. One option, brute-force approach -
>>>>>>>>>>> make TLVs at least 12 octets long. Any other suggestions?
>>>>>>>>>>> The requirement is to ensure that test packets are symmetrical.
>>>>>>>>>>> If we decide that is not required, then the text can be modified
>>>>>>>>>>> accordingly.
>>>>>>>>>>> As for your second question, as defined in Section 4, a
>>>>>>>>>>> Session-Reflector will continue parsing the received test packet and, as
>>>>>>>>>>> the result, multiple Error Code TLVs might be added into the reflected
>>>>>>>>>>> packet.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Greg
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 23, 2020 at 1:51 PM Rakesh Gandhi <
>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks Greg.
>>>>>>>>>>>> I think I am missing something.
>>>>>>>>>>>> The Error code TLV adds 8 more bytes to the Unrecognized TLV (4
>>>>>>>>>>>> bytes for the "Code/Subcode/Reserved" part and 4 bytes for the
>>>>>>>>>>>> "Type/Length" part of the Unrecognized TLV.
>>>>>>>>>>>>
>>>>>>>>>>>> I also do not see the flexibility to return entire/truncated..
>>>>>>>>>>>> TLV. It says following with MUST:
>>>>>>>>>>>>
>>>>>>>>>>>> The Session-Reflector MUST set the Length
>>>>>>>>>>>>    field's value in the Error Code TLV equal to the Length
>>>>>>>>>>>> field of the
>>>>>>>>>>>>    problematic TLV in the received test packet.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also, if there are more than one Unrecognized TLV, will the
>>>>>>>>>>>> reflector add an Error code TLV for each of them?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 23, 2020 at 2:59 PM Greg Mirsky <
>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Rakesh,
>>>>>>>>>>>>> I agree and I think that the latest version allows for such
>>>>>>>>>>>>> flexibility:
>>>>>>>>>>>>>    A Session-Reflector that encountered a problem processing a
>>>>>>>>>>>>> TLV in
>>>>>>>>>>>>>    the Extended STAMP test packet SHOULD include the Error
>>>>>>>>>>>>> Code TLV in
>>>>>>>>>>>>>    the reflected test packet.  The Session-Reflector MUST set
>>>>>>>>>>>>> the Length
>>>>>>>>>>>>>    field's value in the Error Code TLV equal to the Length
>>>>>>>>>>>>> field of the
>>>>>>>>>>>>>    problematic TLV in the received test packet.  The handling
>>>>>>>>>>>>> of the
>>>>>>>>>>>>>    Received TLV field in the reflected packet depends on the
>>>>>>>>>>>>> Error Code
>>>>>>>>>>>>>    value.  This specification defines the Unrecognized Type as
>>>>>>>>>>>>> a new
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Error Code.  For the case of the Unrecognized Type, the
>>>>>>>>>>>>> Session-
>>>>>>>>>>>>>    Reflector:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    o  MUST set the Length field's value in Error Code equal to
>>>>>>>>>>>>> the
>>>>>>>>>>>>>       Length field's value in the received problematic TLV;
>>>>>>>>>>>>>
>>>>>>>>>>>>>    o  MUST copy the problematic TLV, starting from the Type
>>>>>>>>>>>>> field but
>>>>>>>>>>>>>       less four octets, into the Received TLV field.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As you see, handling of Length and Received TLV fields is
>>>>>>>>>>>>> defined based on an Error Code. For the case of the Unrecognized Type
>>>>>>>>>>>>> error, returning only the first four octets might be sufficient. To keep
>>>>>>>>>>>>> test packets symmetrical, I've proposed to use the received TLV. For other
>>>>>>>>>>>>> cases, we might define another mechanism to populate Length and Received
>>>>>>>>>>>>> TLV fields.
>>>>>>>>>>>>> Attached, please find the new working version of the draft and
>>>>>>>>>>>>> the diff to -06. Please review and share your comments.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think that to continue moving this document, we need
>>>>>>>>>>>>> guidance from WG Chairs and our AD.
>>>>>>>>>>>>> Dear Ian, Tommy, and Martin,
>>>>>>>>>>>>> please consider the discussion and share your thoughts on what
>>>>>>>>>>>>> should be done next.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jun 23, 2020 at 10:36 AM Rakesh Gandhi <
>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Greg,
>>>>>>>>>>>>>> The text could make it flexible to allow the return of the
>>>>>>>>>>>>>> full or truncated TLV.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, Jun 23, 2020 at 11:32 AM Greg Mirsky <
>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Rakesh,
>>>>>>>>>>>>>>> I think that there could be a case, though it might be a
>>>>>>>>>>>>>>> corner case when adding four octets per unrecognized TLV will make the
>>>>>>>>>>>>>>> reflected packet too big for MTU at hand. On the other hand, another error
>>>>>>>>>>>>>>> handling might handle the Received TLV field differently. I've updated the
>>>>>>>>>>>>>>> text to make it specific to the Unrecognized Type error:
>>>>>>>>>>>>>>>    A Session-Reflector that encountered a problem processing
>>>>>>>>>>>>>>> a TLV in
>>>>>>>>>>>>>>>    the Extended STAMP test packet SHOULD include the Error
>>>>>>>>>>>>>>> Code TLV in
>>>>>>>>>>>>>>>    the reflected test packet.  The Session-Reflector MUST
>>>>>>>>>>>>>>> set the Length
>>>>>>>>>>>>>>>    field's value in the Error Code TLV equal to the Length
>>>>>>>>>>>>>>> field of the
>>>>>>>>>>>>>>>    problematic TLV in the received test packet.  The
>>>>>>>>>>>>>>> handling of the
>>>>>>>>>>>>>>>    Received TLV field in the reflected packet depends on the
>>>>>>>>>>>>>>> Error Code
>>>>>>>>>>>>>>>    value.  This specification defines that if the Error Code
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>    Unrecognized Type, then the Session-Reflector MUST use
>>>>>>>>>>>>>>> Code and Sub-
>>>>>>>>>>>>>>>    Code values to characterize the encountered problem using
>>>>>>>>>>>>>>> the Error
>>>>>>>>>>>>>>>    Code and Error Sub-Code sub-registries created by IANA
>>>>>>>>>>>>>>> (Section 5.5).
>>>>>>>>>>>>>>>    The Session-Reflector MUST copy the problematic TLV,
>>>>>>>>>>>>>>> starting from
>>>>>>>>>>>>>>>    the Type field but less four octets, into the Received
>>>>>>>>>>>>>>> TLV field.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The intention is to allow other methods of handling errors
>>>>>>>>>>>>>>> in other scenarios.
>>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, Jun 23, 2020 at 8:06 AM Rakesh Gandhi <
>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks Greg for the reply.
>>>>>>>>>>>>>>>> Some TLVs may be consumed by the reflector successfully. Is
>>>>>>>>>>>>>>>> it expected in the draft that reflectors always add Extra Padding TLV and
>>>>>>>>>>>>>>>> return a symmetric size packet in that case also? If that is not the case,
>>>>>>>>>>>>>>>> then the reflector can return the entire unrecognized TLV to avoid missing
>>>>>>>>>>>>>>>> useful data if the TLV was very small (e.g. just 4 byte size).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jun 23, 2020 at 10:56 AM Greg Mirsky <
>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Rakesh,
>>>>>>>>>>>>>>>>> thank you for your comments, suggestions. I had two
>>>>>>>>>>>>>>>>> objectives in mind when proposing to copy Length- 4 octets:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    - return a sufficient amount of information about the
>>>>>>>>>>>>>>>>>    problematic TLV to the Session-Sender;
>>>>>>>>>>>>>>>>>    - keep test packets symmetric, i.e., the length of the
>>>>>>>>>>>>>>>>>    reflected packet is the same as the length of the packet transmitted by the
>>>>>>>>>>>>>>>>>    Session-Sender.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I can imagine how using the Extra Padding TLV as described
>>>>>>>>>>>>>>>>> in -06 allows the Session-Sender to find which TLV(s) were not processed by
>>>>>>>>>>>>>>>>> the Session-Reflector. But I like that the Error Code TLV explicitly
>>>>>>>>>>>>>>>>> provides that information and may be used in error handling in other
>>>>>>>>>>>>>>>>> scenarios.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Jun 23, 2020 at 7:05 AM Rakesh Gandhi <
>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks Greg for the proposal.
>>>>>>>>>>>>>>>>>> Perhaps reflector can copy the entire received
>>>>>>>>>>>>>>>>>> unrecognized TLV including Type, Length and Value "as is". The Error Code
>>>>>>>>>>>>>>>>>> TLV will have Type - Unrecognized TLV and Length will include the
>>>>>>>>>>>>>>>>>> additional bytes in the Error code TLV - i.e. it is just a wrapper around
>>>>>>>>>>>>>>>>>> it. I am not clear if there is a need to add Extra Padding TLV instead.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, Jun 23, 2020 at 6:27 AM Henrik Nydell <
>>>>>>>>>>>>>>>>>> [email-masked] <hnydell@accedian..com>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi, I sense a bit of ambiguity in what should be sent
>>>>>>>>>>>>>>>>>>> back to the sender. The field is called "Received packet" and it is
>>>>>>>>>>>>>>>>>>> mentioned that the reflector should place "a copy of the problematic STAMP
>>>>>>>>>>>>>>>>>>> test packet" in this field. But later in the text you mention that only the
>>>>>>>>>>>>>>>>>>> problematic TLV (less 4 bytes) should be sent back.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I also believe it should be written out that it is not
>>>>>>>>>>>>>>>>>>> recommended to make use of the error TLV if the reflector doesnt recognize
>>>>>>>>>>>>>>>>>>> the TLV, it should then just replace the unknown TLV with the Extra Padding
>>>>>>>>>>>>>>>>>>> TLV as described in section 4..
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Jun 23, 2020 at 4:22 AM Greg Mirsky <
>>>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Rakesh,
>>>>>>>>>>>>>>>>>>>> below is the new section where a new Error Code LTV
>>>>>>>>>>>>>>>>>>>> defined:
>>>>>>>>>>>>>>>>>>>> NEW TEXT:
>>>>>>>>>>>>>>>>>>>>    An Error Code TLV is used by a STAMP
>>>>>>>>>>>>>>>>>>>> Session-Reflector to inform a
>>>>>>>>>>>>>>>>>>>>    Session-Sender of a problem processing the received
>>>>>>>>>>>>>>>>>>>> STAMP test
>>>>>>>>>>>>>>>>>>>>    packet.  The format of the Error Code TLV is shown
>>>>>>>>>>>>>>>>>>>> in Figure 13..
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>        0                   1                   2
>>>>>>>>>>>>>>>>>>>>             3
>>>>>>>>>>>>>>>>>>>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>>>>>>>>>>>>>>>>>>>> 4 5 6 7 8 9 0 1
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>>>>>>>>>>>       |        Error Code Type        |
>>>>>>>>>>>>>>>>>>>> Length              |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>>>>>>>>>>>       |      Code     |    Sub-Code   |
>>>>>>>>>>>>>>>>>>>>  Reserved             |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>>>>>>>>>>>       ~                        Received Packet
>>>>>>>>>>>>>>>>>>>>                ~
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>                          Figure 13: Error Code TLV
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    where fields are defined as the following:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    o  Error Code Type - TBA9 allocated by IANA Section
>>>>>>>>>>>>>>>>>>>> 5.1
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    o  Length - two octets long field equals length on
>>>>>>>>>>>>>>>>>>>> the Value field in
>>>>>>>>>>>>>>>>>>>>       octets.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    o  Code - one octet-long field.  It specifies the
>>>>>>>>>>>>>>>>>>>> reason for an
>>>>>>>>>>>>>>>>>>>>       error.  Valid values are defined in Section 5.5.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    o  Sub-Code - one octet-long field.  It provides
>>>>>>>>>>>>>>>>>>>> additional
>>>>>>>>>>>>>>>>>>>>       information to the Code field.  Valid values are
>>>>>>>>>>>>>>>>>>>> defined in
>>>>>>>>>>>>>>>>>>>>       Section 5.5.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    o  Reserved - two octets-long field.  MUST be zeroed
>>>>>>>>>>>>>>>>>>>> on transmission
>>>>>>>>>>>>>>>>>>>>       and ignored upon receipt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    o  Received Packet - a copy of the problematic STAMP
>>>>>>>>>>>>>>>>>>>> test packet,
>>>>>>>>>>>>>>>>>>>>       less four octets than the value in the Length
>>>>>>>>>>>>>>>>>>>> field.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    A Session-Reflector that encountered a problem
>>>>>>>>>>>>>>>>>>>> processing a TLV in
>>>>>>>>>>>>>>>>>>>>    the Extended STAMP test packet SHOULD include the
>>>>>>>>>>>>>>>>>>>> Error Code TLV in
>>>>>>>>>>>>>>>>>>>>    the reflected test packet.  TThe Session-Reflector
>>>>>>>>>>>>>>>>>>>> MUST set the
>>>>>>>>>>>>>>>>>>>>    Length field's value in the Error Code TLV equal to
>>>>>>>>>>>>>>>>>>>> the Length field
>>>>>>>>>>>>>>>>>>>>    of the problematic TLV in the received test packet.
>>>>>>>>>>>>>>>>>>>> The Session-
>>>>>>>>>>>>>>>>>>>>    Reflector MUST use Code and Sub-Code values to
>>>>>>>>>>>>>>>>>>>> characterize the
>>>>>>>>>>>>>>>>>>>>    encountered problem using the Error Code and Error
>>>>>>>>>>>>>>>>>>>> Sub-Code sub-
>>>>>>>>>>>>>>>>>>>>    registries created by IANA (Section 5.5).  The
>>>>>>>>>>>>>>>>>>>> Session-Reflector MUST
>>>>>>>>>>>>>>>>>>>>    copy the problematic TLV in the received test
>>>>>>>>>>>>>>>>>>>> packet, starting from
>>>>>>>>>>>>>>>>>>>>    its Type field but less four octets, into the
>>>>>>>>>>>>>>>>>>>> Received Packet field.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And here the text that specifies the handling of an
>>>>>>>>>>>>>>>>>>>> unknown Type:
>>>>>>>>>>>>>>>>>>>> NEW TEXT:
>>>>>>>>>>>>>>>>>>>>       if an implementation does not recognize the value
>>>>>>>>>>>>>>>>>>>> in the Type
>>>>>>>>>>>>>>>>>>>>       field it MUST include the Error Code TLV into the
>>>>>>>>>>>>>>>>>>>> reflected STAMP
>>>>>>>>>>>>>>>>>>>>       packet setting the Code field to the value
>>>>>>>>>>>>>>>>>>>> Unrecognized Type
>>>>>>>>>>>>>>>>>>>>       Table 10.  Processing of the Length and Received
>>>>>>>>>>>>>>>>>>>> Packet fields
>>>>>>>>>>>>>>>>>>>>       described in Section 4.9.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Also, a new sub-section added into IANA Considerations:
>>>>>>>>>>>>>>>>>>>> NEW TEXT:
>>>>>>>>>>>>>>>>>>>> 5.5.  Error Code and Error Sub-Code Sub-registries
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    IANA is requested to create Error Code and Error
>>>>>>>>>>>>>>>>>>>> Sub-Code sub-
>>>>>>>>>>>>>>>>>>>>    registries as part of the STAMP TLV Type registry.
>>>>>>>>>>>>>>>>>>>> All code points
>>>>>>>>>>>>>>>>>>>>    in the range 1 through 127 in these registries shall
>>>>>>>>>>>>>>>>>>>> be allocated
>>>>>>>>>>>>>>>>>>>>    according to the "IETF Review" procedure as
>>>>>>>>>>>>>>>>>>>> specified in [RFC8126]..
>>>>>>>>>>>>>>>>>>>>    Code points in the range 128 through 239 in these
>>>>>>>>>>>>>>>>>>>> registries shall be
>>>>>>>>>>>>>>>>>>>>    allocated according to the "First Come First Served"
>>>>>>>>>>>>>>>>>>>> procedure as
>>>>>>>>>>>>>>>>>>>>    specified in [RFC8126].  Remaining code points are
>>>>>>>>>>>>>>>>>>>> allocated
>>>>>>>>>>>>>>>>>>>>    according to Table 9:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +-----------+--------------+-------------------------+
>>>>>>>>>>>>>>>>>>>>           | Value     | Description  | Reference
>>>>>>>>>>>>>>>>>>>>         |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +-----------+--------------+-------------------------+
>>>>>>>>>>>>>>>>>>>>           | 0         |   Reserved   | This document
>>>>>>>>>>>>>>>>>>>>         |
>>>>>>>>>>>>>>>>>>>>           | 1- 127    |  Unassigned  | IETF Review
>>>>>>>>>>>>>>>>>>>>         |
>>>>>>>>>>>>>>>>>>>>           | 128 - 239 |  Unassigned  | First Come First
>>>>>>>>>>>>>>>>>>>> Served |
>>>>>>>>>>>>>>>>>>>>           | 240 - 249 | Experimental | This document
>>>>>>>>>>>>>>>>>>>>         |
>>>>>>>>>>>>>>>>>>>>           | 250 - 254 | Private Use  | This document
>>>>>>>>>>>>>>>>>>>>         |
>>>>>>>>>>>>>>>>>>>>           | 255       |   Reserved   | This document
>>>>>>>>>>>>>>>>>>>>         |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +-----------+--------------+-------------------------+
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>            Table 9: Error Code and Error Sub-Code
>>>>>>>>>>>>>>>>>>>> Sub-registries
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>    This document defines the following new values in
>>>>>>>>>>>>>>>>>>>> the Error Code sub-
>>>>>>>>>>>>>>>>>>>>    registry:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  +-------+-------------------+---------------+
>>>>>>>>>>>>>>>>>>>>                | Value |    Description    | Reference
>>>>>>>>>>>>>>>>>>>>     |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  +-------+-------------------+---------------+
>>>>>>>>>>>>>>>>>>>>                | 1     | Unrecognized Type | This
>>>>>>>>>>>>>>>>>>>> document |
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  +-------+-------------------+---------------+
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>                            Table 10: Error Codes
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I greatly appreciate your comments and suggestions.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, Jun 22, 2020 at 6:46 PM Rakesh Gandhi <
>>>>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Greg,
>>>>>>>>>>>>>>>>>>>>> I think this document should have some generic
>>>>>>>>>>>>>>>>>>>>> handling. There can be generic return codes and also return of the
>>>>>>>>>>>>>>>>>>>>> unsupported TLVs. It could be one combo tlv with sub-tlvs or two separate
>>>>>>>>>>>>>>>>>>>>> tlvs.
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Mon., Jun. 22, 2020, 8:07 p.m. Greg Mirsky, <
>>>>>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If that is preferred by everyone, we can certainly
>>>>>>>>>>>>>>>>>>>>>> roll it in. I can share the new text by tomorrow.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Mon, Jun 22, 2020 at 4:49 PM Martin Duke <
>>>>>>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Why not in this document?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jun 22, 2020 at 4:45 PM Greg Mirsky <
>>>>>>>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi Rakesh,
>>>>>>>>>>>>>>>>>>>>>>>> I think that is a great idea, thank you! We have
>>>>>>>>>>>>>>>>>>>>>>>> several ideas for new TLVs, would you be interested to discuss and work
>>>>>>>>>>>>>>>>>>>>>>>> together on this? I think the Return Code TLV you've suggested can be added
>>>>>>>>>>>>>>>>>>>>>>>> to a new document. What do you think?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jun 22, 2020 at 4:41 PM Rakesh Gandhi <
>>>>>>>>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Greg,
>>>>>>>>>>>>>>>>>>>>>>>>> One comment regarding handling of unknown Type
>>>>>>>>>>>>>>>>>>>>>>>>> values to a "softer" approach.. It is better than the ICMP message.
>>>>>>>>>>>>>>>>>>>>>>>>> Why not define a new TLV Type called Unsupported
>>>>>>>>>>>>>>>>>>>>>>>>> TLV? The Value of that TLV can return the whole unsupported TLV including
>>>>>>>>>>>>>>>>>>>>>>>>> its Type. This way there is no ambiguity. The return packet size may be
>>>>>>>>>>>>>>>>>>>>>>>>> different but this would be the case when the TLV is consumed by the
>>>>>>>>>>>>>>>>>>>>>>>>> reflector.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> My 2c.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jun 22, 2020 at 7:17 PM Greg Mirsky <
>>>>>>>>>>>>>>>>>>>>>>>>> [email-masked]> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Dear All,
>>>>>>>>>>>>>>>>>>>>>>>>>> the new version includes updates to address one
>>>>>>>>>>>>>>>>>>>>>>>>>> comment from WG LC (thank you, Yali Wang), and the comments from AD review
>>>>>>>>>>>>>>>>>>>>>>>>>> (many thanks, Martin):
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>    - clarified the interoperation between a
>>>>>>>>>>>>>>>>>>>>>>>>>>    Session-Sender that uses SSID and a Session-Refletr that does not;
>>>>>>>>>>>>>>>>>>>>>>>>>>    - simplified allocation of the Type values by
>>>>>>>>>>>>>>>>>>>>>>>>>>    merging the Mandatory and optional ranges of values into one;
>>>>>>>>>>>>>>>>>>>>>>>>>>    - modified handling of unknown Type values to
>>>>>>>>>>>>>>>>>>>>>>>>>>    a "softer" approach. The Session-Reflector includes the Extra Padding TLV
>>>>>>>>>>>>>>>>>>>>>>>>>>    in the reflected packet in place of the unrecognized TLV. That keeps
>>>>>>>>>>>>>>>>>>>>>>>>>>    packets symmetrical, i..e., the same length;
>>>>>>>>>>>>>>>>>>>>>>>>>>    - improvements to the text - removed text
>>>>>>>>>>>>>>>>>>>>>>>>>>    duplication, added some clarifications..
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I always welcome your questions and comments.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>>>>>>>>>>>>>>>>>> From: <[email-masked]>
>>>>>>>>>>>>>>>>>>>>>>>>>> Date: Mon, Jun 22, 2020 at 12:45 PM
>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: New Version Notification for
>>>>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-ippm-stamp-option-tlv-06.txt
>>>>>>>>>>>>>>>>>>>>>>>>>> To: Ernesto Ruffini <[email-masked]>,
>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Foote <[email-masked]>, Greg
>>>>>>>>>>>>>>>>>>>>>>>>>> Mirsky <[email-masked]>, Henrik Nydell <
>>>>>>>>>>>>>>>>>>>>>>>>>> [email-masked]>, Adi Masputra <
>>>>>>>>>>>>>>>>>>>>>>>>>> [email-masked]>, Xiao Min <[email-masked]..cn
>>>>>>>>>>>>>>>>>>>>>>>>>> <[email-masked]>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> A new version of I-D,
>>>>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-ippm-stamp-option-tlv-06.txt
>>>>>>>>>>>>>>>>>>>>>>>>>> has been successfully submitted by Greg Mirsky
>>>>>>>>>>>>>>>>>>>>>>>>>> and posted to the
>>>>>>>>>>>>>>>>>>>>>>>>>> IETF repository.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Name:           draft-ietf-ippm-stamp-option-tlv
>>>>>>>>>>>>>>>>>>>>>>>>>> Revision:       06
>>>>>>>>>>>>>>>>>>>>>>>>>> Title:          Simple Two-way Active Measurement
>>>>>>>>>>>>>>>>>>>>>>>>>> Protocol Optional Extensions
>>>>>>>>>>>>>>>>>>>>>>>>>> Document date:  2020-06-22
>>>>>>>>>>>>>>>>>>>>>>>>>> Group:          ippm
>>>>>>>>>>>>>>>>>>>>>>>>>> Pages:          24
>>>>>>>>>>>>>>>>>>>>>>>>>> URL:
>>>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-ippm-stamp-option-tlv-06.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-06
>>>>>>>>>>>>>>>>>>>>>>>>>> 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-06
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Abstract:
>>>>>>>>>>>>>>>>>>>>>>>>>>    This document describes optional extensions to
>>>>>>>>>>>>>>>>>>>>>>>>>> Simple Two-way Active
>>>>>>>>>>>>>>>>>>>>>>>>>>    Measurement Protocol (STAMP) which enable
>>>>>>>>>>>>>>>>>>>>>>>>>> measurement performance
>>>>>>>>>>>>>>>>>>>>>>>>>>    metrics in addition to ones supported by the
>>>>>>>>>>>>>>>>>>>>>>>>>> STAMP base
>>>>>>>>>>>>>>>>>>>>>>>>>>    specification.  The document also defines a
>>>>>>>>>>>>>>>>>>>>>>>>>> STAMP Test Session
>>>>>>>>>>>>>>>>>>>>>>>>>>    Identifier and thus updates RFC 8762.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Please note that it may take a couple of minutes
>>>>>>>>>>>>>>>>>>>>>>>>>> from the time of submission
>>>>>>>>>>>>>>>>>>>>>>>>>> until the htmlized version and diff are available
>>>>>>>>>>>>>>>>>>>>>>>>>> at tools.ietf.org.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>> ippm mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>> ippm mailing list
>>>>>>>>>>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> ippm mailing list
>>>>>>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Henrik Nydell*
>>>>>>>>>>>>>>>>>>> *Sr Product Manager*
>>>>>>>>>>>>>>>>>>> 1.866.685.8181
>>>>>>>>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>>>>>>>>> <http://accedian.com>
>>>>>>>>>>>>>>>>>>> <https://www.facebook.com/accedian/>
>>>>>>>>>>>>>>>>>>> <https://twitter.com/Accedian>
>>>>>>>>>>>>>>>>>>> <https://ca.linkedin.com/company/accedian>
>>>>>>>>>>>>>>>>>>> <http://www.accedian.com>
>>>>>>>>>>>>>>>>>>> *accedian.com <http://accedian.com>*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Avis de confidentialité
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Les informations contenues dans le présent message et
>>>>>>>>>>>>>>>>>>> dans toute pièce qui lui est jointe sont confidentielles et peuvent être
>>>>>>>>>>>>>>>>>>> protégées par le secret professionnel. Ces informations sont à l’usage
>>>>>>>>>>>>>>>>>>> exclusif de son ou de ses destinataires. Si vous recevez ce message par
>>>>>>>>>>>>>>>>>>> erreur, veuillez s’il vous plait communiquer immédiatement avec
>>>>>>>>>>>>>>>>>>> l’expéditeur et en détruire tout exemplaire. De plus, il vous est
>>>>>>>>>>>>>>>>>>> strictement interdit de le divulguer, de le distribuer ou de le reproduire
>>>>>>>>>>>>>>>>>>> sans l’autorisation de l’expéditeur. Merci.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Confidentiality notice
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This e-mail message and any attachment hereto contain
>>>>>>>>>>>>>>>>>>> confidential information which may be privileged and which is intended for
>>>>>>>>>>>>>>>>>>> the exclusive use of its addressee(s). If you receive this message in
>>>>>>>>>>>>>>>>>>> error, please inform sender immediately and destroy any copy thereof.
>>>>>>>>>>>>>>>>>>> Furthermore, any disclosure, distribution or copying of this message and/or
>>>>>>>>>>>>>>>>>>> any attachment hereto without the consent of the sender is strictly
>>>>>>>>>>>>>>>>>>> prohibited. Thank you.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>> ippm mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>>>>>
>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 4 Jul 2020 11:51:40 -0700

Hi Rakesh,
thank you for your help and comments. The intention of that wording was to
instruct an implementor to copy the unprocessed part of an extended STAMP
packet, including the TLV that failed validation. I am open to any
suggestion if the wording used does not convey that idea or if the desired
behavior is not right.

Regards,
Greg

On Sat, Jul 4, 2020 at 7:04 AM Rakesh Gandhi <[email-masked]> wrote:

>>>>>> (2) TLV has an error such as wrong length or value, are not covered
>>>>>>> by the draft.
>>>>>>>
>>>>>> This was part of the specification and, as I understand, the WG
>>>>>> agreed to the procedure.
>>>>>>
>>>>>>>>>>> ~ Value field from Received Unrecognized TLV Truncated by 4
>>>>>>>>>>> Bytes ~
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> you're right, to keep packets symmetrical we must leave not
>>>>>>>>>>>> four but eight octets out. Since several TLVs defined in the draft, e.g.,
>>>>>>>>>>>>> The Error code TLV adds 8 more bytes to the Unrecognized TLV
>>>>>>>>>>>>> (4 bytes for the "Code/Subcode/Reserved" part and 4 bytes for the
>>>>>>>>>>>>>>    value.  This specification defines the Unrecognized Type
>>>>>>>>>>>>>> as a new
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    o  MUST set the Length field's value in Error Code equal
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> Attached, please find the new working version of the draft
>>>>>>>>>>>>>> and the diff to -06. Please review and share your comments.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> please consider the discussion and share your thoughts on
>>>>>>>>>>>>>> what should be done next.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    Received TLV field in the reflected packet depends on
>>>>>>>>>>>>>>>> the Error Code
>>>>>>>>>>>>>>>>    value.  This specification defines that if the Error
>>>>>>>>>>>>>>>> Code is
>>>>>>>>>>>>>>>>    Code values to characterize the encountered problem
>>>>>>>>>>>>>>>> using the Error
>>>>>>>>>>>>>>>>> Some TLVs may be consumed by the reflector successfully.
>>>>>>>>>>>>>>>>> Is it expected in the draft that reflectors always add Extra Padding TLV
>>>>>>>>>>>>>>>>> and return a symmetric size packet in that case also? If that is not the
>>>>>>>>>>>>>>>>> case, then the reflector can return the entire unrecognized TLV to avoid
>>>>>>>>>>>>>>>>> missing useful data if the TLV was very small (e.g. just 4 byte size).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    - keep test packets symmetric, i.e., the length of
>>>>>>>>>>>>>>>>>>    the reflected packet is the same as the length of the packet transmitted by
>>>>>>>>>>>>>>>>>>    the Session-Sender.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I can imagine how using the Extra Padding TLV as
>>>>>>>>>>>>>>>>>> described in -06 allows the Session-Sender to find which TLV(s) were not
>>>>>>>>>>>>>>>>>> processed by the Session-Reflector. But I like that the Error Code TLV
>>>>>>>>>>>>>>>>>> explicitly provides that information and may be used in error handling in
>>>>>>>>>>>>>>>>>> other scenarios.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>    o  Reserved - two octets-long field.  MUST be
>>>>>>>>>>>>>>>>>>>>> zeroed on transmission
>>>>>>>>>>>>>>>>>>>>>    o  Received Packet - a copy of the problematic
>>>>>>>>>>>>>>>>>>>>> STAMP test packet,
>>>>>>>>>>>>>>>>>>>>>    of the problematic TLV in the received test
>>>>>>>>>>>>>>>>>>>>> packet.  The Session-
>>>>>>>>>>>>>>>>>>>>>       if an implementation does not recognize the
>>>>>>>>>>>>>>>>>>>>> value in the Type
>>>>>>>>>>>>>>>>>>>>>       field it MUST include the Error Code TLV into
>>>>>>>>>>>>>>>>>>>>> the reflected STAMP
>>>>>>>>>>>>>>>>>>>>>    in the range 1 through 127 in these registries
>>>>>>>>>>>>>>>>>>>>> shall be allocated
>>>>>>>>>>>>>>>>>>>>>    allocated according to the "First Come First
>>>>>>>>>>>>>>>>>>>>> Served" procedure as
>>>>>>>>>>>>>>>>>>>>>           | 128 - 239 |  Unassigned  | First Come
>>>>>>>>>>>>>>>>>>>>> First Served |
>>>>>>>>>>>>>>>>>>>>>>>>>>>    - simplified allocation of the Type values
>>>>>>>>>>>>>>>>>>>>>>>>>>>    by merging the Mandatory and optional ranges of values into one;
>>>>>>>>>>>>>>>>>>>>>>>>>>>    - modified handling of unknown Type values
>>>>>>>>>>>>>>>>>>>>>>>>>>>    to a "softer" approach. The Session-Reflector includes the Extra Padding
>>>>>>>>>>>>>>>>>>>>>>>>>>>    TLV in the reflected packet in place of the unrecognized TLV. That keeps
>>>>>>>>>>>>>>>>>>>>>>>>>>> Title:          Simple Two-way Active
>>>>>>>>>>>>>>>>>>>>>>>>>>> Measurement Protocol Optional Extensions
>>>>>>>>>>>>>>>>>>>>>>>>>>>    This document describes optional extensions
>>>>>>>>>>>>>>>>>>>>>>>>>>> to Simple Two-way Active
>>>>>>>>>>>>>>>>>>>>>>>>>>> until the htmlized version and diff are
>>>>>>>>>>>>>>>>>>>>>>>>>>> available at tools.ietf.org.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The IETF Secretariat
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 3 Jul 2020 12:40:44 -0700

Hi Rakesh,

Regards,
Greg

On Mon, Jun 29, 2020 at 2:56 PM Rakesh Gandhi <[email-masked]>
wrote:

> On Mon, Jun 29, 2020 at 4:38 PM Greg Mirsky <[email-masked]> wrote:
>
>> Hi Rakesh,
>>>> GIM>> Do you see this as a different case from the Not recognized? What
>>>> could be the difference between these two cases from the test operator's
>>>> point of view?
>>>>
>>>
>>>>       equal, the processing of extension TLVs MUST be stopped.  Also, if
>>> <RG> Why use a different protocol (ICMP) for error handling while it can
>>> be done within the same protocol (STAMP)? Makes it easier to implement in
>>> the same protocol.
>>>
>>>
>>>>>> On Tue, Jun 23, 2020 at 3:16 PM Rakesh Gandhi <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>> On Tue, Jun 23, 2020 at 5:41 PM Martin Duke <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>> ~ Value field from Received Unrecognized TLV Truncated by 4 Bytes ~
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> | Error Code Type               | Length = Unrecognized TLV Len+4
>>>>>>>>> |
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jun 23, 2020 at 5:08 PM Greg Mirsky <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Rakesh,
>>>>>>>>>>>    field's value in the Error Code TLV equal to the Length field
>>>>>>>>>>> of the
>>>>>>>>>>>>    the Extended STAMP test packet SHOULD include the Error Code
>>>>>>>>>>>> TLV in
>>>>>>>>>>>> I think that to continue moving this document, we need guidance
>>>>>>>>>>>> from WG Chairs and our AD.
>>>>>>>>>>>>>>    the Type field but less four octets, into the Received TLV
>>>>>>>>>>>>>> field.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The intention is to allow other methods of handling errors in
>>>>>>>>>>>>>> other scenarios.
>>>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    packet.  The format of the Error Code TLV is shown in
>>>>>>>>>>>>>>>>>>> Figure 13..
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>        0                   1                   2
>>>>>>>>>>>>>>>>>>>           3
>>>>>>>>>>>>>>>>>>>       |        Error Code Type        |           Length
>>>>>>>>>>>>>>>>>>>              |
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    copy the problematic TLV in the received test packet,
>>>>>>>>>>>>>>>>>>> starting from
>>>>>>>>>>>>>>>>>>>    according to the "IETF Review" procedure as specified
>>>>>>>>>>>>>>>>>>> in [RFC8126]..
>>>>>>>>>>>>>>>>>>>    This document defines the following new values in the
>>>>>>>>>>>>>>>>>>> Error Code sub-
>>>>>>>>>>>>>>>>>>>    registry:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> [email-masked]>, Adi Masputra <[email-masked]>,
>>>>>>>>>>>>>>>>>>>>>>>>> Xiao Min <[email-masked]..cn
>>>>>>>>>>>>>>>>>>>>>>>>> <[email-masked]>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> A new version of I-D,
>>>>>>>>>>>>>>>>>>>>>>>>> has been successfully submitted by Greg Mirsky and
>>>>>>>>>>>>>>>>>>>>>>>>> posted to the
>>>>>>>>>>>>>>>>>>>>>>>>> IETF repository.
>>>>>>>>>>>>>>>>>>>>>>>>>

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 6 Jul 2020 09:35:12 -0400

Hi Greg,
Thanks for your reply.
I would have thought that the reflector would just return the copy of the
whole HMAC TLV as is, just like the other two error cases (U and L).

Thanks,
Rakesh

On Sat, Jul 4, 2020 at 2:51 PM Greg Mirsky <[email-masked]> wrote:

>> Many thanks Greg for the updates and discussions. Changes look good to
>> me. One minor comment on the text below, why only copy the "remainder" and
>> not the entire TLV?
>>
>>> Attached are the working copy (including changes addressing comments
>>> from SecDir and GenART reviewers) and the diff to -06 version.
>>>
>>>>>>> On Fri, Jun 26, 2020 at 9:41 AM Rakesh Gandhi <
>>>>>> <RG> Unsupported means recognized but software doesn't support some
>>>>>> or all aspects of the TLV.
>>>>>>
>>>>>>
>>>>>>> GIM>> I think that we have covered this case in the following part
>>>>>>> of Section 4:
>>>>>>>>> I've taken Martin's idea and made changes in the working version
>>>>>>>>> of the draft (attached along with the diff). I think that it provides the
>>>>>>>>>>> Speaking as an individual, another way to go would be to use
>>>>>>>>>>> only 15 bits for the type and have the first bit be an error indicator.
>>>>>>>>>>>
>>>>>>>>>>>> Len |
>>>>>>>>>>>>> The requirement is to ensure that test packets are
>>>>>>>>>>>>> symmetrical. If we decide that is not required, then the text can be
>>>>>>>>>>>>> modified accordingly.
>>>>>>>>>>>>>> I also do not see the flexibility to return
>>>>>>>>>>>>>> entire/truncated.. TLV. It says following with MUST:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    - return a sufficient amount of information about
>>>>>>>>>>>>>>>>>>>    the problematic TLV to the Session-Sender;
>>>>>>>>>>>>>>>>>>>>>>    Session-Sender of a problem processing the
>>>>>>>>>>>>>>>>>>>>>> received STAMP test
>>>>>>>>>>>>>>>>>>>>>>    o  Error Code Type - TBA9 allocated by IANA
>>>>>>>>>>>>>>>>>>>>>> Section 5.1
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>       information to the Code field.  Valid values
>>>>>>>>>>>>>>>>>>>>>> are defined in
>>>>>>>>>>>>>>>>>>>>>>       Section 5.5.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>    Length field's value in the Error Code TLV equal
>>>>>>>>>>>>>>>>>>>>>> to the Length field
>>>>>>>>>>>>>>>>>>>>>>       Table 10.  Processing of the Length and
>>>>>>>>>>>>>>>>>>>>>> Received Packet fields
>>>>>>>>>>>>>>>>>>>>>>    registries as part of the STAMP TLV Type
>>>>>>>>>>>>>>>>>>>>>> registry.  All code points
>>>>>>>>>>>>>>>>>>>>>>                | Value |    Description    |
>>>>>>>>>>>>>>>>>>>>>> Reference     |
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please note that it may take a couple of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> minutes from the time of submission