Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
Greg Mirsky <gregimirsky@gmail.com> Thu, 26 September 2019 15:08 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472F212088D; Thu, 26 Sep 2019 08:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.755
X-Spam-Level:
X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMPF1EHi-Q7O; Thu, 26 Sep 2019 08:08:29 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE7C12088E; Thu, 26 Sep 2019 08:08:23 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id q64so2529981ljb.12; Thu, 26 Sep 2019 08:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bFzD0C0CHy1rasABY/DenB8BTZUAKVXrbLHTTN0kAc4=; b=PjGX3m//IXfvOtZR36NWVeFwFyk2AaScXyKi2mlzyemtWauQTmGIZiq3wyPADulKJD sa9crB4Erteb5FtdUyQ+RIBf3q95MDnwNJY7+3WKUBycPsgeXA0Uxs13DR8o3NGlPuhs 6QfSQEysNSkeNsAiFzSg44Gp9C3LmCXBSnnmbkO3NNMJHM2zuJFZIuEsaWods/W63UY1 3Cu+2Mz/dsvn7LirNOsMg6wGx1BpWyoaFPtFaAg1qQlkwLv3p/I2bqlEhXxusGNdr+k6 QIJkwEJ7Xdpz1+tG3p9SC4KuYtT4e5CzHmE08NtjTTq8sM8+RHGF7IddKzySKPFYUZWg CdtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bFzD0C0CHy1rasABY/DenB8BTZUAKVXrbLHTTN0kAc4=; b=BYRDLAFY6vr/JJionyEwLk7ckKSctE82JwJPDewa62EJkmUD0yW2SpbEhEult9ABSr 5IKjmiZeuJHIAYaozA4TS+EJCusbIboTEAVpFImYmRHszQkjsNQJPMt0Ms38NmZZ2/8i C3C3947w4dkDQPt+mfCi99ugE+qLl3xueBgTeEEDPzdvJ91Rmk/ojBdT7Ntccn44SHeo 7lkwDziCCUorRJEBfDK2iBt+nuDMbUTVg2CHnm0cKvUEl9NCUqkhZ2BF3YxKhUQtWRt4 Im9QNkP2CYyCCDl5XURr2ZCpctFE3eI2+SaVZrRk4SFRq27JildwEf693MepFB7jr0+X 9s7w==
X-Gm-Message-State: APjAAAWGMwmyUuzaZIkfEM2nlaUUWqXrQRIDEtEZhVpUSWMkhLT/v1tO 3LioA97yoU5d6ajMMTLcv9DKzA0Tg1+axV1rlkg=
X-Google-Smtp-Source: APXvYqy+RqrL3Rd1f0U0gXY9Yrz6/tT7cQj1Qxf63H9JB+K93GRuSsevk3VvP9JyNs5LAifQ+8ounzCu5pFTPFrcqSI=
X-Received: by 2002:a2e:5d98:: with SMTP id v24mr3097616lje.56.1569510501099; Thu, 26 Sep 2019 08:08:21 -0700 (PDT)
MIME-Version: 1.0
References: <156760524845.22816.16339950342338392164.idtracker@ietfa.amsl.com> <CA+RyBmUy-_ETfaPWoYivcWa0S3De4dcn9=Wb47M7x0vSfEsjYQ@mail.gmail.com> <06fcd3bea80067202534aa70857194b2e4335d3f.camel@ericsson.com> <CA+RyBmUowr39bRBDv1g35f-rJve-whkscd0ht17cjJA5-rWixQ@mail.gmail.com> <ed5f1afb634e8c0d39cdb6c2a52ad9e2ab459285.camel@ericsson.com> <CA+RyBmU08iGsqK9M9Vyq5wgs9UKQ7Q7c1zg_0j4u4X_48jOHGw@mail.gmail.com> <d87ce9b28bc7649875a1e5faff975e899f4609c9.camel@ericsson.com>
In-Reply-To: <d87ce9b28bc7649875a1e5faff975e899f4609c9.camel@ericsson.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 26 Sep 2019 08:08:10 -0700
Message-ID: <CA+RyBmUwRvaaXPZV8NM2by4=jmKesdSkyzA2sJ6QcR8Xa8C=Og@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "tal.mizrahi.phd@gmail.com" <tal.mizrahi.phd@gmail.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e3b35a05937623be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/u4x6hoEJVx7Lpq_qgZwq7L98jeY>
Subject: Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2019 15:08:36 -0000
Hi Magnus, thank you for all your comments, discussion, and patience. Kind regards, Greg On Thu, Sep 26, 2019 at 1:41 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi Greg, > > This clarifies it sufficiently. I have cleared my discuss. > > Thanks > > Magnus > > On Tue, 2019-09-24 at 13:39 -0700, Greg Mirsky wrote: > > Hi Magnus, > > a new section, Operational Considerations, has been added to address > Barry's > > DISCUSS: > > > > 5. Operational Considerations > > > > STAMP is intended to be used on production networks to enable the > > operator to assess service level agreements based on packet delay, > > delay variation, and loss. When using STAMP over the Internet, > > especially when STAMP test packets are transmitted with the > > destination UDP port number from the User Ports range, the possible > > impact of the STAMP test packets MUST be thoroughly analyzed. The > > use of STAMP for each case MUST be agreed by users of nodes hosting > > the Session-Sender and Session-Reflector before starting the STAMP > > test session. > > > > Also, the use of the well-known port number as the destination UDP > > port number in STAMP test packets transmitted by a Session-Sender > > would not impede the ability to measure performance in an Equal Cost > > Multipath environment and analysis in Section 5.3 [RFC8545] fully > > applies to STAMP. > > > > Would it address your concern? > > > > The new version of the draft has been published. It includes all the > updates > > we've discussed. > > > > Much appreciate your consideration of the new version, comments, and > > questions. > > > > Kind regards, > > Greg > > > > On Mon, Sep 16, 2019 at 8:29 AM Magnus Westerlund < > > magnus.westerlund@ericsson.com> wrote: > > > On Wed, 2019-09-11 at 11:33 -0700, Greg Mirsky wrote: > > > > Hi Magnus, > > > > thank you for clarifications and further detailing your comments, > > > > questions. Please find my answers and notes below in-lined under the > > > > GIM2>> tag. > > > > > > > > Regards, > > > > Greg > > > > > > > > On Wed, Sep 11, 2019 at 12:53 AM Magnus Westerlund < > > > > magnus.westerlund@ericsson.com> wrote: > > > > > Hi Greg, > > > > > > > > > > Thanks for the reply. See inline for my comments and response. > > > > > > > > > > > > > > > On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote: > > > > > > Hi Magnus, > > > > > > thank you for the review and thoughtful, pointed questions. > > > > > Please > > > > > > find my answers in-line under GIM>> tag. > > > > > > > > > > > > Regards, > > > > > > Greg > > > > > > > > > > > > On Wed, Sep 4, 2019 at 3:54 PM Magnus Westerlund via Datatracker > > > > > < > > > > > > noreply@ietf.org> wrote: > > > > > > > Magnus Westerlund has entered the following ballot position for > > > > > > > draft-ietf-ippm-stamp-07: Discuss > > > > > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > > to > > > > > > > all > > > > > > > email addresses included in the To and CC lines. (Feel free to > > > > > cut > > > > > > > this > > > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > > > > > > > Please refer to > > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found > > > > > here: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > > ---- > > > > > > > ----- > > > > > > > DISCUSS: > > > > > > > ------------------------------------------------------------- > > > > > ---- > > > > > > > ----- > > > > > > > > > > > > > > Two very much discussing discusses. However, I would really > > > > > like to > > > > > > > hear the > > > > > > > answer to these concerns before clearing. > > > > > > > > > > > > > > 1. Section 4.3: Is the HMAC field size of 16 bytes hard coded? > > > > > If > > > > > > > there ever > > > > > > > would exist a need to deploy another integrity solution, even > > > > > if > > > > > > > the actual > > > > > > > algorithm used to construct the tag can be agreed by the > > > > > > > management, there > > > > > > > appear to exist a hard look in to use 16-byte tags. Have this > > > > > issue > > > > > > > been > > > > > > > considered? > > > > > > > > > > > > GIM>> Indeed, this specification defines the use of only one > > > > > > algorithm and only 16 bytes-long HMAC field. Your question > > > > > prompted > > > > > > the discussion among authors and we believe that in a future > > > > > > specification it would be feasible to extend supporting a number > > > > > of > > > > > > algorithms and different lengths of HMAC field both being defined > > > > > > through extension to STAMP YANG data model. > > > > > > > > > > So if I understand this (taking a discussion with Mirja about > > > > > keeping > > > > > things as simple as possible) the solution is to basically is when > > > > > need > > > > > arises define a new STAMP version, and then use YANG to coordinate > > > > > which version is used for the measurement. If that is a correct re- > > > > > interpretation of your response then I am fine with it. > > > > > > > > GIM2>> The direction from the WG was to keep the base specification > > > > as simple as possible (and that was the reason to split TLV > > > > extensions into a separate document). > > > > > > Yes, understood. > > > > > > > > > > 2. Section 6: > > > > > > > The possible impact of the > > > > > > > STAMP test packets on the network MUST be thoroughly > > > > > analyzed, > > > > > > > and > > > > > > > the use of STAMP for each case MUST be agreed by all users > > > > > on > > > > > > > the > > > > > > > network before starting the STAMP test session. > > > > > > > > > > > > > > I assume some potential issues are know, shouldn't they > > > > > > > really be > > > > > > > listed here in the security consideration to further > > > > > > > motivate why the > > > > > > > analysis needs to happen. > > > > > > > > > > > > GIM>> This is in reference to using numbers from the User range > > > > > as > > > > > > the destination port number. Would adding the reference to the > > > > > case > > > > > > of using the port numbers from the User range address your > > > > > concern? > > > > > > Or rather refer to Section 4, as it includes more discussion > > > > > (see > > > > > > below)? > > > > > > > > > > Okay, I don't really care where the discussion happens. But I don't > > > > > find any real discussion and listing of the concerns with using > > > > > user or > > > > > dynamic ports for STAMP Sessions? With the formulation you use, I > > > > > would > > > > > expect at least some list of potential concerns that needs to be > > > > > evaluated in the context of the particular usage of STAMP. > > > > > > > > GIM2>> Per Berry's suggestion, I'm adding a new section, Operational > > > > Considerations, to list possible scenarios and possible issues with > > > > using destination ports from the User range and from the Dynamic > > > > range. I hope to finish it in a couple days. Will share on this > > > > discussion thread promptly. > > > > > > Great! > > > > > > Looking forward to review it when written. > > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > > ---- > > > > > > > ----- > > > > > > > COMMENT: > > > > > > > ------------------------------------------------------------- > > > > > ---- > > > > > > > ----- > > > > > > > > > > > > > > 1. Section 4: > > > > > > > Before using numbers from the User Ports range, the > > > > > > > possible impact > > > > > > > on the network MUST be carefully studied and agreed by all > > > > > users > > > > > > > of > > > > > > > the network. > > > > > > > > > > > > > > Is the above sentence missing to list an important > > > > > > > assumption? Is the > > > > > > > assumption that by using the registred destination port > > > > > an > > > > > > > operator > > > > > > > that sees to much STAMP traffic can simply filter it > > > > > out > > > > > > > and that way > > > > > > > deal with the traffic, something which is not possible > > > > > when > > > > > > > using an > > > > > > > locally decided port? If that is the case, this > > > > > assumption > > > > > > > should > > > > > > > probably be noted. > > > > > > > > > > > > GIM>> That is a very good point but our primary motivation for > > > > > this > > > > > > cautionary note (or strong warning) was that by allowing STAMP to > > > > > use > > > > > > port numbers from the User range, ports that may be already > > > > > assigned > > > > > > to protocols, creates a DDOS attack vector. As for the filtering > > > > > > STAMP traffic out, I think that even if the destination port is > > > > > one > > > > > > from the Dynamic range, for a relatively long test session it can > > > > > be > > > > > > filtered out. > > > > > > > > > > So if that is the only? concern then write it out. I would expect > > > > > that > > > > > the higher layer management protocol that creates a measurement > > > > > session > > > > > to actually ensure that the STAMP endpoint actually have the port > > > > > numbers they attempt to use. Isn't that a reasonable requirement to > > > > > put > > > > > on the solution? > > > > > > > > GIM2>> Agree with your suggestion. Will put in the new section. If > > > > STAMP is managed by a centralized system, whether it is proprietary > > > > OSS/BSS or an orchestrator that uses YANG data models, the system > > > > will be able to coordinate selection of port numbers on the Session- > > > > Sender and Session-Reflector. But some systems may use EMS or CLI and > > > > that is where human coordination may be required. > > > > > > > > > Good, then likely this is resolved when your text is ready. > > > > > > > > My thinking with the filtering out concern was that in cases where > > > > > one > > > > > runs STAMP measurement sessions, if the measurement interfer with > > > > > critical traffic an action for an on-path node that can actually > > > > > identify the STAMP traffic was to filer it out. And that may be > > > > > considered trivial when the well known port is used, but if a user > > > > > or > > > > > dynamic port is used, then that requries a managment system to > > > > > provide > > > > > the on-path node with the necessary information, i.e. 3/5 tuple for > > > > > the > > > > > STAMP flows. > > > > > > > > GIM2>> I think that a transit node can identify a flow as the STAMP > > > > flow only if the destination port is the STAMP default UDP > > > > destination port number, 862. In case a STAMP session has the > > > > destination port number as one of port numbers from the User range, > > > > IP/UDP encapsulation of STAMP packets would be indistinguishable from > > > > packets originated by the application that is assigned that port > > > > number. Thus, filtering out on only destination port number may > > > > negatively affect service, legitimate service. Because of that, I > > > > think that filtering will have to use more information. On the other > > > > hand, if the test flow does not exceed agreed rate, then any > > > > filtering test packets out, in my opinion, is counter-productive, as > > > > it hides some issues in the networks rather than letting the OAM > > > > tools to expose them, localize, and characterize. > > > > > > Ok. This was primarily to understand if this was in scope or not. But > > > it sounds like this is not really in scope for how to manage it. > > > > > > > > > > > > > > > 2. Section 3 and 4, and 4.1.1: What is a STAMP Session? > > > > > Is > > > > > > > that a > > > > > > > measurment session between one specific and sender and > > > > > a > > > > > > > specific > > > > > > > reflector for a time duration? The defenition of the > > > > > > > session do matter > > > > > > > if one intended to enable a single sender to use > > > > > multiple > > > > > > > reflectors, > > > > > > > and if that can be a single session or always multiple > > > > > > > indepdendent > > > > > > > ones. Would appreciate a definition what a session is. > > > > > If > > > > > > > it is > > > > > > > possible to send STAMP traffic using a multicast or > > > > > > > broadcast address > > > > > > > should be made explicit. > > > > > > > > > > > > GIM>> Your interpretation is correct, STAMP session is implicitly > > > > > > defined as p2p. And that is what reflected in the STAMP YANG > > > > > model. > > > > > > Would the following text make it clearer: > > > > > > NEW TEXT: > > > > > > In this document, a measurement session also referred to as > > > > > > STAMP session, is the session between one specific Session- > > > > > Sender > > > > > > and > > > > > > one particular Session-Reflector for a time duration. > > > > > > > > > > Yes, please include that definition. Question would it be clearer > > > > > to > > > > > replace ".. is the session betweeen .." with ".. is the bi- > > > > > directional > > > > > packet flows between .."? > > > > > > > > GIM2>> I agree, defining a session as a session makes is somewhat > > > > repetitive. Thank you. > > > > Below is the updated text: > > > > In this document, a measurement session also referred to as > > > > STAMP session, is the bi-directional packet flow between one > > > > specific > > > > Session-Sender and one particular Session-Reflector for a time > > > > duration. > > > > > > Looks good to me. > > > > > > > > > > > > > > > 3. Section 4.1.1.: > > > > > > > Timestamp is eight octets long field. STAMP node MUST > > > > > > > support > > > > > > > Network Time Protocol (NTP) version 4 64-bit timestamp > > > > > format > > > > > > > [RFC5905], the format used in [RFC5357]. STAMP node MAY > > > > > > > support > > > > > > > IEEE 1588v2 Precision Time Protocol truncated 64-bit > > > > > > > timestamp > > > > > > > format [IEEE.1588.2008], the format used in [RFC8186]. > > > > > > > > > > > > > > Is the clock source here something that may be relevant > > > > > or > > > > > > > simply > > > > > > > information the management functions should capture. I > > > > > > > think there is a > > > > > > > similar issue to that of RTP faced when it comes to > > > > > > > understand what the > > > > > > > timestamp actually represent and thus be used > > > > > correctly. > > > > > > > RTP clock > > > > > > > source specification is RFC 7273 > > > > > > > (https://datatracker.ietf.org/doc/rfc7273/) > > > > > > > > > > > > GIM>> NTP and PTP encodings have a different interpretation of > > > > > the > > > > > > Fraction field of the Timestamp field. In my experience, PTP > > > > > format > > > > > > is native for the data plane, while NTP is more used at the > > > > > control > > > > > > plane. Original extension to TWAMP has been described in RFC > > > > > 8186. > > > > > > > > > > I think you missunderstood. When I talk about clock source, I am > > > > > actually referring to identifying the particular clock that the > > > > > node > > > > > use to derive the included timestamp from. > > > > > > > > > > And likely this is a moot point in this document where the clock > > > > > source > > > > > information belongs in the management layer, e.g. in the YANG data > > > > > model. > > > > > > > > GIM2>> Timestamp Information TLV (draft-ietf-ippm-stamp-option-tlv) > > > > provides information about the clock synchronization protocol and the > > > > method by wich the timestamp has been acquired at a Session- > > > > Reflector. We may extend it to list the name/locatior of the master > > > > clock. > > > > > > Ok. sounds reasonable. > > > > > > > > > > > > > > > 4. Section 4.1: > > > > > > > Because STAMP supports symmetrical test packets, > > > > > STAMP > > > > > > > Session-Sender > > > > > > > packet has a minimum size of 44 octets in unauthenticated > > > > > mode, > > > > > > > see > > > > > > > Figure 2, and 112 octets in the authenticated mode, see > > > > > Figure > > > > > > > 4. > > > > > > > > > > > > > > The above text implies some potential for UDP payload > > > > > size > > > > > > > variability > > > > > > > for the STAMP packets. However, the actual definition > > > > > > > appear to have > > > > > > > fixed sizes. Can you please clarify if I have missed > > > > > > > something that > > > > > > > enables the STAMP packet to have variable size? > > > > > > > > > > > > GIM>> I think that the text can be improved by characterizing the > > > > > > listed sizes as "base". The variable length of a test packet in > > > > > STAMP > > > > > > is supported by using Extra Padding TLV defined in draft-ietf- > > > > > ippm- > > > > > > stamp-option-tlv. Below is the proposed update: > > > > > > OLD TEXT: > > > > > > Because STAMP supports symmetrical test packets, STAMP > > > > > Session- > > > > > > Sender > > > > > > packet has a minimum size of 44 octets in unauthenticated > > > > > mode, > > > > > > see > > > > > > Figure 2, and 112 octets in the authenticated mode, see Figure > > > > > 4. > > > > > > NEW TEXT: > > > > > > STAMP supports symmetrical test packets. The base STAMP > > > > > Session- > > > > > > Sender packet has a minimum size of 44 octets in > > > > > unauthenticated > > > > > > mode, see Figure 2, and 112 octets in the authenticated mode, > > > > > see > > > > > > Figure 4. The variable length of a test packet in STAMP is > > > > > > supported > > > > > > by using Extra Padding TLV defined in > > > > > > [I-D.ietf-ippm-stamp-option-tlv]. > > > > > > > > > > > > With the new reference, should I-D.ietf-ippm-stamp-option-tlv be > > > > > > moved to the Normative References list or may remain in the > > > > > > Informative list? > > > > > > > > > > From my perspective, the fact that optional TLV may occur following > > > > > the > > > > > base headers appears quite important. Here comes a question of > > > > > intention form the WG. Is it intended that one can have STAMP > > > > > endpoints > > > > > that do not even support receiving packets larger than the base? > > > > > In other words there will be two main versions already now, one > > > > > that > > > > > supports some TLV and can at least handle the TLV skip forward and > > > > > ignore the content and one that will throw a fit over the TLVs? If > > > > > that > > > > > is not the intention I think the fact that TLV's may occur should > > > > > be > > > > > moved into this specification and have it as a normative reference. > > > > > > > > GIM2>> Will move the reference to the Normative section. With TLV > > > > being normative, I'd expect that the intelligent implementation of > > > > this draft, of the base STAMP specification, will accept any valid > > > > STAMP packet though not process extensions. But the base STAMP > > > > Session-Reflector will return the base reflected packet. > > > > > > I think that is very reasonable approach. Are you close to complete the > > > stamp-option-tlv document, or will the missref cause any issue? > > > > > > > > I guess the answer is that you have backwards comaptibility reasons > > > > > for > > > > > not allowing TLVs at all in some sessions, or? > > > > > > > > GIM2>> Yes, that and the principle "keep it simple". > > > > > > Thanks, > > > > > > To me it looks like with some text changes all my issues are addressed. > > > > > > Cheers > > > > > > Magnus Westerlund > > > > > > > > > ---------------------------------------------------------------------- > > > Network Architecture & Protocols, Ericsson Research > > > ---------------------------------------------------------------------- > > > Ericsson AB | Phone +46 10 7148287 > > > Torshamnsgatan 23 | Mobile +46 73 0949079 > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > ---------------------------------------------------------------------- > > > > > > > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > >
- [ippm] Magnus Westerlund's Discuss on draft-ietf-… Magnus Westerlund via Datatracker
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Henrik Nydell
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Henrik Nydell
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Magnus Westerlund
- Re: [ippm] Magnus Westerlund's Discuss on draft-i… Greg Mirsky