From nobody Wed Sep 7 08:57:41 2016 Return-Path: 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 8811112B1CB; Wed, 7 Sep 2016 08:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.029 X-Spam-Level: X-Spam-Status: No, score=-16.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RqUcXj1wQN9f; Wed, 7 Sep 2016 08:57:30 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDB112B21B; Wed, 7 Sep 2016 08:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=86009; q=dns/txt; s=iport; t=1473263849; x=1474473449; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=qW4l1lldhkEaJSAlLjJwtaEKsW62AmCRCW19JqJ/xEM=; b=GzgdGBm978/hhYiUQC9lf5zRG2Lu3Rej7xpT/FtmrNHiSJ70ySF8ED1U DWa2JPf9Ybs/dPc2TgaTqbi0aT8nKnQdSJag7UyT7uZ3ckFg/lUYwia7z 4nkRS0KOfTzz3RHlicgi8mAv1rZdQoUBJwOlqNbnKUpmv4ewDN7ASTQZ7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAwChONBX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgnozAQEBAQF1KlKNL6sNggADGQEKgh0Bg1oCgh4UAQIBAQEBAQEBXieEYgE?= =?us-ascii?q?BBAEBARdUCxALOAENJzAGAQwGAgEBiEYOvD8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEXBYYvgXiCVoQRDAYBAQEEhVUdBY4nhVAVhU2GIokbgW6EXoMSgSCEXYZzghG?= =?us-ascii?q?HRx42hFI6NIMpDheCCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,296,1470700800"; d="scan'208,217";a="645346380" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2016 15:57:25 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u87FvPUL003084; Wed, 7 Sep 2016 15:57:25 GMT To: Jan Lindblad , Mahesh Jethanandani References: <69F97F8E-AFD0-4ACD-81E2-4E769E1EBA73@tail-f.com> <9BB14D6E-9ADA-43FB-8730-8CA7E36BC27E@gmail.com> <92F6A871-7872-41D9-8388-FB34ED059C02@tail-f.com> From: Benoit Claise Message-ID: Date: Wed, 7 Sep 2016 17:57:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <92F6A871-7872-41D9-8388-FB34ED059C02@tail-f.com> Content-Type: multipart/alternative; boundary="------------696FE8B94D531FE83E80FFB5" Archived-At: Cc: YANG Doctors , draft-ietf-ippm-twamp-yang@ietf.org, ippm@ietf.org Subject: Re: [ippm] [yang-doctors] YD review of draft-ietf-ippm-twamp-yang X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 15:57:33 -0000 This is a multi-part message in MIME format. --------------696FE8B94D531FE83E80FFB5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Mahesh, Can you please let us know what the status is, after the YANG doctors review. See Jan's first paragraph below. Regards, Benoit > Mahesh, all, > >> The authors have updated the document based on the comments sent in >> this e-mail. The latest version of the draft can be found here >> . Please >> let us know if the document addresses your comments. > > Hmm. I have checked several times to see if the link above really > leads to the latest document, but I find it does. Many of the points I > suggested needed changes have been fixed. Most, however, have not been > changed or fixed in any way. While the opinions expressed in my review > comments are certainly not binding to the WG in any way, I find some > of this status quo strange. Even a number of plain errors remain > unfixed. It is also odd that in many cases fixes are suggested by [mj] > in this mail thread, but do not appear in the actual document or YANG > spec. > > I apologize if perhaps I'm missing something fundamental. > >>> [mj] Our decision was to move the current set of documentation on >>> each attribute from the draft into the description field of the YANG >>> module, and reducing the documentation within the draft itself to a >>> high level overview. You will find as a result, that it will address >>> some of the questions you have raised about attributes. > > I think this is an excellent change, which increases the > readability+maintainability of both the RFC and the YANG. > >>> [mj] In general there seems to be some confusion around the usage of >>> RFC 2119 language for terms such as MUST. SHOULD. MAY etc. as it >>> relates to text in the draft and its implication/use in the YANG >>> module. We could remove its usage in the YANG module,or change the >>> SHOULD to a should, and leave the text in the draft if that helps >>> to draw the difference. A SHOULD in an RFC is a RECOMMEND, which for >>> valid reasons can be ignored by the system. Therefore …. >>> >>>> >>>> Section 4.1 and section 4.2 describes the max-count leaf like this: >>>> max-count >>>> If an attacking system sets the maximum value in Count >>>> (2**32), then the system under attack would stall for a >>>> significant period of time while it attempts to generate >>>> keys. Therefore, TWAMP-compliant systems SHOULD have a >>>> configuration control to limit the maximum Count value. The >>>> default max-count value SHOULD be 32768. >>> >>> [mj] The reason that max-count is a SHOULD and not a MUST is because >>> it is still a *recommendation* of the count. Nowhere in the model do >>> we enforce it with a must/if statement. Implementations can choose >>> any value within that range *if* they want to change the default value. > > The module currently defines the max-count as follows: > > leaf max-count { > type uint32 { > range 1024..4294967295; > } > default 32768; > description > "This parameter limits the maximum Count value. > > If an attacking system sets the maximum value in > Count (2**32), then the system under attack would stall > for a significant period of time while it attempts to > generate keys."; > } > > With this definition, there is no way for a system that implements > this module to use anything else than 32768 for the default value. The > RFC text says SHOULD, the YANG text says MUST through the use of the > default statement. I find this problematic. One or the other should be > changed to not be mutually contradictory. > > For MUST behavior: change the RFC text to say MUST. > > For SHOULD behavior: remove the YANG "default" statement, so that each > implementation can pick its own implementation dependent default. If > there is no default statement, then each implementor can implement the > behavior they like for the case that this optional leaf is left unset. > There is no such freedom if the RFC keeps a default statement in the > YANG module. > >>>> Line 208: >>>> container twamp { >>>> description "Top level container"; >>>> >>>> We know it's a top level container. Explain instead what TWAMP is, >>>> and what the four pillars inside are. >>> >>> [mj] How about this? >>> >>> Container twamp consists of the four models that together describe >>> the TWAMP deployment. They are TWAMP Control-Client, Server, >>> Session-Sender >>> and Session-Reflector. > > Sounds good. But it's not in the YANG. > >>>> Line 210: >>>> container twamp-client { >>>> presence "twamp-client"; >>>> description "Twamp client container"; >>>> >>>> I'd suggest renaming "twamp-client" to "client". It's already >>>> inside container "twamp". Presence statements should explain what >>>> it means if they are created, e.g. "Enables TWAMP-client >>>> functionality", and what if it doesn't exist. >>> >>> [mj] Ok. Will rename twamp-client to client. You do bring up a good >>> point on what if does not exist. Let me discuss with the authors. > > The name change is implemented, nice. But the presence statement > doesn't describe anything useful. As noted above it should be > something like > presence "Enables TWAMP-client functionality"; > > container client { > if-feature control-client; > presence client; > description > "Configuration of the TWAMP Control-Client logical entity."; > >>>> Line 224: >>>> leaf priority { >>>> type uint16; >>>> description "priority"; >>>> } >>>> >>>> Explain that lower values indicate higher priority. >>> >>> [mj] How about this? >>> >>> description “Expressed as a 16-bit unsigned integer, where zero is >>> the highest priority and >>> subsequent values monotonically increasing) with their corresponding >>> mode (expressed as a 32-bit Hexadecimal value). Depending on the >>> Modes available in the Server Greeting, the Control-Client MUST >>> choose the highest priority Mode from the configured >>> mode-preference- chain list.”; > > Fine, but this text isn't in the YANG. > >>>> Line 235: >>>> list key-chain { >>>> key "key-id"; >>>> leaf key-id { >>>> type string { >>>> length "1..80"; >>>> } >>>> description "Key ID"; >>>> } >>>> >>>> Where is that max length of 80 characters coming from? Is there a >>>> reason/value for this limit? >>>> >>>> Line 243: >>>> leaf secret-key { >>>> type string; >>>> description "Secret key"; >>>> } >>>> >>>> Is string appropriate here? Wouldn't binary be a more appropriate >>>> representation, which has a safe base64 textual encoding? >>> >>> [mj] References to key-chain, key-id, secret-key will be removed >>> from this draft. We will refer to the YANG model in >>> https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-06 for >>> key-chain and its attributes. > > They are still here now, YANG unchnaged. > >>>> Line 259: >>>> leaf client-ip { >>>> type inet:ip-address; >>>> description "Client IP address"; >>>> } >>>> >>>> Explain what happens if client-ip is not set. >>> >>> [mj] When we move the description of client ip into the model, it >>> will address this issue. > > Not fixed yet. > >>>> Line 286: >>>> leaf max-count { >>>> type uint32 { >>>> range 1024..4294967295; >>>> } >>>> default 32768; >>>> description "Max count value."; >>>> } >>>> >>>> As mentioned above, this is inconsistent with the RFC text's >>>> SHOULD. Here it is modeled as MUST. This value needs to be a power >>>> of two, say so in the description. Also explain the security >>>> implications of using a lower or higher number. A better range >>>> statement would be >>>> range >>>> "1024|2048|4096|8192|16384|32768|65536|131072|262144|524288|1048576|2097152|4194304|8388608|16777216|33554432|67108864|134217728|268435456|536870912|1073741824|2147483648"; >>>> >>>> Alternatively, it might be more convenient for operators if this >>>> was modeled as a small power of two value with the range 10..31. >>> >>> [mj] I think there some confusion brought about by the range and >>> default value as it applies to 'max-count'. While the range and >>> default value have numbers that are power of 2, I am not sure the >>> implication is that the value that can be set has to be power of 2. >>> At least not for this attribute. It might be true for the attribute >>> ‘count'. For that attribute, I agree that we could use the range >>> statement that you have defined above. > > There are two leaf count at different levels under /twamp/server. One > of them specifically says power of 2. Shouldn't they have the same > description and range? > > Leaf max-count is described as "This parameter limits the maximum > Count value.", wouldn't that mean that it needs to be a power of two > as well? > Would it make sense to have a must statement on count, must "current() > <= ../max-count" ? > > Regardless of the comment above, the more specific range is not seen > anywhere in the YANG. > > leaf count { > type uint32 { > range 1024..4294967295; > } > description > "Parameter used in deriving a key from a shared > secret as described in href="./rfc4656#section-3.1">Section 3.1 of RFC 4656, > and are communicated to the Control-Client as part > of the Server Greeting message. > > count MUST be a power of 2. > > count MUST be at least 1024. > > count SHOULD be increased as more computing power > becomes common."; > } > >>>> Line 298: >>>> leaf server-start-time { >>>> type uint64; >>>> config "false"; >>>> description "The Start-Time advertized by the Server in >>>> the Server-Start message"; >>>> } >>>> >>>> What is the base and units of this value? Specify in description >>>> and using "units" keyword. >>> >>> [mj] How about this? >>> >>> leaf server-start-time { >>> …. >>> units seconds; >>> description >>> “The Start-Time advertised in seconds by the Server in the >>> Server-Start message”; > > Very good. But it's not in the latest YANG. > >>>> Line 348: >>>> leaf sender-udp-port { >>>> type dynamic-port-number; >>>> description "Sender UDP port"; >>>> } >>>> >>>> Explain what happens if not set. >>> >>> [mj] Good point. While we say what happens if the value is set to >>> zero, we do not say what happens if the value is not set at all. A >>> default value of 0?? > > No change in the YANG as yet. > >>>> Line 365: >>>> leaf timeout { >>>> type uint64; >>>> default "2"; >>>> description "The time (in seconds)Session-Reflector MUST >>>> wait after receiving a Stop-Session message."; >>>> } >>>> >>>> Specify units using "units" keyword. >>> >>> [mj] How about this? >>> >>> leaf timeout { >>> >>> …. >>> units seconds; >>> …. >>> } > > Good, but not in the YANG. > >>>> Line 379: >>>> leaf dscp { >>>> type inet:dscp; >>>> description "The DSCP value to be placed in the UDP >>>> header of TWAMP-Test packets generated by the >>>> Session-Sender, and in the UDP header of the TWAMP-Test >>>> response packets generated by the Session-Reflector >>>> for this test session."; >>>> } >>>> >>>> Specify what happens if not set. Possibly add a default statement. >>> >>> [mj] Moving the description from the draft into the model should >>> address this. > > It's not in the YANG. > >>>> Line 397: >>>> leaf repeat { >>>> type uint32; >>>> default "0"; >>>> description "Determines if the test session is to be >>>> run repeatedly. The default value of repeat is 0, >>>> indicating that once the session has completed, it >>>> will not be renegotiated and restarted. 1 thru 4,294,967,294 >>>> indicate the number of repetitions, and the max value of >>>> 4,294,967,295 indicates repeat forever."; >>>> } >>>> >>>> Using magical values is a thing of the past and does not belong in >>>> YANG moduled, IMO. It's not making the configuration intent easy to >>>> parse by humans nor machines. Could we rather model this as >>>> type union { >>>> type uint32 { >>>> range 0..4294967294; >>>> } >>>> type enumeration { >>>> enum forever; >>>> } >>>> } >>> >>> [mj] Agree. Will update the model. > > No change to the YANG as yet. > >>>> Line 407: >>>> leaf repeat-interval { >>>> when "../repeat!='0'" { >>>> description "When repeat is not 0, the test is to be >>>> repeated"; >>>> } >>>> type uint32; >>>> description "Repeat interval (in minutes)"; >>>> } >>>> >>>> Why minutes? Is this really following the principle of least >>>> surprise? In any case, add "units" statement. >>> >>> [mj] s/minutes/seconds/ >>> >>> and add >>> >>> units seconds; > > Very good, but it's not in the YANG. > >>>> Line 466: >>>> leaf dscp { >>>> type inet:dscp; >>>> description "The DSCP value to be placed in the IP header of >>>> TCP TWAMP-Control packets generated by the Server"; >>>> } >>>> >>>> Specify what happens if not set. Possibly add a default statement. >>> >>> Moving the description from the draft into the model will address this. > > Not yet. > >>>> Line 578: >>>> leaf salt{ >>>> type binary { >>>> length "16"; >>>> } >>>> description "Salt MUST be generated pseudo-randomly"; >>>> } >>>> >>>> This is a config false value, not much point discussing how it MUST >>>> be generated. >>> >>> [mj] Agreed. > > No change in YANG yet. > >>>> Line 633: >>>> leaf number-of-packets { >>>> type uint32; >>>> description "The overall number of UDP test packets to be >>>> transmitted by the sender for this test session."; >>>> } >>>> >>>> Specify what happens if not set. Possibly add a default statement. > > No change. > >>>> Line 645: >>>> leaf periodic-interval-units { >>>> type units; >>>> description "Periodic interval units"; >>>> } >>>> >>>> Specify what happens if not set. Possibly add a default statement. > > Not adressed. > >>>> Line 656: >>>> leaf lambda-units{ >>>> type uint32; >>>> description "Lambda units."; >>>> } >>>> >>>> Specify what happens if not set. Possibly add a default statement. >>>> Add a units "reciprocal-seconds" statement, and give a better >>>> description. It's not easy to figure out what value to use here >>>> currently. >>>> >>>> Line 660: >>>> leaf max-interval{ >>>> type uint32; >>>> description "maximum time between packet >>>> transmissions."; >>>> } >>>> >>>> Maybe a better description would be "Maximum time between packet >>>> transmissions given in units specified by lambda-units.” >>> >>> [mj] Agree. > > No change. > >>>> Line 665: >>>> leaf truncation-point-units{ >>>> type units; >>>> description "Truncation point units"; >>>> } >>>> >>>> What is this? I see no explanation in the document, other than the >>>> allowed values. What happens if you set it, or if it is left unset? >>>> Maybe add a default statement? >>> >>> [mj] Ok. Will add reference to Section 4.6 of RFC 7312. Units will >>> be seconds. > > No change. > >>>> Line 690: >>>> leaf refwait { >>>> type uint32 { >>>> range 1..604800; >>>> } >>>> default 900; >>>> description "REFWAIT (TWAMP test session timeout), >>>> the default value is 900"; >>>> } >>>> >>>> Add a units statement. >>>> >>>> Section 6.1, in the second example has a port value out of range. >>>> 500001 >>>> >>>> Change to port 50001? >>>> >>>> All throughout chapter 6 and 7 there are numerous examples of >>>> sender-udp-port and reflector-udp-port that are outside the dynamic >>>> port range. That would be invalid according to the YANG model. >>>> >>>> 4001 >>>> >>>> Change to port 54001? Must be in the dynamic port range. >>> >>> Will correct. >>> >>>> >>>> Section 6 starts off stating "This section presents a simple but >>>> complete example of configuring all four entities in Figure 1", but >>>> only the three first examples are actually configurations. All the >>>> rest are the results from operations with some filter. >>> >>> Will correct text. >>> >>>> >>>> Section 7, security considerations, is empty. Needs to be fixed. >>> >>> Will update. >>> >>>> >>>> Appendix A claims thart "This appendix extends the example >>>> presented in Section 6 by configuring more fields such as >>>> authentication parameters, dscp values and so on." All examples are >>>> however results of operations. Several sender-udp-port and >>>> reflector-udp-port values are out of range. >>> >>> Will change text and fix port values. > > None of the examples seem to have been corrected. > > /jan > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --------------696FE8B94D531FE83E80FFB5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Mahesh,

Can you please let us know what the status is, after the YANG doctors review.
See Jan's first paragraph below.

Regards, Benoit
Mahesh, all,

The authors have updated the document based on the comments sent in this e-mail. The latest version of the draft can be found here. Please let us know if the document addresses your comments.

Hmm. I have checked several times to see if the link above really leads to the latest document, but I find it does. Many of the points I suggested needed changes have been fixed. Most, however, have not been changed or fixed in any way. While the opinions expressed in my review comments are certainly not binding to the WG in any way, I find some of this status quo strange. Even a number of plain errors remain unfixed. It is also odd that in many cases fixes are suggested by [mj] in this mail thread, but do not appear in the actual document or YANG spec.

I apologize if perhaps I'm missing something fundamental.

[mj] Our decision was to move the current set of documentation on each attribute from the draft into the description field of the YANG module, and reducing the documentation within the draft itself to a high level overview. You will find as a result, that it will address some of the questions you have raised about attributes.

I think this is an excellent change, which increases the readability+maintainability of both the RFC and the YANG.

[mj] In general there seems to be some confusion around the usage of RFC 2119 language for terms such as MUST. SHOULD. MAY etc. as it relates to text in the draft and its implication/use in the YANG module. We could remove its usage in the YANG module,or change the SHOULD to a should,  and leave the text in the draft if that helps to draw the difference. A SHOULD in an RFC is a RECOMMEND, which for valid reasons can be ignored by the system. Therefore ….


Section 4.1 and section 4.2 describes the max-count leaf like this:
  max-count
          If an attacking system sets the maximum value in Count
          (2**32), then the system under attack would stall for a
          significant period of time while it attempts to generate
          keys.  Therefore, TWAMP-compliant systems SHOULD have a
          configuration control to limit the maximum Count value.  The
          default max-count value SHOULD be 32768.

[mj] The reason that max-count is a SHOULD and not a MUST is because it is still a recommendation of the count. Nowhere in the model do we enforce it with a must/if statement. Implementations can choose any value within that range if they want to change the default value.

The module currently defines the max-count as follows:

        leaf max-count {
          type uint32 {
            range 1024..4294967295;
          }
          default 32768;
          description
            "This parameter limits the maximum Count value.

            If an attacking system sets the maximum value in
            Count (2**32), then the system under attack would stall
            for a significant period of time while it attempts to
            generate keys.";
        }

With this definition, there is no way for a system that implements this module to use anything else than 32768 for the default value. The RFC text says SHOULD, the YANG text says MUST through the use of the default statement. I find this problematic. One or the other should be changed to not be mutually contradictory.

For MUST behavior: change the RFC text to say MUST.

For SHOULD behavior: remove the YANG "default" statement, so that each implementation can pick its own implementation dependent default. If there is no default statement, then each implementor can implement the behavior they like for the case that this optional leaf is left unset. There is no such freedom if the RFC keeps a default statement in the YANG module.

Line 208:
 container twamp {
   description "Top level container";

We know it's a top level container. Explain instead what TWAMP is, and what the four pillars inside are.

[mj] How about this?

Container twamp consists of the four models that together describe the TWAMP deployment. They are TWAMP Control-Client, Server, Session-Sender 
   and Session-Reflector.

Sounds good. But it's not in the YANG.

Line 210:
   container twamp-client {
     presence "twamp-client";
     description "Twamp client container";

I'd suggest renaming "twamp-client" to "client". It's already inside container "twamp". Presence statements should explain what it means if they are created, e.g. "Enables TWAMP-client functionality", and what if it doesn't exist.

[mj] Ok. Will rename twamp-client to client. You do bring up a good point on what if does not exist. Let me discuss with the authors.

The name change is implemented, nice. But the presence statement doesn't describe anything useful. As noted above it should be something like 
presence "Enables TWAMP-client functionality";

    container client {
      if-feature control-client;
      presence client;
      description
        "Configuration of the TWAMP Control-Client logical entity.";

Line 224:
       leaf priority {
         type uint16;
         description "priority";
       }

Explain that lower values indicate higher priority.

[mj] How about this?

description “Expressed as a 16-bit unsigned integer, where zero is the highest priority and 
   subsequent values monotonically increasing) with their corresponding
   mode (expressed as a 32-bit Hexadecimal value).  Depending on the
   Modes available in the Server Greeting, the Control-Client MUST
   choose the highest priority Mode from the configured mode-preference-
   chain list.”;

Fine, but this text isn't in the YANG.

Line 235:
     list key-chain {
       key "key-id";
       leaf key-id {
         type string {
           length "1..80";
         }
         description "Key ID";
       }

Where is that max length of 80 characters coming from? Is there a reason/value for this limit?

Line 243:
       leaf secret-key {
         type string;
         description "Secret key";
       }

Is string appropriate here? Wouldn't binary be a more appropriate representation, which has a safe base64 textual encoding?

[mj] References to key-chain, key-id, secret-key will be removed from this draft. We will refer to the YANG model in https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-06 for key-chain and its attributes.

They are still here now, YANG unchnaged.

Line 259:
       leaf client-ip {
         type inet:ip-address;
         description "Client IP address";
       }

Explain what happens if client-ip is not set.

[mj] When we move the description of client ip into the model, it will address this issue.

Not fixed yet.

Line 286:
       leaf max-count {
         type uint32 {
           range 1024..4294967295;
         }
         default 32768;
         description "Max count value.";
       }

As mentioned above, this is inconsistent with the RFC text's SHOULD. Here it is modeled as MUST. This value needs to be a power of two, say so in the description. Also explain the security implications of using a lower or higher number. A better range statement would be
range "1024|2048|4096|8192|16384|32768|65536|131072|262144|524288|1048576|2097152|4194304|8388608|16777216|33554432|67108864|134217728|268435456|536870912|1073741824|2147483648";

Alternatively, it might be more convenient for operators if this was modeled as a small power of two value with the range 10..31.

[mj] I think there some confusion brought about by the range and default value as it applies to 'max-count'. While the range and default value have numbers that are power of 2, I am not sure the implication is that the value that can be set has to be power of 2. At least not for this attribute. It might be true for the attribute ‘count'. For that attribute, I agree that we could use the range statement that you have defined above.

There are two leaf count at different levels under /twamp/server. One of them specifically says power of 2. Shouldn't they have the same description and range?

Leaf max-count is described as "This parameter limits the maximum Count value.", wouldn't that mean that it needs to be a power of two as well?
Would it make sense to have a must statement on count, must "current() <= ../max-count" ?

Regardless of the comment above, the more specific range is not seen anywhere in the YANG.

      leaf count {
        type uint32 {
          range 1024..4294967295;
        }
        description
            "Parameter used in deriving a key from a shared
            secret as described in <a href="./rfc4656#section-3.1">Section&nbsp;3.1 of  RFC 4656</a>,
            and are communicated to the Control-Client as part
            of the Server Greeting message.

            count MUST be a power of 2.

            count MUST be at least 1024.

            count SHOULD be increased as more computing power
            becomes common.";
      }

Line 298:
       leaf server-start-time {
         type uint64;
         config "false";
         description "The Start-Time advertized by the Server in
         the Server-Start message";
       }

What is the base and units of this value? Specify in description and using "units" keyword.

[mj] How about this?

leaf server-start-time {
   ….
   units seconds;
   description 
       “The Start-Time advertised in seconds by the Server in the
         Server-Start message”; 

Very good. But it's not in the latest YANG.

Line 348:
         leaf sender-udp-port {
           type dynamic-port-number;
           description "Sender UDP port";
         }

Explain what happens if not set.

[mj] Good point. While we say what happens if the value is set to zero, we do not say what happens if the value is not set at all. A default value of 0??

No change in the YANG as yet.

Line 365:
         leaf timeout {
           type uint64;
           default "2";
           description "The time (in seconds)Session-Reflector MUST
           wait after receiving a Stop-Session message.";
         }

Specify units using "units" keyword.

[mj] How about this?

leaf timeout {

   ….
   units seconds;
   ….
}

Good, but not in the YANG.

Line 379:
         leaf dscp {
           type inet:dscp;
           description "The DSCP value to be placed in the UDP
           header of TWAMP-Test packets generated by the
           Session-Sender, and in the UDP header of the TWAMP-Test
           response packets generated by the Session-Reflector
           for this test session.";
         }

Specify what happens if not set. Possibly add a default statement.

[mj] Moving the description from the draft into the model should address this.

It's not in the YANG.

Line 397:
         leaf repeat {
           type uint32;
           default "0";
           description "Determines if the test session is to be
           run repeatedly. The default value of repeat is 0,
           indicating that once the session has completed, it
           will not be renegotiated and restarted. 1 thru 4,294,967,294
           indicate the number of repetitions, and the max value of
           4,294,967,295 indicates repeat forever.";
         }

Using magical values is a thing of the past and does not belong in YANG moduled, IMO. It's not making the configuration intent easy to parse by humans nor machines. Could we rather model this as
type union {
   type uint32 {
       range 0..4294967294;
   }
   type enumeration {
       enum forever;
   }
}

[mj] Agree. Will update the model.

No change to the YANG as yet.

Line 407:
         leaf repeat-interval  {
           when "../repeat!='0'" {
             description "When repeat is not 0, the test is to be
             repeated";
           }
           type uint32;
           description "Repeat interval (in minutes)";
         }

Why minutes? Is this really following the principle of least surprise? In any case, add "units" statement.

[mj] s/minutes/seconds/

and add

   units seconds;

Very good, but it's not in the YANG.

Line 466:
     leaf dscp {
       type inet:dscp;
       description "The DSCP value to be placed in the IP header of
       TCP TWAMP-Control packets generated by the Server";
     }

Specify what happens if not set. Possibly add a default statement.

Moving the description from the draft into the model will address this.

Not yet.

Line 578:
       leaf salt{
         type binary {
           length "16";
         }
         description "Salt MUST be generated pseudo-randomly";
       }

This is a config false value, not much point discussing how it MUST be generated.

[mj] Agreed.

No change in YANG yet.

Line 633:
       leaf number-of-packets {
         type uint32;
         description "The overall number of UDP test packets to be
           transmitted by the sender for this test session.";
       }

Specify what happens if not set. Possibly add a default statement.

No change.

Line 645:
           leaf periodic-interval-units  {
             type units;
             description "Periodic interval units";
           }

Specify what happens if not set. Possibly add a default statement.

Not adressed.

Line 656:
           leaf lambda-units{
             type uint32;
             description "Lambda units.";
           }

Specify what happens if not set. Possibly add a default statement. Add a units "reciprocal-seconds" statement, and give a better description. It's not easy to figure out what value to use here currently.

Line 660:
           leaf max-interval{
             type uint32;
             description "maximum time between packet
             transmissions.";
           }

Maybe a better description would be "Maximum time between packet transmissions given in units specified by lambda-units.”

[mj] Agree.

No change.

Line 665:
           leaf truncation-point-units{
             type units;
             description "Truncation point units";
           }

What is this? I see no explanation in the document, other than the allowed values. What happens if you set it, or if it is left unset? Maybe add a default statement?

[mj] Ok. Will add reference to Section 4.6 of RFC 7312. Units will be seconds.

No change.

Line 690:
     leaf refwait {
       type uint32 {
         range 1..604800;
       }
       default 900;
       description "REFWAIT (TWAMP test session timeout),
         the default value is 900";
     }

Add a units statement.

Section 6.1, in the second example has a port value out of range.
                 <reflector-udp-port>500001</reflector-udp-port>

Change to port 50001?

All throughout chapter 6 and 7 there are numerous examples of sender-udp-port and reflector-udp-port that are outside the dynamic port range. That would be invalid according to the YANG model.

                 <sender-udp-port>4001</sender-udp-port>

Change to port 54001? Must be in the dynamic port range.

Will correct.


Section 6 starts off stating "This section presents a simple but complete example of configuring all four entities in Figure 1", but only the three first examples are actually configurations. All the rest are the results from <get> operations with some filter.

Will correct text.


Section 7, security considerations, is empty. Needs to be fixed.

Will update.


Appendix A claims thart "This appendix extends the example presented in Section 6 by configuring more fields such as authentication parameters, dscp values and so on." All examples are however results of <get> operations. Several sender-udp-port and reflector-udp-port values are out of range.

Will change text and fix port values.

None of the examples seem to have been corrected.

/jan



_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

--------------696FE8B94D531FE83E80FFB5-- From nobody Wed Sep 7 09:27:01 2016 Return-Path: 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 81E1612B384 for ; Wed, 7 Sep 2016 09:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 R4DkR5w1bv4c for ; Wed, 7 Sep 2016 09:26:58 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 C2C0C12B226 for ; Wed, 7 Sep 2016 09:26:58 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id l8so12298205ywb.0 for ; Wed, 07 Sep 2016 09:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=lcut9W6rbRrQY/sWrHeiesZVL7WW5Ovr4tRY2Ec+EmQ=; b=RbClhes0LXcqMbs7AI6h6DUkgNKiXhLaxNGkBSEjRS9RGMup5DXQrk9u355Ah8e5e5 0vKwEbaO2E02Dqkkc+pZT0ydI1difN33oqtVTxEmViyPA+qTpaDf79PUQeRCBgt6k6/L zEfD6RYWi55kUVgsbgVu2/KtwUm71svCM2UTsnjvJziX8a3BmAe27vaEjTNHcVdD1rWo wzlnNxGR9R3DVldPnDjEjeA4ZJwYuWZ6ciFhRabwNQY3R9jx+n4g3B7X3CunIgVS3LWS +g0dlcTJFhwP3RMaN+d9RncHql/6cVZlZVG95/CUmGIoS66R8wxYpifO4pNvsqQxIM2+ YiOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lcut9W6rbRrQY/sWrHeiesZVL7WW5Ovr4tRY2Ec+EmQ=; b=j6VMTC3Ch9FtaRYE7/qs6q70p+uDUhxBIljG8eHDUIiUN8QZlM5xrlGQrhpcmsG3Fc bC4tCwyFhUgPKZo0gcxHWQEjduAILiTb2znzTJph0cI8xD0ONY2d4ZlxQCJHItAYqrgS OrIlGp3KfhsugT9sO1I04ESe1d9Me08I67Ca6xfwGYt+uqlFdrn2q9mDFal4DjE9D9JG RqvJSc/PcC6dUlG8eIu8Q4YqFk8dXnrMjjEf3chOu5RZPIzz5FoSVvQPX5K1L6zepzO8 ol/KO0mcryDuTMG2s9HLQW0ZuATVGCMUQVpap9BwPFo+NJ2/B0OLEhaLX7Z3MIrV36bG PXow== X-Gm-Message-State: AE9vXwPxDQZZbpnUlrCavuHOJMzC+lgYiihpZ4aX6BwXICcsu/MFmbXmON/S5btoSgIG38IIPT1uAIhAvKCG1g== X-Received: by 10.129.30.214 with SMTP id e205mr37892416ywe.118.1473265618046; Wed, 07 Sep 2016 09:26:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.15.2 with HTTP; Wed, 7 Sep 2016 09:26:57 -0700 (PDT) From: Greg Mirsky Date: Wed, 7 Sep 2016 09:26:57 -0700 Message-ID: To: draft-ietf-ippm-twamp-yang@tools.ietf.org, "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a1142e364d2f64e053bed6149 Archived-At: Subject: [ippm] TWAMP YANG data models X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 16:27:00 -0000 --001a1142e364d2f64e053bed6149 Content-Type: text/plain; charset=UTF-8 Dear Authors, All in our meeting in Berlin I've shared my concern with the draft-ietf-ippm-twamp-yang. These are my comments: - Figure 2 presents view of how YANG data model my be used. I believe that in SDN environment the Orchestrator may act more like described in draft-mirsky-ippm-twamp-light-yang-03 Figure 1 where Session-Sender and Session-Reflector are configured directly without Server and Control-Client by the single SDN controller/configuration client; - even though TWAMP-Control is optional, one possible solution to control TWAMP-Test, TWAMP-Test dataa model depends on TWAMP-Control data model. For example: leaf ctrl-connection-name { type string; config false; description "The name of the parent TWAMP-Control connection that is responsible for negotiating this TWAMP-Test session."; } in list test-session, which is in session-sender; - as I look into session-sender YANG model I don't see it contains sender-ip, sender-udp-port, reflector-ip, reflector-udp-port, and test-packet-dscp. I believe that without these session-sender cannot be used to instantiate TWAMP test session without the TWAMP-Control; - I think that the test session state information provided by maintenance-statistics should be extended, e.g. with the container current-stats as in draft-mirsky-ippm-twamp-light-yang-03; - purpose of parent_connection_XXX in session_reflector is not clear to me. According to the last paragraph of section 4.4 four-tuple {parent-connection-client-ip, parent-connection-client-tcp-port, parent-connection-server-ip, parent-connection-server-tcp-port} define the test session but that, in my view, is only in some scenarios when TWAMP-Test session instantiated via TWAMP-Control. I believe that in SDN environment, where TWAMP-Control use is not required, identities of Control Client and the Server are not used; - grouping maintenance-statistics used in both session-sender and session-reflector. If the purpose of the grouping to provide information about the measured parameters, then, in my view, it is too limited and should be extended. If the grouping is to provide information for debugging, then it seems as more proprietary rather than standard data. Regards, Greg --001a1142e364d2f64e053bed6149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors, All
in our meeting in Berlin I've sh= ared my concern with the=C2=A0draft-ietf-ippm-twamp-yang. These are my comm= ents:
  • Figure 2 presents view of how YANG data model my be= used. I believe that in SDN environment the Orchestrator may act more like= described in=C2=A0draft-mirsky-ippm-twamp-light-yang-03 Figure 1 where Ses= sion-Sender and Session-Reflector are configured directly without Server an= d Control-Client by the single SDN controller/configuration client;
    • even though TWAMP-Control is optional, one possible solution to control TW= AMP-Test, TWAMP-Test dataa model depends on TWAMP-Control data model. For e= xample:
          leaf ctrl-conn=
ection-name {
            type string;
            config false;
            description
              "The name of the parent TWAMP-Control connection that
              is responsible for negotiating this TWAMP-Test session."=
;
          }

in list test-session, which is in session-sender;
  • as I look into session-sender YANG model I don't see it= contains sender-ip, sender-udp-= port,=C2=A0reflector-ip, reflect= or-udp-port, and=C2=A0test-packe= t-dscp. I believe that without these session-sender cannot be used to insta= ntiate TWAMP test session without the TWAMP-Control;
  • I think that the test session state informatio= n provided by=C2=A0maintenance-statisti= cs=C2=A0should be extended, e.g.= with the container current-stats as in=C2=A0draft-mirsky-ippm-twamp-light-= yang-03;
  • purp= ose of parent_connection_XXX in session_reflector is not clear to me. Accor= ding to the last paragraph of section 4.4 four-tuple=C2=A0{parent-connection-client-ip, parent-connection-c= lient-tcp-port, parent-connectio= n-server-ip, parent-connection-server-tcp-port} define the test session but= that, in my view, is only in some scenarios when TWAMP-Test session instan= tiated via TWAMP-Control. I believe that in SDN=C2=A0environment, where TWA= MP-Control=C2=A0use is not required, identities of Control Client and the S= erver are not used;
  • grou= ping=C2=A0maintenance-statistics used in both session-sender and session-re= flector. If the purpose of the grouping to provide information about the me= asured parameters, then, in my view, it is too limited and should be extend= ed. If the grouping is to provide information for debugging, then it seems = as more=C2=A0proprietary=C2=A0rather than standard data.
Regards, Greg

<= /div>
--001a1142e364d2f64e053bed6149-- From nobody Tue Sep 13 15:58:59 2016 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF90012B090; Tue, 13 Sep 2016 15:58:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147380753470.13027.5569647139961894728.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 15:58:54 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 22:58:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-04.txt Pages : 29 Date : 2016-09-13 Abstract: To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 13 16:04:59 2016 Return-Path: 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 7FF0F12B02F for ; Tue, 13 Sep 2016 16:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 SEnJiykZsW0n for ; Tue, 13 Sep 2016 16:04:55 -0700 (PDT) Received: from nm4-vm1.bullet.mail.ne1.yahoo.com (nm4-vm1.bullet.mail.ne1.yahoo.com [98.138.91.44]) (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 391E112B008 for ; Tue, 13 Sep 2016 16:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473807894; bh=wXSt6Xdiv7e8vFDPQp9Za3W215hWjNLdIYAGVwl8RAk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cX5ixf6kK4otKyNviEBPwvyS5790aJYVrHMn4njBIxM+/If07cky+Yd5a4yrJXWGa0ZREQs8Zh3L6pQAfgL5CNE6k9Ip0Uwr3t4IAo3f6ihPJ64JIMN/lwBXG4I1X7/Bpz1n2OPKHZeqYHjANZtHUbjdu1zo+IAT7ISuY9ZhESuMrp9jtxxIOJMpL6LPYHB0An8WzWaeJPg305ASDNSjUqOjMbZ28i5FqawcvZA/ApR/4DTRFYQu/lwz82gv7psFCaG0CJhqsRuQK2P0IKq3ogP1XeNj78B9GiWn+/3hc09h1qavxv9tbO94kY7xxM7ouhdukBLN+hcdRHwHppyYNg== Received: from [98.138.100.103] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2016 23:04:54 -0000 Received: from [98.138.86.156] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2016 23:04:54 -0000 Received: from [127.0.0.1] by omp1014.mail.ne1.yahoo.com with NNFMP; 13 Sep 2016 23:04:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 410937.78604.bm@omp1014.mail.ne1.yahoo.com X-YMail-OSG: rNQGPnsVM1kISe81ANn3pc_E0UjYbau0InHjCvckc6_hic4X.3jF6_iB6u6w9va DnN2901Ti5peU0oWFrW1.m1bPpABltUGMtm5nIgH1Rw0RTca517tZGPsIy67ExnHqo0RsbfvkYwk V95aeoPUIMFFmwCdlGBCGAn5u4Dsmt7HUkSh6YGlc_2Ik3Hw7.WAMGpt_KNwb7Sgg8s7a1lGbK.C uwqkG8SVxKyjufmUF6BAUtgoDUL3UcxFQ36g7MH7pHdfVinjvVlZ0.pBM3gUSIr4C_VrNl.I2rUj twjSSyWsjk919TKdOd1Q3EfSbqTzCvO_UswP7YkE3T_h_nvdkcJALOwBHflMJbYwpM4KsQ5jdVs_ nwkcBLexTA92ppyKB9bKuu999OSQdC196c_oWpIvJIW5lfSVEp3PudAR2GfJqLfJrTtrrf05jzfn axyvRkS8B1MQl2d0XthxiMmW7ufE4KZ7belCenqj8wobnXJYzVfija5bLJW1Fj.6pR_21rW79Om6 tJZRNOOoKwJY52d01.aplL7eWrUIK3DCydhyad5fuNnWcL.sztqyZ.80VOPsxaWH42Nhdl_ENGjH 9FndxW4fmHPEdmljABw-- Received: from jws100201.mail.ne1.yahoo.com by sendmailws152.mail.ne1.yahoo.com; Tue, 13 Sep 2016 23:04:54 +0000; 1473807894.019 Date: Tue, 13 Sep 2016 23:04:50 +0000 (UTC) From: To: Spencer Dawkins at IETF , "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "MORTON ALFRED C (AL)" Message-ID: <881483676.498721.1473807890669@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 23:04:57 -0000 Spencer, We have (we believe!) addressed your comments as well as those from Al Morton as document shepherd. The new version is at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-04 We have added quite a bit to the Security Considerations. We have started implementation of PDM in the FreeBSD kernel, as I might have mentioned before. It has shed quite a bit of light on the potential hazards which may come up as far as DOS attacks, etc. That was helpful to us in doing the Security Considerations. Many thanks to both you and Al Morton for your help and comments. - Nalini Elkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Hamilton) Inside Products, Inc. www.insidethestack.com (831) 659-8360 ________________________________ From: Spencer Dawkins at IETF To: draft-ietf-ippm-6man-pdm-option@tools.ietf.org Cc: ippm@ietf.org Sent: Monday, August 22, 2016 5:37 PM Subject: AD review of draft-ietf-ippm-6man-pdm-option-03 Dear Authors, Nice work, and this would have been very valuable when I was implementing performance monitors at Tektronix, so I imagine it's equally valuable now. I do have some comments that I'd like you let you consider before I request IETF Last Call for this draft. Please let me know if you have any questions, of course. Thanks, Spencer I saw the abstract following the table of contents mentioned in the shepherd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says A Table of Contents (TOC) is required in all RFCs. It must be positioned after the Copyright Notice and before the Introduction. It's probably a good thing to use the organization from RFC 7322, just to sidestep reviewers who start out complaining about document structure nits and then keep on typing. Not that I ever did that in six years as a Gen-ART reviwer, of course :-) ... I probably lack imagination, but perhaps other readers will, also. In this text DELTATLR = Send time packet 2 - Receive time packet 1 and Delta Time Last Sent = Receive time packet 2 - Send time packet 1 these are mathematical expressions, aren't they? If so, that would likely be clearer if the right side terms had parentheses around the expression. (It's a bit odd that the first expression uses the abbreviation DELTATLR and the second term is spelled out as "Delta Time Last Sent" - you might think about which seems clearer, and do that with both expressions) In text like this We propose a base unit for the time. you probably want to use a verb like "specify" (when the draft is published as an RFC, it will no longer be a proposal). There are multiple occurrences of "propose" in the document, so this comment applies in multiple places. For this text Assume that two packets are sent for each ACK from the server. you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. In this text from 6.3 PDM Flow - Multiple Send with Errors One might wonder if all of the functions of PDM might be better suited to TCP or a TCP option. that's an interesting point in the broader sense, because (duh) putting PDM in a TCP option doesn't help you with any other transport protocol (SCTP, QUIC, what else are we doing these days? and, of course, they're all running over UDP anyway). I wonder if that's worth pointing out earlier in the document, perhaps in Section 1.4? This text Let's say that packet 4 STILL does not make it. is probably too breezy to translate well into other languages. Perhaps "is also lost"? (Yes, I talk like this, too) In the Security Considerations section, you might want to say something about (1) what watching the unencrypted PDM values might tell attackers that are doing pervasive monitoring (RFC 7258), and possibly about (2) what happens if PDM is used as a covert channel. I don't think either of these will be showstoppers at SECDIR review time, but I'd expect that demonstrating awareness of at least (1) will shorten the review comments cycle. Possibly a lot, judging by recent ballots on other drafts ... From nobody Tue Sep 13 16:54:37 2016 Return-Path: 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 3DEB112B146 for ; Tue, 13 Sep 2016 16:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-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 uoRUxceqBicM for ; Tue, 13 Sep 2016 16:54:31 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 157E812B14A for ; Tue, 13 Sep 2016 16:54:22 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u82so1344621ywc.2 for ; Tue, 13 Sep 2016 16:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5PICLiJ174YDca+EgdUly6RM0YlJzNITrzbvuPrh7I4=; b=DKR20kBgNbqCUo8nvNSfdOWhtIY3BzsNL2pR3+Nnu9rXUNGRQJjBFlQpTq5q+UnUjt ++4EdBtFmQyRWTi0lzx1OsAO8Js+xQz9M3EsmgyuVMaNBVR3jiB512QJ3quPJQVUdLrP rrvaSd9teqIy9PvD41sDNig5PEV+b6zEjy9FGy5h/fo1Cl0r1akFpRyWzk08vjsIE+rL lasUPsm4diN6zGnY4d9gTvx6DGU34TPwYaW5S7IL4W11cWjyfEMWxjO7m75/EBHZtO3I kX2UCW8JdTlnu/pH2quRYuJS5F2vZKuowhLFF3CK0/24l1Dp9ngP/PJjI1fzVIyWsG3Z ijbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5PICLiJ174YDca+EgdUly6RM0YlJzNITrzbvuPrh7I4=; b=JAEkdlb6C5CkpKe1f7EjibLqvLiMpqZ5pEqgXRcvpaIS+AXFHXUp8/pd8rSoxQdMQR UpbpOTgzP/JgiTX6c96KelnM3PoIa+R7vUqb8l1O8rIU9t8cO4wlo3miqi2tbtqzkeD0 h/ib7xoneORlzmy1jObInM5dWDLYiSAtJ+XEcWBMEApLBsU+rkPJtG4hEw+9uPxbS61o C2rci8zKlbJp5P4JI3XeNFy7lJuzW36br69fdF0LphNab2ihinHAu3Suw+d9j6E/wHAM qH5rgS+w1p9MVVg90b9jLKqTq+47h6cwBJYxerWzDb3IsluwRcVoaUlbHQ67fO8eur+q kmgA== X-Gm-Message-State: AE9vXwP/UtcyB/emamjyTuZO4zUb/5kokpgpR49pdXiEkwaRp5hlsg7qP9Tmz2xZkwsYRwiXsjzOmtaIu4uNDQ== X-Received: by 10.129.106.5 with SMTP id f5mr3613343ywc.208.1473810861156; Tue, 13 Sep 2016 16:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Tue, 13 Sep 2016 16:54:20 -0700 (PDT) Received: by 10.37.24.86 with HTTP; Tue, 13 Sep 2016 16:54:20 -0700 (PDT) In-Reply-To: <881483676.498721.1473807890669@mail.yahoo.com> References: <881483676.498721.1473807890669@mail.yahoo.com> From: Spencer Dawkins at IETF Date: Tue, 13 Sep 2016 18:54:20 -0500 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=001a11473d8ad870c0053c6c5494 Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , acmorton@att.com, ippm@ietf.org Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 23:54:36 -0000 --001a11473d8ad870c0053c6c5494 Content-Type: text/plain; charset=UTF-8 Nalini, On Sep 13, 2016 18:04, wrote: > > Spencer, > > We have (we believe!) addressed your comments as well as those from Al Morton as document shepherd. > > The new version is at: > > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-04 > > We have added quite a bit to the Security Considerations. We have started implementation of PDM in the FreeBSD kernel, as I might have mentioned before. It has shed quite a bit of light on the potential hazards which may come up as far as DOS attacks, etc. That was helpful to us in doing the Security Considerations. > > Many thanks to both you and Al Morton for your help and comments. I'm happy. Al, is this version ready for IETF Last Call? Thanks, Spencer > - Nalini Elkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Hamilton) > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ________________________________ > From: Spencer Dawkins at IETF > To: draft-ietf-ippm-6man-pdm-option@tools.ietf.org > Cc: ippm@ietf.org > Sent: Monday, August 22, 2016 5:37 PM > Subject: AD review of draft-ietf-ippm-6man-pdm-option-03 > > > > Dear Authors, > > Nice work, and this would have been very valuable when I was implementing performance monitors at Tektronix, so I imagine it's equally valuable now. > > I do have some comments that I'd like you let you consider before I request IETF Last Call for this draft. Please let me know if you have any questions, of course. > > Thanks, > > Spencer > > I saw the abstract following the table of contents mentioned in the shepherd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says > > A Table of Contents (TOC) is required in all RFCs. It must be > positioned after the Copyright Notice and before the Introduction. > > It's probably a good thing to use the organization from RFC 7322, just to sidestep reviewers who start out complaining about document structure nits and then keep on typing. Not that I ever did that in six years as a Gen-ART reviwer, of course :-) ... > > I probably lack imagination, but perhaps other readers will, also. > > In this text > > DELTATLR = Send time packet 2 - Receive time packet 1 > > and > > Delta Time Last Sent = Receive time packet 2 - Send time packet 1 > > these are mathematical expressions, aren't they? If so, that would likely be clearer if the right side terms had parentheses around the expression. > > (It's a bit odd that the first expression uses the abbreviation DELTATLR and the second term is spelled out as "Delta Time Last Sent" - you might think about which seems clearer, and do that with both expressions) > > In text like this > > We propose a base unit for the time. > > you probably want to use a verb like "specify" (when the draft is published as an RFC, it will no longer be a proposal). There are multiple occurrences of "propose" in the document, so this comment applies in multiple places. > > For this text > > Assume that two packets are sent for each ACK from the server. > > you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. > > In this text from 6.3 PDM Flow - Multiple Send with Errors > > One might wonder if all of the functions of PDM might be better > suited to TCP or a TCP option. > > that's an interesting point in the broader sense, because (duh) putting PDM in a TCP option doesn't help you with any other transport protocol (SCTP, QUIC, what else are we doing these days? and, of course, they're all running over UDP anyway). I wonder if that's worth pointing out earlier in the document, perhaps in Section 1.4? > > This text > > Let's say that packet 4 STILL does not make it. > > is probably too breezy to translate well into other languages. Perhaps "is also lost"? (Yes, I talk like this, too) > > In the Security Considerations section, you might want to say something about (1) what watching the unencrypted PDM values might tell attackers that are doing pervasive monitoring (RFC 7258), and possibly about (2) what happens if PDM is used as a covert channel. I don't think either of these will be showstoppers at SECDIR review time, but I'd expect that demonstrating awareness of at least (1) will shorten the review comments cycle. Possibly a lot, judging by recent ballots on other drafts ... --001a11473d8ad870c0053c6c5494 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Nalini,

On Sep 13, 2016 18:04, <nalini.elkins@insidethestack.com> wrote:
>
> Spencer,
>
> We have (we believe!) addressed your comments as well as those from Al= Morton as document shepherd.
>
> The new version is at:
>
> https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-04
>
> We have added quite a bit to the Security Considerations.=C2=A0 We hav= e started implementation of PDM in the FreeBSD kernel, as I might have ment= ioned before.=C2=A0 =C2=A0It has shed quite a bit of light on the potential= hazards which may come up as far as DOS attacks, etc.=C2=A0 =C2=A0That was= helpful to us in doing the Security Considerations.
>
> Many thanks to both you and Al Morton for your help and comments.

I'm happy. Al, is this version ready for IETF Last Call?=

Thanks,

Spencer

> - Nalini Elkins - on behalf of the PDM co-authors (Mike= Ackermann and Rob Hamilton)
> Inside Products, Inc.
> www.insidethestack.com > (831) 659-8360
>
>
>
> ________________________________
> From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> To: = draft-ietf-ippm-6man-pdm-option@tools.ietf.org
> Cc: ippm@ietf.org
> Sent: Monday, August 22, 2016 5:37 PM
> Subject: AD review of draft-ietf-ippm-6man-pdm-option-03
>
>
>
> Dear Authors,
>
> Nice work, and this would have been very valuable when I was implement= ing performance monitors at Tektronix, so I imagine it's equally valuab= le now.
>
> I do have some comments that I'd like you let you consider before = I request IETF Last Call for this draft. Please let me know if you have any= questions, of course.
>
> Thanks,
>
> Spencer
>
> I saw the abstract following the table of contents mentioned in the sh= epherd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says
>
> =C2=A0 =C2=A0A Table of Contents (TOC) is required in all RFCs.=C2=A0 = It must be
> =C2=A0 =C2=A0positioned after the Copyright Notice and before the Intr= oduction.
>
> It's probably a good thing to use the organization from RFC 7322, = just to sidestep reviewers who start out complaining about document structu= re nits and then keep on typing. Not that I ever did that in six years as a= Gen-ART reviwer, of course :-) ...
>
> I probably lack imagination, but perhaps other readers will, also.
>
> In this text
>
> =C2=A0 =C2=A0DELTATLR =3D Send time packet 2 - Receive time packet 1 >
> and
>
> =C2=A0 =C2=A0Delta Time Last Sent =3D Receive time packet 2 - Send tim= e packet 1
>
> these are mathematical expressions, aren't they? If so, that would= likely be clearer if the right side terms had parentheses around the expre= ssion.
>
> (It's a bit odd that the first expression uses the abbreviation DE= LTATLR and the second term is spelled out as "Delta Time Last Sent&quo= t; - you might think about which seems clearer, and do that with both expre= ssions)
>
> In text like this
>
> =C2=A0 =C2=A0We propose a base unit for the time.
>
> you probably want to use a verb like "specify" (when the dra= ft is published as an RFC, it will no longer be a proposal). There are mult= iple occurrences of "propose" in the document, so this comment ap= plies in multiple places.
>
> For this text
>
> =C2=A0 =C2=A0Assume that two packets are sent for each ACK from the se= rver.
>
> you might point out that TCP does this, per RFC 1122 Section 4.2.3.2.<= br> >
> In this text from 6.3 PDM Flow - Multiple Send with Errors
>
> =C2=A0 =C2=A0One might wonder if all of the functions of PDM might be = better
> =C2=A0 =C2=A0suited to TCP or a TCP option.
>
> that's an interesting point in the broader sense, because (duh) pu= tting PDM in a TCP option doesn't help you with any other transport pro= tocol (SCTP, QUIC, what else are we doing these days? and, of course, they&= #39;re all running over UDP anyway). I wonder if that's worth pointing = out earlier in the document, perhaps in Section 1.4?
>
> This text
>
> =C2=A0 =C2=A0Let's say that packet 4 STILL does not make it.
>
> is probably too breezy to translate well into other languages. Perhaps= "is also lost"? (Yes, I talk like this, too)
>
> In the Security Considerations section, you might want to say somethin= g about (1) what watching the unencrypted PDM values might tell attackers t= hat are doing pervasive monitoring (RFC 7258), and possibly about (2) what = happens if PDM is used as a covert channel. I don't think either of the= se will be showstoppers at SECDIR review time, but I'd expect that demo= nstrating awareness of at least (1) will shorten the review comments cycle.= Possibly a lot, judging by recent ballots on other drafts ...

--001a11473d8ad870c0053c6c5494-- From nobody Tue Sep 13 19:07:56 2016 Return-Path: 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 47FED12B462 for ; Tue, 13 Sep 2016 19:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 sfrR1E9eDWcF for ; Tue, 13 Sep 2016 19:07:52 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBBF12B17F for ; Tue, 13 Sep 2016 19:07:52 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 743C4120545; Tue, 13 Sep 2016 22:21:58 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-blue.research.att.com (Postfix) with ESMTP id 105F7404FCD; Tue, 13 Sep 2016 22:07:52 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Tue, 13 Sep 2016 22:07:51 -0400 From: "MORTON, ALFRED C (AL)" To: Spencer Dawkins at IETF , Nalini Elkins Date: Tue, 13 Sep 2016 22:07:50 -0400 Thread-Topic: AD review of draft-ietf-ippm-6man-pdm-option-03 Thread-Index: AdIOGiez785acovvTVG3xpa2o3CfDwAEoA6A Message-ID: <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> References: <881483676.498721.1473807890669@mail.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D4598DC73CFNJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 02:07:55 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D4598DC73CFNJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIGNoZWNrIGZpcnN0IHRoaW5nIHRvbW9ycm93LA0KdGhhbmtzIQ0KQWwNCg0KRnJvbTog U3BlbmNlciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWls LmNvbV0NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNiA3OjU0IFBNDQpUbzogTmFs aW5pIEVsa2lucw0KQ2M6IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgaXBwbUBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbkB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6 IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uLTAzDQoNCg0KTmFs aW5pLA0KDQpPbiBTZXAgMTMsIDIwMTYgMTg6MDQsIDxuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0 YWNrLmNvbTxtYWlsdG86bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20+PiB3cm90ZToN Cj4NCj4gU3BlbmNlciwNCj4NCj4gV2UgaGF2ZSAod2UgYmVsaWV2ZSEpIGFkZHJlc3NlZCB5b3Vy IGNvbW1lbnRzIGFzIHdlbGwgYXMgdGhvc2UgZnJvbSBBbCBNb3J0b24gYXMgZG9jdW1lbnQgc2hl cGhlcmQuDQo+DQo+IFRoZSBuZXcgdmVyc2lvbiBpcyBhdDoNCj4NCj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb24tMDQNCj4NCj4gV2Ug aGF2ZSBhZGRlZCBxdWl0ZSBhIGJpdCB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuICBX ZSBoYXZlIHN0YXJ0ZWQgaW1wbGVtZW50YXRpb24gb2YgUERNIGluIHRoZSBGcmVlQlNEIGtlcm5l bCwgYXMgSSBtaWdodCBoYXZlIG1lbnRpb25lZCBiZWZvcmUuICAgSXQgaGFzIHNoZWQgcXVpdGUg YSBiaXQgb2YgbGlnaHQgb24gdGhlIHBvdGVudGlhbCBoYXphcmRzIHdoaWNoIG1heSBjb21lIHVw IGFzIGZhciBhcyBET1MgYXR0YWNrcywgZXRjLiAgIFRoYXQgd2FzIGhlbHBmdWwgdG8gdXMgaW4g ZG9pbmcgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLg0KPg0KPiBNYW55IHRoYW5rcyB0byBi b3RoIHlvdSBhbmQgQWwgTW9ydG9uIGZvciB5b3VyIGhlbHAgYW5kIGNvbW1lbnRzLg0KDQpJJ20g aGFwcHkuIEFsLCBpcyB0aGlzIHZlcnNpb24gcmVhZHkgZm9yIElFVEYgTGFzdCBDYWxsPw0KDQpU aGFua3MsDQoNClNwZW5jZXINCg0KPiAtIE5hbGluaSBFbGtpbnMgLSBvbiBiZWhhbGYgb2YgdGhl IFBETSBjby1hdXRob3JzIChNaWtlIEFja2VybWFubiBhbmQgUm9iIEhhbWlsdG9uKQ0KPiBJbnNp ZGUgUHJvZHVjdHMsIEluYy4NCj4gd3d3Lmluc2lkZXRoZXN0YWNrLmNvbTxodHRwOi8vd3d3Lmlu c2lkZXRoZXN0YWNrLmNvbT4NCj4gKDgzMSkgNjU5LTgzNjANCj4NCj4NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogU3BlbmNlciBEYXdraW5zIGF0IElFVEYg PHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRm QGdtYWlsLmNvbT4+DQo+IFRvOiBkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQHRvb2xzLmll dGYub3JnPg0KPiBDYzogaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4NCj4gU2Vu dDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTYgNTozNyBQTQ0KPiBTdWJqZWN0OiBBRCByZXZpZXcg b2YgZHJhZnQtaWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbi0wMw0KPg0KPg0KPg0KPiBEZWFyIEF1 dGhvcnMsDQo+DQo+IE5pY2Ugd29yaywgYW5kIHRoaXMgd291bGQgaGF2ZSBiZWVuIHZlcnkgdmFs dWFibGUgd2hlbiBJIHdhcyBpbXBsZW1lbnRpbmcgcGVyZm9ybWFuY2UgbW9uaXRvcnMgYXQgVGVr dHJvbml4LCBzbyBJIGltYWdpbmUgaXQncyBlcXVhbGx5IHZhbHVhYmxlIG5vdy4NCj4NCj4gSSBk byBoYXZlIHNvbWUgY29tbWVudHMgdGhhdCBJJ2QgbGlrZSB5b3UgbGV0IHlvdSBjb25zaWRlciBi ZWZvcmUgSSByZXF1ZXN0IElFVEYgTGFzdCBDYWxsIGZvciB0aGlzIGRyYWZ0LiBQbGVhc2UgbGV0 IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucywgb2YgY291cnNlLg0KPg0KPiBUaGFu a3MsDQo+DQo+IFNwZW5jZXINCj4NCj4gSSBzYXcgdGhlIGFic3RyYWN0IGZvbGxvd2luZyB0aGUg dGFibGUgb2YgY29udGVudHMgbWVudGlvbmVkIGluIHRoZSBzaGVwaGVyZCB3cml0ZS11cCwgYnV0 IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MzIyI3NlY3Rpb24tNC43IHNheXMNCj4N Cj4gICAgQSBUYWJsZSBvZiBDb250ZW50cyAoVE9DKSBpcyByZXF1aXJlZCBpbiBhbGwgUkZDcy4g IEl0IG11c3QgYmUNCj4gICAgcG9zaXRpb25lZCBhZnRlciB0aGUgQ29weXJpZ2h0IE5vdGljZSBh bmQgYmVmb3JlIHRoZSBJbnRyb2R1Y3Rpb24uDQo+DQo+IEl0J3MgcHJvYmFibHkgYSBnb29kIHRo aW5nIHRvIHVzZSB0aGUgb3JnYW5pemF0aW9uIGZyb20gUkZDIDczMjIsIGp1c3QgdG8gc2lkZXN0 ZXAgcmV2aWV3ZXJzIHdobyBzdGFydCBvdXQgY29tcGxhaW5pbmcgYWJvdXQgZG9jdW1lbnQgc3Ry dWN0dXJlIG5pdHMgYW5kIHRoZW4ga2VlcCBvbiB0eXBpbmcuIE5vdCB0aGF0IEkgZXZlciBkaWQg dGhhdCBpbiBzaXggeWVhcnMgYXMgYSBHZW4tQVJUIHJldml3ZXIsIG9mIGNvdXJzZSA6LSkgLi4u DQo+DQo+IEkgcHJvYmFibHkgbGFjayBpbWFnaW5hdGlvbiwgYnV0IHBlcmhhcHMgb3RoZXIgcmVh ZGVycyB3aWxsLCBhbHNvLg0KPg0KPiBJbiB0aGlzIHRleHQNCj4NCj4gICAgREVMVEFUTFIgPSBT ZW5kIHRpbWUgcGFja2V0IDIgLSBSZWNlaXZlIHRpbWUgcGFja2V0IDENCj4NCj4gYW5kDQo+DQo+ ICAgIERlbHRhIFRpbWUgTGFzdCBTZW50ID0gUmVjZWl2ZSB0aW1lIHBhY2tldCAyIC0gU2VuZCB0 aW1lIHBhY2tldCAxDQo+DQo+IHRoZXNlIGFyZSBtYXRoZW1hdGljYWwgZXhwcmVzc2lvbnMsIGFy ZW4ndCB0aGV5PyBJZiBzbywgdGhhdCB3b3VsZCBsaWtlbHkgYmUgY2xlYXJlciBpZiB0aGUgcmln aHQgc2lkZSB0ZXJtcyBoYWQgcGFyZW50aGVzZXMgYXJvdW5kIHRoZSBleHByZXNzaW9uLg0KPg0K PiAoSXQncyBhIGJpdCBvZGQgdGhhdCB0aGUgZmlyc3QgZXhwcmVzc2lvbiB1c2VzIHRoZSBhYmJy ZXZpYXRpb24gREVMVEFUTFIgYW5kIHRoZSBzZWNvbmQgdGVybSBpcyBzcGVsbGVkIG91dCBhcyAi RGVsdGEgVGltZSBMYXN0IFNlbnQiIC0geW91IG1pZ2h0IHRoaW5rIGFib3V0IHdoaWNoIHNlZW1z IGNsZWFyZXIsIGFuZCBkbyB0aGF0IHdpdGggYm90aCBleHByZXNzaW9ucykNCj4NCj4gSW4gdGV4 dCBsaWtlIHRoaXMNCj4NCj4gICAgV2UgcHJvcG9zZSBhIGJhc2UgdW5pdCBmb3IgdGhlIHRpbWUu DQo+DQo+IHlvdSBwcm9iYWJseSB3YW50IHRvIHVzZSBhIHZlcmIgbGlrZSAic3BlY2lmeSIgKHdo ZW4gdGhlIGRyYWZ0IGlzIHB1Ymxpc2hlZCBhcyBhbiBSRkMsIGl0IHdpbGwgbm8gbG9uZ2VyIGJl IGEgcHJvcG9zYWwpLiBUaGVyZSBhcmUgbXVsdGlwbGUgb2NjdXJyZW5jZXMgb2YgInByb3Bvc2Ui IGluIHRoZSBkb2N1bWVudCwgc28gdGhpcyBjb21tZW50IGFwcGxpZXMgaW4gbXVsdGlwbGUgcGxh Y2VzLg0KPg0KPiBGb3IgdGhpcyB0ZXh0DQo+DQo+ICAgIEFzc3VtZSB0aGF0IHR3byBwYWNrZXRz IGFyZSBzZW50IGZvciBlYWNoIEFDSyBmcm9tIHRoZSBzZXJ2ZXIuDQo+DQo+IHlvdSBtaWdodCBw b2ludCBvdXQgdGhhdCBUQ1AgZG9lcyB0aGlzLCBwZXIgUkZDIDExMjIgU2VjdGlvbiA0LjIuMy4y Lg0KPg0KPiBJbiB0aGlzIHRleHQgZnJvbSA2LjMgUERNIEZsb3cgLSBNdWx0aXBsZSBTZW5kIHdp dGggRXJyb3JzDQo+DQo+ICAgIE9uZSBtaWdodCB3b25kZXIgaWYgYWxsIG9mIHRoZSBmdW5jdGlv bnMgb2YgUERNIG1pZ2h0IGJlIGJldHRlcg0KPiAgICBzdWl0ZWQgdG8gVENQIG9yIGEgVENQIG9w dGlvbi4NCj4NCj4gdGhhdCdzIGFuIGludGVyZXN0aW5nIHBvaW50IGluIHRoZSBicm9hZGVyIHNl bnNlLCBiZWNhdXNlIChkdWgpIHB1dHRpbmcgUERNIGluIGEgVENQIG9wdGlvbiBkb2Vzbid0IGhl bHAgeW91IHdpdGggYW55IG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbCAoU0NUUCwgUVVJQywgd2hh dCBlbHNlIGFyZSB3ZSBkb2luZyB0aGVzZSBkYXlzPyBhbmQsIG9mIGNvdXJzZSwgdGhleSdyZSBh bGwgcnVubmluZyBvdmVyIFVEUCBhbnl3YXkpLiBJIHdvbmRlciBpZiB0aGF0J3Mgd29ydGggcG9p bnRpbmcgb3V0IGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50LCBwZXJoYXBzIGluIFNlY3Rpb24gMS40 Pw0KPg0KPiBUaGlzIHRleHQNCj4NCj4gICAgTGV0J3Mgc2F5IHRoYXQgcGFja2V0IDQgU1RJTEwg ZG9lcyBub3QgbWFrZSBpdC4NCj4NCj4gaXMgcHJvYmFibHkgdG9vIGJyZWV6eSB0byB0cmFuc2xh dGUgd2VsbCBpbnRvIG90aGVyIGxhbmd1YWdlcy4gUGVyaGFwcyAiaXMgYWxzbyBsb3N0Ij8gKFll cywgSSB0YWxrIGxpa2UgdGhpcywgdG9vKQ0KPg0KPiBJbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiwgeW91IG1pZ2h0IHdhbnQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCAoMSkg d2hhdCB3YXRjaGluZyB0aGUgdW5lbmNyeXB0ZWQgUERNIHZhbHVlcyBtaWdodCB0ZWxsIGF0dGFj a2VycyB0aGF0IGFyZSBkb2luZyBwZXJ2YXNpdmUgbW9uaXRvcmluZyAoUkZDIDcyNTgpLCBhbmQg cG9zc2libHkgYWJvdXQgKDIpIHdoYXQgaGFwcGVucyBpZiBQRE0gaXMgdXNlZCBhcyBhIGNvdmVy dCBjaGFubmVsLiBJIGRvbid0IHRoaW5rIGVpdGhlciBvZiB0aGVzZSB3aWxsIGJlIHNob3dzdG9w cGVycyBhdCBTRUNESVIgcmV2aWV3IHRpbWUsIGJ1dCBJJ2QgZXhwZWN0IHRoYXQgZGVtb25zdHJh dGluZyBhd2FyZW5lc3Mgb2YgYXQgbGVhc3QgKDEpIHdpbGwgc2hvcnRlbiB0aGUgcmV2aWV3IGNv bW1lbnRzIGN5Y2xlLiBQb3NzaWJseSBhIGxvdCwganVkZ2luZyBieSByZWNlbnQgYmFsbG90cyBv biBvdGhlciBkcmFmdHMgLi4uDQo= --_000_4AF73AA205019A4C8A1DDD32C034631D4598DC73CFNJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv aGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1X b3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPknigJlsbCBjaGVjayBm aXJzdCB0aGluZyB0b21vcnJvdyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6YmxhY2snPnRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6YmxhY2snPkFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gU3BlbmNlciBEYXdraW5zIGF0 IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0gPGJyPjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTYgNzo1NCBQTTxicj48Yj5Ubzo8L2I+IE5h bGluaSBFbGtpbnM8YnI+PGI+Q2M6PC9iPiBNT1JUT04sIEFMRlJFRCBDIChBTCk7IGlwcG1AaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb25AdG9vbHMuaWV0Zi5vcmc8YnI+ PGI+U3ViamVjdDo8L2I+IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHBtLTZtYW4tcGRt LW9wdGlvbi0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHA+TmFsaW5pLCA8bzpwPjwvbzpwPjwvcD48cD5P biBTZXAgMTMsIDIwMTYgMTg6MDQsICZsdDs8YSBocmVmPSJtYWlsdG86bmFsaW5pLmVsa2luc0Bp bnNpZGV0aGVzdGFjay5jb20iPm5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPC9hPiZn dDsgd3JvdGU6PGJyPiZndDs8YnI+Jmd0OyBTcGVuY2VyLDxicj4mZ3Q7PGJyPiZndDsgV2UgaGF2 ZSAod2UgYmVsaWV2ZSEpIGFkZHJlc3NlZCB5b3VyIGNvbW1lbnRzIGFzIHdlbGwgYXMgdGhvc2Ug ZnJvbSBBbCBNb3J0b24gYXMgZG9jdW1lbnQgc2hlcGhlcmQuPGJyPiZndDs8YnI+Jmd0OyBUaGUg bmV3IHZlcnNpb24gaXMgYXQ6PGJyPiZndDs8YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbi0wNCI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb24tMDQ8 L2E+PGJyPiZndDs8YnI+Jmd0OyBXZSBoYXZlIGFkZGVkIHF1aXRlIGEgYml0IHRvIHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucy4mbmJzcDsgV2UgaGF2ZSBzdGFydGVkIGltcGxlbWVudGF0aW9u IG9mIFBETSBpbiB0aGUgRnJlZUJTRCBrZXJuZWwsIGFzIEkgbWlnaHQgaGF2ZSBtZW50aW9uZWQg YmVmb3JlLiZuYnNwOyAmbmJzcDtJdCBoYXMgc2hlZCBxdWl0ZSBhIGJpdCBvZiBsaWdodCBvbiB0 aGUgcG90ZW50aWFsIGhhemFyZHMgd2hpY2ggbWF5IGNvbWUgdXAgYXMgZmFyIGFzIERPUyBhdHRh Y2tzLCBldGMuJm5ic3A7ICZuYnNwO1RoYXQgd2FzIGhlbHBmdWwgdG8gdXMgaW4gZG9pbmcgdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLjxicj4mZ3Q7PGJyPiZndDsgTWFueSB0aGFua3MgdG8g Ym90aCB5b3UgYW5kIEFsIE1vcnRvbiBmb3IgeW91ciBoZWxwIGFuZCBjb21tZW50cy48bzpwPjwv bzpwPjwvcD48cD5JJ20gaGFwcHkuIEFsLCBpcyB0aGlzIHZlcnNpb24gcmVhZHkgZm9yIElFVEYg TGFzdCBDYWxsPzxvOnA+PC9vOnA+PC9wPjxwPlRoYW5rcywgPG86cD48L286cD48L3A+PHA+U3Bl bmNlcjxvOnA+PC9vOnA+PC9wPjxwPiZndDsgLSBOYWxpbmkgRWxraW5zIC0gb24gYmVoYWxmIG9m IHRoZSBQRE0gY28tYXV0aG9ycyAoTWlrZSBBY2tlcm1hbm4gYW5kIFJvYiBIYW1pbHRvbik8YnI+ Jmd0OyBJbnNpZGUgUHJvZHVjdHMsIEluYy48YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3Lmlu c2lkZXRoZXN0YWNrLmNvbSI+d3d3Lmluc2lkZXRoZXN0YWNrLmNvbTwvYT48YnI+Jmd0OyAoODMx KSA2NTktODM2MDxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPiZndDsgRnJvbTogU3BlbmNlciBEYXdraW5zIGF0IElFVEYg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSI+c3BlbmNl cmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4mZ3Q7IFRvOiA8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbkB0b29scy5pZXRmLm9yZyI+ZHJhZnQt aWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbkB0b29scy5pZXRmLm9yZzwvYT48YnI+Jmd0OyBDYzog PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciPmlwcG1AaWV0Zi5vcmc8L2E+PGJyPiZndDsg U2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTYgNTozNyBQTTxicj4mZ3Q7IFN1YmplY3Q6IEFE IHJldmlldyBvZiBkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uLTAzPGJyPiZndDs8YnI+ Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgRGVhciBBdXRob3JzLDxicj4mZ3Q7PGJyPiZndDsgTmljZSB3 b3JrLCBhbmQgdGhpcyB3b3VsZCBoYXZlIGJlZW4gdmVyeSB2YWx1YWJsZSB3aGVuIEkgd2FzIGlt cGxlbWVudGluZyBwZXJmb3JtYW5jZSBtb25pdG9ycyBhdCBUZWt0cm9uaXgsIHNvIEkgaW1hZ2lu ZSBpdCdzIGVxdWFsbHkgdmFsdWFibGUgbm93Ljxicj4mZ3Q7PGJyPiZndDsgSSBkbyBoYXZlIHNv bWUgY29tbWVudHMgdGhhdCBJJ2QgbGlrZSB5b3UgbGV0IHlvdSBjb25zaWRlciBiZWZvcmUgSSBy ZXF1ZXN0IElFVEYgTGFzdCBDYWxsIGZvciB0aGlzIGRyYWZ0LiBQbGVhc2UgbGV0IG1lIGtub3cg aWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucywgb2YgY291cnNlLjxicj4mZ3Q7PGJyPiZndDsgVGhh bmtzLDxicj4mZ3Q7PGJyPiZndDsgU3BlbmNlcjxicj4mZ3Q7PGJyPiZndDsgSSBzYXcgdGhlIGFi c3RyYWN0IGZvbGxvd2luZyB0aGUgdGFibGUgb2YgY29udGVudHMgbWVudGlvbmVkIGluIHRoZSBz aGVwaGVyZCB3cml0ZS11cCwgYnV0IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MzIyI3NlY3Rpb24tNC43Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzMy MiNzZWN0aW9uLTQuNzwvYT4gc2F5czxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwO0EgVGFi bGUgb2YgQ29udGVudHMgKFRPQykgaXMgcmVxdWlyZWQgaW4gYWxsIFJGQ3MuJm5ic3A7IEl0IG11 c3QgYmU8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7cG9zaXRpb25lZCBhZnRlciB0aGUgQ29weXJpZ2h0 IE5vdGljZSBhbmQgYmVmb3JlIHRoZSBJbnRyb2R1Y3Rpb24uPGJyPiZndDs8YnI+Jmd0OyBJdCdz IHByb2JhYmx5IGEgZ29vZCB0aGluZyB0byB1c2UgdGhlIG9yZ2FuaXphdGlvbiBmcm9tIFJGQyA3 MzIyLCBqdXN0IHRvIHNpZGVzdGVwIHJldmlld2VycyB3aG8gc3RhcnQgb3V0IGNvbXBsYWluaW5n IGFib3V0IGRvY3VtZW50IHN0cnVjdHVyZSBuaXRzIGFuZCB0aGVuIGtlZXAgb24gdHlwaW5nLiBO b3QgdGhhdCBJIGV2ZXIgZGlkIHRoYXQgaW4gc2l4IHllYXJzIGFzIGEgR2VuLUFSVCByZXZpd2Vy LCBvZiBjb3Vyc2UgOi0pIC4uLjxicj4mZ3Q7PGJyPiZndDsgSSBwcm9iYWJseSBsYWNrIGltYWdp bmF0aW9uLCBidXQgcGVyaGFwcyBvdGhlciByZWFkZXJzIHdpbGwsIGFsc28uPGJyPiZndDs8YnI+ Jmd0OyBJbiB0aGlzIHRleHQ8YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtERUxUQVRMUiA9 IFNlbmQgdGltZSBwYWNrZXQgMiAtIFJlY2VpdmUgdGltZSBwYWNrZXQgMTxicj4mZ3Q7PGJyPiZn dDsgYW5kPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7RGVsdGEgVGltZSBMYXN0IFNlbnQg PSBSZWNlaXZlIHRpbWUgcGFja2V0IDIgLSBTZW5kIHRpbWUgcGFja2V0IDE8YnI+Jmd0Ozxicj4m Z3Q7IHRoZXNlIGFyZSBtYXRoZW1hdGljYWwgZXhwcmVzc2lvbnMsIGFyZW4ndCB0aGV5PyBJZiBz bywgdGhhdCB3b3VsZCBsaWtlbHkgYmUgY2xlYXJlciBpZiB0aGUgcmlnaHQgc2lkZSB0ZXJtcyBo YWQgcGFyZW50aGVzZXMgYXJvdW5kIHRoZSBleHByZXNzaW9uLjxicj4mZ3Q7PGJyPiZndDsgKEl0 J3MgYSBiaXQgb2RkIHRoYXQgdGhlIGZpcnN0IGV4cHJlc3Npb24gdXNlcyB0aGUgYWJicmV2aWF0 aW9uIERFTFRBVExSIGFuZCB0aGUgc2Vjb25kIHRlcm0gaXMgc3BlbGxlZCBvdXQgYXMgJnF1b3Q7 RGVsdGEgVGltZSBMYXN0IFNlbnQmcXVvdDsgLSB5b3UgbWlnaHQgdGhpbmsgYWJvdXQgd2hpY2gg c2VlbXMgY2xlYXJlciwgYW5kIGRvIHRoYXQgd2l0aCBib3RoIGV4cHJlc3Npb25zKTxicj4mZ3Q7 PGJyPiZndDsgSW4gdGV4dCBsaWtlIHRoaXM8YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtX ZSBwcm9wb3NlIGEgYmFzZSB1bml0IGZvciB0aGUgdGltZS48YnI+Jmd0Ozxicj4mZ3Q7IHlvdSBw cm9iYWJseSB3YW50IHRvIHVzZSBhIHZlcmIgbGlrZSAmcXVvdDtzcGVjaWZ5JnF1b3Q7ICh3aGVu IHRoZSBkcmFmdCBpcyBwdWJsaXNoZWQgYXMgYW4gUkZDLCBpdCB3aWxsIG5vIGxvbmdlciBiZSBh IHByb3Bvc2FsKS4gVGhlcmUgYXJlIG11bHRpcGxlIG9jY3VycmVuY2VzIG9mICZxdW90O3Byb3Bv c2UmcXVvdDsgaW4gdGhlIGRvY3VtZW50LCBzbyB0aGlzIGNvbW1lbnQgYXBwbGllcyBpbiBtdWx0 aXBsZSBwbGFjZXMuPGJyPiZndDs8YnI+Jmd0OyBGb3IgdGhpcyB0ZXh0PGJyPiZndDs8YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7QXNzdW1lIHRoYXQgdHdvIHBhY2tldHMgYXJlIHNlbnQgZm9yIGVhY2gg QUNLIGZyb20gdGhlIHNlcnZlci48YnI+Jmd0Ozxicj4mZ3Q7IHlvdSBtaWdodCBwb2ludCBvdXQg dGhhdCBUQ1AgZG9lcyB0aGlzLCBwZXIgUkZDIDExMjIgU2VjdGlvbiA0LjIuMy4yLjxicj4mZ3Q7 PGJyPiZndDsgSW4gdGhpcyB0ZXh0IGZyb20gNi4zIFBETSBGbG93IC0gTXVsdGlwbGUgU2VuZCB3 aXRoIEVycm9yczxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwO09uZSBtaWdodCB3b25kZXIg aWYgYWxsIG9mIHRoZSBmdW5jdGlvbnMgb2YgUERNIG1pZ2h0IGJlIGJldHRlcjxicj4mZ3Q7ICZu YnNwOyAmbmJzcDtzdWl0ZWQgdG8gVENQIG9yIGEgVENQIG9wdGlvbi48YnI+Jmd0Ozxicj4mZ3Q7 IHRoYXQncyBhbiBpbnRlcmVzdGluZyBwb2ludCBpbiB0aGUgYnJvYWRlciBzZW5zZSwgYmVjYXVz ZSAoZHVoKSBwdXR0aW5nIFBETSBpbiBhIFRDUCBvcHRpb24gZG9lc24ndCBoZWxwIHlvdSB3aXRo IGFueSBvdGhlciB0cmFuc3BvcnQgcHJvdG9jb2wgKFNDVFAsIFFVSUMsIHdoYXQgZWxzZSBhcmUg d2UgZG9pbmcgdGhlc2UgZGF5cz8gYW5kLCBvZiBjb3Vyc2UsIHRoZXkncmUgYWxsIHJ1bm5pbmcg b3ZlciBVRFAgYW55d2F5KS4gSSB3b25kZXIgaWYgdGhhdCdzIHdvcnRoIHBvaW50aW5nIG91dCBl YXJsaWVyIGluIHRoZSBkb2N1bWVudCwgcGVyaGFwcyBpbiBTZWN0aW9uIDEuND88YnI+Jmd0Ozxi cj4mZ3Q7IFRoaXMgdGV4dDxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwO0xldCdzIHNheSB0 aGF0IHBhY2tldCA0IFNUSUxMIGRvZXMgbm90IG1ha2UgaXQuPGJyPiZndDs8YnI+Jmd0OyBpcyBw cm9iYWJseSB0b28gYnJlZXp5IHRvIHRyYW5zbGF0ZSB3ZWxsIGludG8gb3RoZXIgbGFuZ3VhZ2Vz LiBQZXJoYXBzICZxdW90O2lzIGFsc28gbG9zdCZxdW90Oz8gKFllcywgSSB0YWxrIGxpa2UgdGhp cywgdG9vKTxicj4mZ3Q7PGJyPiZndDsgSW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNl Y3Rpb24sIHlvdSBtaWdodCB3YW50IHRvIHNheSBzb21ldGhpbmcgYWJvdXQgKDEpIHdoYXQgd2F0 Y2hpbmcgdGhlIHVuZW5jcnlwdGVkIFBETSB2YWx1ZXMgbWlnaHQgdGVsbCBhdHRhY2tlcnMgdGhh dCBhcmUgZG9pbmcgcGVydmFzaXZlIG1vbml0b3JpbmcgKFJGQyA3MjU4KSwgYW5kIHBvc3NpYmx5 IGFib3V0ICgyKSB3aGF0IGhhcHBlbnMgaWYgUERNIGlzIHVzZWQgYXMgYSBjb3ZlcnQgY2hhbm5l bC4gSSBkb24ndCB0aGluayBlaXRoZXIgb2YgdGhlc2Ugd2lsbCBiZSBzaG93c3RvcHBlcnMgYXQg U0VDRElSIHJldmlldyB0aW1lLCBidXQgSSdkIGV4cGVjdCB0aGF0IGRlbW9uc3RyYXRpbmcgYXdh cmVuZXNzIG9mIGF0IGxlYXN0ICgxKSB3aWxsIHNob3J0ZW4gdGhlIHJldmlldyBjb21tZW50cyBj eWNsZS4gUG9zc2libHkgYSBsb3QsIGp1ZGdpbmcgYnkgcmVjZW50IGJhbGxvdHMgb24gb3RoZXIg ZHJhZnRzIC4uLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_4AF73AA205019A4C8A1DDD32C034631D4598DC73CFNJFPSRVEXG0re_-- From nobody Wed Sep 14 05:56:15 2016 Return-Path: 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 D4AB612B847 for ; Wed, 14 Sep 2016 05:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 MXEG-3crmjJX for ; Wed, 14 Sep 2016 05:56:11 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 222AE12B89B for ; Wed, 14 Sep 2016 05:47:32 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 903E11209BF; Wed, 14 Sep 2016 09:01:39 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 22739E2AEC; Wed, 14 Sep 2016 08:45:02 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Wed, 14 Sep 2016 08:47:31 -0400 From: "MORTON, ALFRED C (AL)" To: Spencer Dawkins at IETF , Nalini Elkins Date: Wed, 14 Sep 2016 08:47:30 -0400 Thread-Topic: AD review of draft-ietf-ippm-6man-pdm-option-03 Thread-Index: AdIOGiez785acovvTVG3xpa2o3CfDwAEoA6AABYMrVA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D459F65BD0A@NJFPSRVEXG0.research.att.com> References: <881483676.498721.1473807890669@mail.yahoo.com> <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D459F65BD0ANJFPSRVEXG0re_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 12:56:14 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D459F65BD0ANJFPSRVEXG0re_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJ4oCZbSBzYXRpc2ZpZWQgd2l0aCB0aGlzIHZlcnNpb24sIExhc3QgQ2FsbCBp cyBuZXh0IHN0ZXAuDQpJIHRoaW5rIGFsbCBteSBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVzc2Vk Lg0KDQouLi4NCknigJltIGdsYWQgdG8gc2VlIHRoZSBleHBhbmRlZCBTZWN1cml0eSBDb25zaWRl cmF0aW9ucy4NCk9uZSBzbWFsbCBjbGFyaWZpY2F0aW9uIGNvdWxkIGJlIG1hZGUgaW4gdGhlICpu ZXh0KiB2ZXJzaW9uLA0KYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDguMToNCg0KDQogICBXZSByZWNv bW1lbmQgdGhhdCBpbXBsZW1lbnRhdGlvbiBvZiBQRE0gU0hPVUxEIGhhdmUgYSBsaW1pdCBvbiB0 aGUNCiAgIHNpemUgb2YgdGhlIGNvbnRyb2wgYmxvY2tzIHVzZWQuDQoNClNpbmNlIHlvdeKAmXZl IGFscmVhZHkgc2FpZCB0aGF0IHRoZSBjb250cm9sIGJsb2NrIGlzIHF1aXRlIHNtYWxsLA0KbWF5 YmUgdGhpcyByZWNvbW1lbmRhdGlvbiBpcyBvbiB0aGUgbnVtYmVyIG9mIGNvbnRyb2wgYmxvY2tz Pw0KDQoNCiAgIFdlIHJlY29tbWVuZCB0aGF0IGltcGxlbWVudGF0aW9uIG9mIFBETSBTSE9VTEQg aGF2ZSBhIGxpbWl0IG9uIHRoZQ0KICAgbnVtYmVyIG9mIHRoZSBjb250cm9sIGJsb2NrcyB1c2Vk Lg0KICBeXl5eXl4NCg0KdGhhbmtzIGF1dGhvcnMhDQpBbA0KDQpGcm9tOiBNT1JUT04sIEFMRlJF RCBDIChBTCkNClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNiAxMDowOCBQTQ0KVG86 IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGOyBOYWxpbmkgRWxraW5zDQpDYzogTU9SVE9OLCBBTEZS RUQgQyAoQUwpOyBpcHBtQGlldGYub3JnOyBkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9u QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBw bS02bWFuLXBkbS1vcHRpb24tMDMNCg0KSeKAmWxsIGNoZWNrIGZpcnN0IHRoaW5nIHRvbW9ycm93 LA0KdGhhbmtzIQ0KQWwNCg0KRnJvbTogU3BlbmNlciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpz cGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAx MywgMjAxNiA3OjU0IFBNDQpUbzogTmFsaW5pIEVsa2lucw0KQ2M6IE1PUlRPTiwgQUxGUkVEIEMg KEFMKTsgaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz47IGRyYWZ0LWlldGYtaXBw bS02bWFuLXBkbS1vcHRpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaXBwbS02 bWFuLXBkbS1vcHRpb25AdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb24tMDMNCg0KDQpOYWxpbmksDQoNCk9uIFNl cCAxMywgMjAxNiAxODowNCwgPG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3RhY2suY29tPG1haWx0 bzpuYWxpbmkuZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbT4+IHdyb3RlOg0KPg0KPiBTcGVuY2Vy LA0KPg0KPiBXZSBoYXZlICh3ZSBiZWxpZXZlISkgYWRkcmVzc2VkIHlvdXIgY29tbWVudHMgYXMg d2VsbCBhcyB0aG9zZSBmcm9tIEFsIE1vcnRvbiBhcyBkb2N1bWVudCBzaGVwaGVyZC4NCj4NCj4g VGhlIG5ldyB2ZXJzaW9uIGlzIGF0Og0KPg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1pcHBtLTZtYW4tcGRtLW9wdGlvbi0wNA0KPg0KPiBXZSBoYXZlIGFkZGVkIHF1 aXRlIGEgYml0IHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4gIFdlIGhhdmUgc3RhcnRl ZCBpbXBsZW1lbnRhdGlvbiBvZiBQRE0gaW4gdGhlIEZyZWVCU0Qga2VybmVsLCBhcyBJIG1pZ2h0 IGhhdmUgbWVudGlvbmVkIGJlZm9yZS4gICBJdCBoYXMgc2hlZCBxdWl0ZSBhIGJpdCBvZiBsaWdo dCBvbiB0aGUgcG90ZW50aWFsIGhhemFyZHMgd2hpY2ggbWF5IGNvbWUgdXAgYXMgZmFyIGFzIERP UyBhdHRhY2tzLCBldGMuICAgVGhhdCB3YXMgaGVscGZ1bCB0byB1cyBpbiBkb2luZyB0aGUgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMuDQo+DQo+IE1hbnkgdGhhbmtzIHRvIGJvdGggeW91IGFuZCBB bCBNb3J0b24gZm9yIHlvdXIgaGVscCBhbmQgY29tbWVudHMuDQoNCkknbSBoYXBweS4gQWwsIGlz IHRoaXMgdmVyc2lvbiByZWFkeSBmb3IgSUVURiBMYXN0IENhbGw/DQoNClRoYW5rcywNCg0KU3Bl bmNlcg0KDQo+IC0gTmFsaW5pIEVsa2lucyAtIG9uIGJlaGFsZiBvZiB0aGUgUERNIGNvLWF1dGhv cnMgKE1pa2UgQWNrZXJtYW5uIGFuZCBSb2IgSGFtaWx0b24pDQo+IEluc2lkZSBQcm9kdWN0cywg SW5jLg0KPiB3d3cuaW5zaWRldGhlc3RhY2suY29tPGh0dHA6Ly93d3cuaW5zaWRldGhlc3RhY2su Y29tPg0KPiAoODMxKSA2NTktODM2MA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBGcm9tOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPj4N Cj4gVG86IGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb25AdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb25AdG9vbHMuaWV0Zi5vcmc+DQo+IENj OiBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KPiBTZW50OiBNb25kYXksIEF1 Z3VzdCAyMiwgMjAxNiA1OjM3IFBNDQo+IFN1YmplY3Q6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRm LWlwcG0tNm1hbi1wZG0tb3B0aW9uLTAzDQo+DQo+DQo+DQo+IERlYXIgQXV0aG9ycywNCj4NCj4g TmljZSB3b3JrLCBhbmQgdGhpcyB3b3VsZCBoYXZlIGJlZW4gdmVyeSB2YWx1YWJsZSB3aGVuIEkg d2FzIGltcGxlbWVudGluZyBwZXJmb3JtYW5jZSBtb25pdG9ycyBhdCBUZWt0cm9uaXgsIHNvIEkg aW1hZ2luZSBpdCdzIGVxdWFsbHkgdmFsdWFibGUgbm93Lg0KPg0KPiBJIGRvIGhhdmUgc29tZSBj b21tZW50cyB0aGF0IEknZCBsaWtlIHlvdSBsZXQgeW91IGNvbnNpZGVyIGJlZm9yZSBJIHJlcXVl c3QgSUVURiBMYXN0IENhbGwgZm9yIHRoaXMgZHJhZnQuIFBsZWFzZSBsZXQgbWUga25vdyBpZiB5 b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLCBvZiBjb3Vyc2UuDQo+DQo+IFRoYW5rcywNCj4NCj4gU3Bl bmNlcg0KPg0KPiBJIHNhdyB0aGUgYWJzdHJhY3QgZm9sbG93aW5nIHRoZSB0YWJsZSBvZiBjb250 ZW50cyBtZW50aW9uZWQgaW4gdGhlIHNoZXBoZXJkIHdyaXRlLXVwLCBidXQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzczMjIjc2VjdGlvbi00Ljcgc2F5cw0KPg0KPiAgICBBIFRhYmxl IG9mIENvbnRlbnRzIChUT0MpIGlzIHJlcXVpcmVkIGluIGFsbCBSRkNzLiAgSXQgbXVzdCBiZQ0K PiAgICBwb3NpdGlvbmVkIGFmdGVyIHRoZSBDb3B5cmlnaHQgTm90aWNlIGFuZCBiZWZvcmUgdGhl IEludHJvZHVjdGlvbi4NCj4NCj4gSXQncyBwcm9iYWJseSBhIGdvb2QgdGhpbmcgdG8gdXNlIHRo ZSBvcmdhbml6YXRpb24gZnJvbSBSRkMgNzMyMiwganVzdCB0byBzaWRlc3RlcCByZXZpZXdlcnMg d2hvIHN0YXJ0IG91dCBjb21wbGFpbmluZyBhYm91dCBkb2N1bWVudCBzdHJ1Y3R1cmUgbml0cyBh bmQgdGhlbiBrZWVwIG9uIHR5cGluZy4gTm90IHRoYXQgSSBldmVyIGRpZCB0aGF0IGluIHNpeCB5 ZWFycyBhcyBhIEdlbi1BUlQgcmV2aXdlciwgb2YgY291cnNlIDotKSAuLi4NCj4NCj4gSSBwcm9i YWJseSBsYWNrIGltYWdpbmF0aW9uLCBidXQgcGVyaGFwcyBvdGhlciByZWFkZXJzIHdpbGwsIGFs c28uDQo+DQo+IEluIHRoaXMgdGV4dA0KPg0KPiAgICBERUxUQVRMUiA9IFNlbmQgdGltZSBwYWNr ZXQgMiAtIFJlY2VpdmUgdGltZSBwYWNrZXQgMQ0KPg0KPiBhbmQNCj4NCj4gICAgRGVsdGEgVGlt ZSBMYXN0IFNlbnQgPSBSZWNlaXZlIHRpbWUgcGFja2V0IDIgLSBTZW5kIHRpbWUgcGFja2V0IDEN Cj4NCj4gdGhlc2UgYXJlIG1hdGhlbWF0aWNhbCBleHByZXNzaW9ucywgYXJlbid0IHRoZXk/IElm IHNvLCB0aGF0IHdvdWxkIGxpa2VseSBiZSBjbGVhcmVyIGlmIHRoZSByaWdodCBzaWRlIHRlcm1z IGhhZCBwYXJlbnRoZXNlcyBhcm91bmQgdGhlIGV4cHJlc3Npb24uDQo+DQo+IChJdCdzIGEgYml0 IG9kZCB0aGF0IHRoZSBmaXJzdCBleHByZXNzaW9uIHVzZXMgdGhlIGFiYnJldmlhdGlvbiBERUxU QVRMUiBhbmQgdGhlIHNlY29uZCB0ZXJtIGlzIHNwZWxsZWQgb3V0IGFzICJEZWx0YSBUaW1lIExh c3QgU2VudCIgLSB5b3UgbWlnaHQgdGhpbmsgYWJvdXQgd2hpY2ggc2VlbXMgY2xlYXJlciwgYW5k IGRvIHRoYXQgd2l0aCBib3RoIGV4cHJlc3Npb25zKQ0KPg0KPiBJbiB0ZXh0IGxpa2UgdGhpcw0K Pg0KPiAgICBXZSBwcm9wb3NlIGEgYmFzZSB1bml0IGZvciB0aGUgdGltZS4NCj4NCj4geW91IHBy b2JhYmx5IHdhbnQgdG8gdXNlIGEgdmVyYiBsaWtlICJzcGVjaWZ5IiAod2hlbiB0aGUgZHJhZnQg aXMgcHVibGlzaGVkIGFzIGFuIFJGQywgaXQgd2lsbCBubyBsb25nZXIgYmUgYSBwcm9wb3NhbCku IFRoZXJlIGFyZSBtdWx0aXBsZSBvY2N1cnJlbmNlcyBvZiAicHJvcG9zZSIgaW4gdGhlIGRvY3Vt ZW50LCBzbyB0aGlzIGNvbW1lbnQgYXBwbGllcyBpbiBtdWx0aXBsZSBwbGFjZXMuDQo+DQo+IEZv ciB0aGlzIHRleHQNCj4NCj4gICAgQXNzdW1lIHRoYXQgdHdvIHBhY2tldHMgYXJlIHNlbnQgZm9y IGVhY2ggQUNLIGZyb20gdGhlIHNlcnZlci4NCj4NCj4geW91IG1pZ2h0IHBvaW50IG91dCB0aGF0 IFRDUCBkb2VzIHRoaXMsIHBlciBSRkMgMTEyMiBTZWN0aW9uIDQuMi4zLjIuDQo+DQo+IEluIHRo aXMgdGV4dCBmcm9tIDYuMyBQRE0gRmxvdyAtIE11bHRpcGxlIFNlbmQgd2l0aCBFcnJvcnMNCj4N Cj4gICAgT25lIG1pZ2h0IHdvbmRlciBpZiBhbGwgb2YgdGhlIGZ1bmN0aW9ucyBvZiBQRE0gbWln aHQgYmUgYmV0dGVyDQo+ICAgIHN1aXRlZCB0byBUQ1Agb3IgYSBUQ1Agb3B0aW9uLg0KPg0KPiB0 aGF0J3MgYW4gaW50ZXJlc3RpbmcgcG9pbnQgaW4gdGhlIGJyb2FkZXIgc2Vuc2UsIGJlY2F1c2Ug KGR1aCkgcHV0dGluZyBQRE0gaW4gYSBUQ1Agb3B0aW9uIGRvZXNuJ3QgaGVscCB5b3Ugd2l0aCBh bnkgb3RoZXIgdHJhbnNwb3J0IHByb3RvY29sIChTQ1RQLCBRVUlDLCB3aGF0IGVsc2UgYXJlIHdl IGRvaW5nIHRoZXNlIGRheXM/IGFuZCwgb2YgY291cnNlLCB0aGV5J3JlIGFsbCBydW5uaW5nIG92 ZXIgVURQIGFueXdheSkuIEkgd29uZGVyIGlmIHRoYXQncyB3b3J0aCBwb2ludGluZyBvdXQgZWFy bGllciBpbiB0aGUgZG9jdW1lbnQsIHBlcmhhcHMgaW4gU2VjdGlvbiAxLjQ/DQo+DQo+IFRoaXMg dGV4dA0KPg0KPiAgICBMZXQncyBzYXkgdGhhdCBwYWNrZXQgNCBTVElMTCBkb2VzIG5vdCBtYWtl IGl0Lg0KPg0KPiBpcyBwcm9iYWJseSB0b28gYnJlZXp5IHRvIHRyYW5zbGF0ZSB3ZWxsIGludG8g b3RoZXIgbGFuZ3VhZ2VzLiBQZXJoYXBzICJpcyBhbHNvIGxvc3QiPyAoWWVzLCBJIHRhbGsgbGlr ZSB0aGlzLCB0b28pDQo+DQo+IEluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u LCB5b3UgbWlnaHQgd2FudCB0byBzYXkgc29tZXRoaW5nIGFib3V0ICgxKSB3aGF0IHdhdGNoaW5n IHRoZSB1bmVuY3J5cHRlZCBQRE0gdmFsdWVzIG1pZ2h0IHRlbGwgYXR0YWNrZXJzIHRoYXQgYXJl IGRvaW5nIHBlcnZhc2l2ZSBtb25pdG9yaW5nIChSRkMgNzI1OCksIGFuZCBwb3NzaWJseSBhYm91 dCAoMikgd2hhdCBoYXBwZW5zIGlmIFBETSBpcyB1c2VkIGFzIGEgY292ZXJ0IGNoYW5uZWwuIEkg ZG9uJ3QgdGhpbmsgZWl0aGVyIG9mIHRoZXNlIHdpbGwgYmUgc2hvd3N0b3BwZXJzIGF0IFNFQ0RJ UiByZXZpZXcgdGltZSwgYnV0IEknZCBleHBlY3QgdGhhdCBkZW1vbnN0cmF0aW5nIGF3YXJlbmVz cyBvZiBhdCBsZWFzdCAoMSkgd2lsbCBzaG9ydGVuIHRoZSByZXZpZXcgY29tbWVudHMgY3ljbGUu IFBvc3NpYmx5IGEgbG90LCBqdWRnaW5nIGJ5IHJlY2VudCBiYWxsb3RzIG9uIG90aGVyIGRyYWZ0 cyAuLi4NCg== --_000_4AF73AA205019A4C8A1DDD32C034631D459F65BD0ANJFPSRVEXG0re_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xv cjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y OmJsYWNrJz5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPknigJltIHNhdGlzZmllZCB3aXRoIHRoaXMgdmVyc2lvbiwgTGFzdCBDYWxs IGlzIG5leHQgc3RlcC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6YmxhY2snPkkgdGhpbmsgYWxsIG15IGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPi4uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+SeKAmW0g Z2xhZCB0byBzZWUgdGhlIGV4cGFuZGVkIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+T25lIHNtYWxsIGNs YXJpZmljYXRpb24gY291bGQgYmUgbWFkZSBpbiB0aGUgKjxiPm5leHQ8L2I+KiB2ZXJzaW9uLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+YXQgdGhl IGVuZCBvZiBzZWN0aW9uIDguMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO2NvbG9yOmJsYWNrJz7CoMKgIFdlIHJlY29tbWVuZCB0aGF0IGltcGxlbWVudGF0aW9u IG9mIFBETSBTSE9VTEQgaGF2ZSBhIGxpbWl0IG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+wqDCoCBzaXplIG9mIHRoZSBjb250cm9sIGJs b2NrcyB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y OmJsYWNrJz5TaW5jZSB5b3XigJl2ZSBhbHJlYWR5IHNhaWQgdGhhdCB0aGUgY29udHJvbCBibG9j ayBpcyBxdWl0ZSBzbWFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPm1heWJlIHRoaXMgcmVjb21tZW5kYXRpb24gaXMgb24gdGhlIG51bWJlciBv ZiBjb250cm9sIGJsb2Nrcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgIFdl IHJlY29tbWVuZCB0aGF0IGltcGxlbWVudGF0aW9uIG9mIFBETSBTSE9VTEQgaGF2ZSBhIGxpbWl0 IG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoCBudW1i ZXIgb2YgdGhlIGNvbnRyb2wgYmxvY2tzIHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciO2NvbG9yOmJsYWNrJz7CoCBeXl5eXl48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+dGhhbmtzIGF1dGhvcnMhPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5BbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIFNl cHRlbWJlciAxMywgMjAxNiAxMDowOCBQTTxicj48Yj5Ubzo8L2I+IFNwZW5jZXIgRGF3a2lucyBh dCBJRVRGOyBOYWxpbmkgRWxraW5zPGJyPjxiPkNjOjwvYj4gTU9SVE9OLCBBTEZSRUQgQyAoQUwp OyBpcHBtQGlldGYub3JnOyBkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQHRvb2xzLmll dGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBw bS02bWFuLXBkbS1vcHRpb24tMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOmJsYWNrJz5J4oCZbGwgY2hlY2sgZmlyc3QgdGhpbmcgdG9tb3Jyb3csPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz50aGFua3MhPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5BbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFs8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRh d2tpbnMuaWV0ZkBnbWFpbC5jb20iPm1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNv bTwvYT5dIDxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgU2VwdGVtYmVyIDEzLCAyMDE2IDc6NTQg UE08YnI+PGI+VG86PC9iPiBOYWxpbmkgRWxraW5zPGJyPjxiPkNjOjwvYj4gTU9SVE9OLCBBTEZS RUQgQyAoQUwpOyA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwv YT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQHRvb2xz LmlldGYub3JnIj5kcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQHRvb2xzLmlldGYub3Jn PC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWlwcG0t Nm1hbi1wZG0tb3B0aW9uLTAzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cD5OYWxpbmksIDxvOnA+PC9vOnA+ PC9wPjxwPk9uIFNlcCAxMywgMjAxNiAxODowNCwgJmx0OzxhIGhyZWY9Im1haWx0bzpuYWxpbmku ZWxraW5zQGluc2lkZXRoZXN0YWNrLmNvbSI+bmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5j b208L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7IFNwZW5jZXIsPGJyPiZndDs8YnI+Jmd0 OyBXZSBoYXZlICh3ZSBiZWxpZXZlISkgYWRkcmVzc2VkIHlvdXIgY29tbWVudHMgYXMgd2VsbCBh cyB0aG9zZSBmcm9tIEFsIE1vcnRvbiBhcyBkb2N1bWVudCBzaGVwaGVyZC48YnI+Jmd0Ozxicj4m Z3Q7IFRoZSBuZXcgdmVyc2lvbiBpcyBhdDo8YnI+Jmd0Ozxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uLTA0 Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLTZtYW4tcGRtLW9w dGlvbi0wNDwvYT48YnI+Jmd0Ozxicj4mZ3Q7IFdlIGhhdmUgYWRkZWQgcXVpdGUgYSBiaXQgdG8g dGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLiZuYnNwOyBXZSBoYXZlIHN0YXJ0ZWQgaW1wbGVt ZW50YXRpb24gb2YgUERNIGluIHRoZSBGcmVlQlNEIGtlcm5lbCwgYXMgSSBtaWdodCBoYXZlIG1l bnRpb25lZCBiZWZvcmUuJm5ic3A7ICZuYnNwO0l0IGhhcyBzaGVkIHF1aXRlIGEgYml0IG9mIGxp Z2h0IG9uIHRoZSBwb3RlbnRpYWwgaGF6YXJkcyB3aGljaCBtYXkgY29tZSB1cCBhcyBmYXIgYXMg RE9TIGF0dGFja3MsIGV0Yy4mbmJzcDsgJm5ic3A7VGhhdCB3YXMgaGVscGZ1bCB0byB1cyBpbiBk b2luZyB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuPGJyPiZndDs8YnI+Jmd0OyBNYW55IHRo YW5rcyB0byBib3RoIHlvdSBhbmQgQWwgTW9ydG9uIGZvciB5b3VyIGhlbHAgYW5kIGNvbW1lbnRz LjxvOnA+PC9vOnA+PC9wPjxwPkknbSBoYXBweS4gQWwsIGlzIHRoaXMgdmVyc2lvbiByZWFkeSBm b3IgSUVURiBMYXN0IENhbGw/PG86cD48L286cD48L3A+PHA+VGhhbmtzLCA8bzpwPjwvbzpwPjwv cD48cD5TcGVuY2VyPG86cD48L286cD48L3A+PHA+Jmd0OyAtIE5hbGluaSBFbGtpbnMgLSBvbiBi ZWhhbGYgb2YgdGhlIFBETSBjby1hdXRob3JzIChNaWtlIEFja2VybWFubiBhbmQgUm9iIEhhbWls dG9uKTxicj4mZ3Q7IEluc2lkZSBQcm9kdWN0cywgSW5jLjxicj4mZ3Q7IDxhIGhyZWY9Imh0dHA6 Ly93d3cuaW5zaWRldGhlc3RhY2suY29tIj53d3cuaW5zaWRldGhlc3RhY2suY29tPC9hPjxicj4m Z3Q7ICg4MzEpIDY1OS04MzYwPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBGcm9tOiBTcGVuY2VyIERhd2tpbnMg YXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29t Ij5zcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPiZndDsgVG86IDxhIGhy ZWY9Im1haWx0bzpkcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQHRvb2xzLmlldGYub3Jn Ij5kcmFmdC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uQHRvb2xzLmlldGYub3JnPC9hPjxicj4m Z3Q7IENjOiA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyI+aXBwbUBpZXRmLm9yZzwvYT48 YnI+Jmd0OyBTZW50OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxNiA1OjM3IFBNPGJyPiZndDsgU3Vi amVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBwbS02bWFuLXBkbS1vcHRpb24tMDM8YnI+ Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBEZWFyIEF1dGhvcnMsPGJyPiZndDs8YnI+Jmd0 OyBOaWNlIHdvcmssIGFuZCB0aGlzIHdvdWxkIGhhdmUgYmVlbiB2ZXJ5IHZhbHVhYmxlIHdoZW4g SSB3YXMgaW1wbGVtZW50aW5nIHBlcmZvcm1hbmNlIG1vbml0b3JzIGF0IFRla3Ryb25peCwgc28g SSBpbWFnaW5lIGl0J3MgZXF1YWxseSB2YWx1YWJsZSBub3cuPGJyPiZndDs8YnI+Jmd0OyBJIGRv IGhhdmUgc29tZSBjb21tZW50cyB0aGF0IEknZCBsaWtlIHlvdSBsZXQgeW91IGNvbnNpZGVyIGJl Zm9yZSBJIHJlcXVlc3QgSUVURiBMYXN0IENhbGwgZm9yIHRoaXMgZHJhZnQuIFBsZWFzZSBsZXQg bWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zLCBvZiBjb3Vyc2UuPGJyPiZndDs8YnI+ Jmd0OyBUaGFua3MsPGJyPiZndDs8YnI+Jmd0OyBTcGVuY2VyPGJyPiZndDs8YnI+Jmd0OyBJIHNh dyB0aGUgYWJzdHJhY3QgZm9sbG93aW5nIHRoZSB0YWJsZSBvZiBjb250ZW50cyBtZW50aW9uZWQg aW4gdGhlIHNoZXBoZXJkIHdyaXRlLXVwLCBidXQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzczMjIjc2VjdGlvbi00LjciPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MzIyI3NlY3Rpb24tNC43PC9hPiBzYXlzPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7QSBUYWJsZSBvZiBDb250ZW50cyAoVE9DKSBpcyByZXF1aXJlZCBpbiBhbGwgUkZDcy4mbmJz cDsgSXQgbXVzdCBiZTxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtwb3NpdGlvbmVkIGFmdGVyIHRoZSBD b3B5cmlnaHQgTm90aWNlIGFuZCBiZWZvcmUgdGhlIEludHJvZHVjdGlvbi48YnI+Jmd0Ozxicj4m Z3Q7IEl0J3MgcHJvYmFibHkgYSBnb29kIHRoaW5nIHRvIHVzZSB0aGUgb3JnYW5pemF0aW9uIGZy b20gUkZDIDczMjIsIGp1c3QgdG8gc2lkZXN0ZXAgcmV2aWV3ZXJzIHdobyBzdGFydCBvdXQgY29t cGxhaW5pbmcgYWJvdXQgZG9jdW1lbnQgc3RydWN0dXJlIG5pdHMgYW5kIHRoZW4ga2VlcCBvbiB0 eXBpbmcuIE5vdCB0aGF0IEkgZXZlciBkaWQgdGhhdCBpbiBzaXggeWVhcnMgYXMgYSBHZW4tQVJU IHJldml3ZXIsIG9mIGNvdXJzZSA6LSkgLi4uPGJyPiZndDs8YnI+Jmd0OyBJIHByb2JhYmx5IGxh Y2sgaW1hZ2luYXRpb24sIGJ1dCBwZXJoYXBzIG90aGVyIHJlYWRlcnMgd2lsbCwgYWxzby48YnI+ Jmd0Ozxicj4mZ3Q7IEluIHRoaXMgdGV4dDxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwO0RF TFRBVExSID0gU2VuZCB0aW1lIHBhY2tldCAyIC0gUmVjZWl2ZSB0aW1lIHBhY2tldCAxPGJyPiZn dDs8YnI+Jmd0OyBhbmQ8YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtEZWx0YSBUaW1lIExh c3QgU2VudCA9IFJlY2VpdmUgdGltZSBwYWNrZXQgMiAtIFNlbmQgdGltZSBwYWNrZXQgMTxicj4m Z3Q7PGJyPiZndDsgdGhlc2UgYXJlIG1hdGhlbWF0aWNhbCBleHByZXNzaW9ucywgYXJlbid0IHRo ZXk/IElmIHNvLCB0aGF0IHdvdWxkIGxpa2VseSBiZSBjbGVhcmVyIGlmIHRoZSByaWdodCBzaWRl IHRlcm1zIGhhZCBwYXJlbnRoZXNlcyBhcm91bmQgdGhlIGV4cHJlc3Npb24uPGJyPiZndDs8YnI+ Jmd0OyAoSXQncyBhIGJpdCBvZGQgdGhhdCB0aGUgZmlyc3QgZXhwcmVzc2lvbiB1c2VzIHRoZSBh YmJyZXZpYXRpb24gREVMVEFUTFIgYW5kIHRoZSBzZWNvbmQgdGVybSBpcyBzcGVsbGVkIG91dCBh cyAmcXVvdDtEZWx0YSBUaW1lIExhc3QgU2VudCZxdW90OyAtIHlvdSBtaWdodCB0aGluayBhYm91 dCB3aGljaCBzZWVtcyBjbGVhcmVyLCBhbmQgZG8gdGhhdCB3aXRoIGJvdGggZXhwcmVzc2lvbnMp PGJyPiZndDs8YnI+Jmd0OyBJbiB0ZXh0IGxpa2UgdGhpczxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7 ICZuYnNwO1dlIHByb3Bvc2UgYSBiYXNlIHVuaXQgZm9yIHRoZSB0aW1lLjxicj4mZ3Q7PGJyPiZn dDsgeW91IHByb2JhYmx5IHdhbnQgdG8gdXNlIGEgdmVyYiBsaWtlICZxdW90O3NwZWNpZnkmcXVv dDsgKHdoZW4gdGhlIGRyYWZ0IGlzIHB1Ymxpc2hlZCBhcyBhbiBSRkMsIGl0IHdpbGwgbm8gbG9u Z2VyIGJlIGEgcHJvcG9zYWwpLiBUaGVyZSBhcmUgbXVsdGlwbGUgb2NjdXJyZW5jZXMgb2YgJnF1 b3Q7cHJvcG9zZSZxdW90OyBpbiB0aGUgZG9jdW1lbnQsIHNvIHRoaXMgY29tbWVudCBhcHBsaWVz IGluIG11bHRpcGxlIHBsYWNlcy48YnI+Jmd0Ozxicj4mZ3Q7IEZvciB0aGlzIHRleHQ8YnI+Jmd0 Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtBc3N1bWUgdGhhdCB0d28gcGFja2V0cyBhcmUgc2VudCBm b3IgZWFjaCBBQ0sgZnJvbSB0aGUgc2VydmVyLjxicj4mZ3Q7PGJyPiZndDsgeW91IG1pZ2h0IHBv aW50IG91dCB0aGF0IFRDUCBkb2VzIHRoaXMsIHBlciBSRkMgMTEyMiBTZWN0aW9uIDQuMi4zLjIu PGJyPiZndDs8YnI+Jmd0OyBJbiB0aGlzIHRleHQgZnJvbSA2LjMgUERNIEZsb3cgLSBNdWx0aXBs ZSBTZW5kIHdpdGggRXJyb3JzPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7T25lIG1pZ2h0 IHdvbmRlciBpZiBhbGwgb2YgdGhlIGZ1bmN0aW9ucyBvZiBQRE0gbWlnaHQgYmUgYmV0dGVyPGJy PiZndDsgJm5ic3A7ICZuYnNwO3N1aXRlZCB0byBUQ1Agb3IgYSBUQ1Agb3B0aW9uLjxicj4mZ3Q7 PGJyPiZndDsgdGhhdCdzIGFuIGludGVyZXN0aW5nIHBvaW50IGluIHRoZSBicm9hZGVyIHNlbnNl LCBiZWNhdXNlIChkdWgpIHB1dHRpbmcgUERNIGluIGEgVENQIG9wdGlvbiBkb2Vzbid0IGhlbHAg eW91IHdpdGggYW55IG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbCAoU0NUUCwgUVVJQywgd2hhdCBl bHNlIGFyZSB3ZSBkb2luZyB0aGVzZSBkYXlzPyBhbmQsIG9mIGNvdXJzZSwgdGhleSdyZSBhbGwg cnVubmluZyBvdmVyIFVEUCBhbnl3YXkpLiBJIHdvbmRlciBpZiB0aGF0J3Mgd29ydGggcG9pbnRp bmcgb3V0IGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50LCBwZXJoYXBzIGluIFNlY3Rpb24gMS40Pzxi cj4mZ3Q7PGJyPiZndDsgVGhpcyB0ZXh0PGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7TGV0 J3Mgc2F5IHRoYXQgcGFja2V0IDQgU1RJTEwgZG9lcyBub3QgbWFrZSBpdC48YnI+Jmd0Ozxicj4m Z3Q7IGlzIHByb2JhYmx5IHRvbyBicmVlenkgdG8gdHJhbnNsYXRlIHdlbGwgaW50byBvdGhlciBs YW5ndWFnZXMuIFBlcmhhcHMgJnF1b3Q7aXMgYWxzbyBsb3N0JnF1b3Q7PyAoWWVzLCBJIHRhbGsg bGlrZSB0aGlzLCB0b28pPGJyPiZndDs8YnI+Jmd0OyBJbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiwgeW91IG1pZ2h0IHdhbnQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCAoMSkg d2hhdCB3YXRjaGluZyB0aGUgdW5lbmNyeXB0ZWQgUERNIHZhbHVlcyBtaWdodCB0ZWxsIGF0dGFj a2VycyB0aGF0IGFyZSBkb2luZyBwZXJ2YXNpdmUgbW9uaXRvcmluZyAoUkZDIDcyNTgpLCBhbmQg cG9zc2libHkgYWJvdXQgKDIpIHdoYXQgaGFwcGVucyBpZiBQRE0gaXMgdXNlZCBhcyBhIGNvdmVy dCBjaGFubmVsLiBJIGRvbid0IHRoaW5rIGVpdGhlciBvZiB0aGVzZSB3aWxsIGJlIHNob3dzdG9w cGVycyBhdCBTRUNESVIgcmV2aWV3IHRpbWUsIGJ1dCBJJ2QgZXhwZWN0IHRoYXQgZGVtb25zdHJh dGluZyBhd2FyZW5lc3Mgb2YgYXQgbGVhc3QgKDEpIHdpbGwgc2hvcnRlbiB0aGUgcmV2aWV3IGNv bW1lbnRzIGN5Y2xlLiBQb3NzaWJseSBhIGxvdCwganVkZ2luZyBieSByZWNlbnQgYmFsbG90cyBv biBvdGhlciBkcmFmdHMgLi4uPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= --_000_4AF73AA205019A4C8A1DDD32C034631D459F65BD0ANJFPSRVEXG0re_-- From nobody Wed Sep 14 07:02:44 2016 Return-Path: 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 710E312BCED for ; Wed, 14 Sep 2016 07:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 gW4ZFEeVWVbp for ; Wed, 14 Sep 2016 07:02:37 -0700 (PDT) Received: from nm5-vm1.bullet.mail.ne1.yahoo.com (nm5-vm1.bullet.mail.ne1.yahoo.com [98.138.91.32]) (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 F1EA112B8A7 for ; Wed, 14 Sep 2016 06:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473859201; bh=81FUXNZArvFm+7jE3OUm/7NsjiDKgdDO75hCMaKOLqg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=E9OnYZG7Llngd258bNXM+Bk20PMLxiRxZ4eAqP73chD8TyVw10Zu+28oCA6MfvJ+wYNNf2XBq/xak4YJwhgopTJl5xJBwmZcoSoXNgTso9fUCf+/P06Y3wwDFJEhUGTIpsBtjdHmciIeRb11QrpuRkLobW0JRx4PFvYzbJBQWePlgczWF8LJlMBMYiZuBkUgC4oiZw/eImW9D1xqOyEWsxNBqkfgaenwyuEjyJNmZ1Q9K/j3nD9qPzuUyHFg1EunOtGKtQwTEQgFmhoNopYf4gvD1AaYpbRvMj0RNm/yllUId8HhyoUrCkLWLsKsMFAaAPtAtIvoOVkXZ2golXF4vA== Received: from [98.138.101.129] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 13:20:01 -0000 Received: from [98.138.226.167] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 13:20:01 -0000 Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 13:20:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 331940.82363.bm@omp1068.mail.ne1.yahoo.com X-YMail-OSG: Wll27D0VM1l4Y3lY1UidKiI3tL3eYQE4KFvi7ZJo53v1IBzCkAwmrQ1tDdtYoJ_ JsSDsy9Ms69ne7RB0bDjjAwhuQzxaYu_LGpHT_oMwYdts4qrasyzwsgWzD8VdDX.x5qps4DU6gtU 7gWBoOHANAkPzWVlS_0C7U3kA.9hk1FJ7x8vdA96Tnme0bY0fo4nPQs1Jh2i0pvG4DoXRzwGASM3 8EFu5BJ4mK2FACLsf09i9MvczyFeTLeCxhtj8qrVl7XmRp8JXpuINAESQcXHZRvvWmg1dDHukI7y Hwk.MabFEgMdc9JCeiClQMBbUPP0NMsO.g33euBccQM7hqJ.reghW1Wx9dZ_M5cL25xpOYFuiXPC mROeONs_qZ2wtcHQCXTBgoxmdrx.2BQghk4dQZcqBXsfCJ5Px4N8JD_5AbCo.m1LyBcWIhAeb.52 _1v_RdIBYHpeHoCUzW6Ej9iDkl30QGK_YnfJF2EEKTMaEw7LnbSAvhA892uvwWntC_XVwVIBJ_Qi jUrAJgZyplXn3cIMht_mkREoTXzgdP.8_MYSViQ.3Dh_byUCjKX7tZm1pj6pqwgQSQdyAq0M3yOC 0w0OazU568fj9LlejpA-- Received: from jws100179.mail.ne1.yahoo.com by sendmailws132.mail.ne1.yahoo.com; Wed, 14 Sep 2016 13:20:00 +0000; 1473859200.866 Date: Wed, 14 Sep 2016 13:19:39 +0000 (UTC) From: To: "MORTON, ALFRED C (AL)" , Spencer Dawkins at IETF Message-ID: <1384062451.908563.1473859179499@mail.yahoo.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D459F65BD0A@NJFPSRVEXG0.research.att.com> References: <881483676.498721.1473807890669@mail.yahoo.com> <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D459F65BD0A@NJFPSRVEXG0.research.att.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_908562_68355134.1473859179484" Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 14:02:42 -0000 ------=_Part_908562_68355134.1473859179484 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, =C2=A0>I=E2=80=99m satisfied with this version, Last Call is next step.>I = think all my comments have been addressed. =C2=A0Great! ...>I=E2=80=99m glad to see the expanded Security Considerations.>One small= clarification could be made in the *next* version,>at the end of section 8= .1: =C2=A0=C2=A0 >=C2=A0 =C2=A0We recommend that implementation of PDM SHOU= LD have a limit on the=C2=A0 =C2=A0>size of the control blocks used. =C2=A0= >Since you=E2=80=99ve already said that the control block is quite small,>m= aybe this recommendation is on the number of control blocks? =C2=A0> =C2=A0= We recommend that implementation of PDM SHOULD have a limit on the =C2=A0> =C2=A0number of the control blocks used.=C2=A0> ^^^^^^ Yes. =C2=A0This should more properly be the number of entries possible for = the control block table. =C2=A0 That is, after 500 entries (or whatever the= implementation chooses), then the oldest entries would be dropped (or howe= ver the implementation chooses to handle it) >=C2=A0thanks authors! Thank YOU, Al! Nalini=C2=A0From: MORTON, ALFRED C (AL)=20 Sent: Tuesday, September 13, 2016 10:08 PM To: Spencer Dawkins at IETF; Nalini Elkins Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm-option@t= ools.ietf.org Subject: RE: AD review of draft-ietf-ippm-6man-pdm-option-03 =C2=A0I=E2=80= =99ll check first thing tomorrow,thanks!Al =C2=A0From: Spencer Dawkins at I= ETF [mailto:spencerdawkins.ietf@gmail.com]=20 Sent: Tuesday, September 13, 2016 7:54 PM To: Nalini Elkins Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm-option@t= ools.ietf.org Subject: Re: AD review of draft-ietf-ippm-6man-pdm-option-03 =C2=A0Nalini, = On Sep 13, 2016 18:04, wrote: > > Spencer, > > We have (we believe!) addressed your comments as well as those from Al Mo= rton as document shepherd. > > The new version is at: > > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-04 > > We have added quite a bit to the Security Considerations.=C2=A0 We have s= tarted implementation of PDM in the FreeBSD kernel, as I might have mention= ed before.=C2=A0 =C2=A0It has shed quite a bit of light on the potential ha= zards which may come up as far as DOS attacks, etc.=C2=A0 =C2=A0That was he= lpful to us in doing the Security Considerations. > > Many thanks to both you and Al Morton for your help and comments.I'm happ= y. Al, is this version ready for IETF Last Call?Thanks, Spencer> - Nalini E= lkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Hamilton) > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ________________________________ > From: Spencer Dawkins at IETF > To: draft-ietf-ippm-6man-pdm-option@tools.ietf.org > Cc: ippm@ietf.org > Sent: Monday, August 22, 2016 5:37 PM > Subject: AD review of draft-ietf-ippm-6man-pdm-option-03 > > > > Dear Authors, > > Nice work, and this would have been very valuable when I was implementing= performance monitors at Tektronix, so I imagine it's equally valuable now. > > I do have some comments that I'd like you let you consider before I reque= st IETF Last Call for this draft. Please let me know if you have any questi= ons, of course. > > Thanks, > > Spencer > > I saw the abstract following the table of contents mentioned in the sheph= erd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says > > =C2=A0 =C2=A0A Table of Contents (TOC) is required in all RFCs.=C2=A0 It = must be > =C2=A0 =C2=A0positioned after the Copyright Notice and before the Introdu= ction. > > It's probably a good thing to use the organization from RFC 7322, just to= sidestep reviewers who start out complaining about document structure nits= and then keep on typing. Not that I ever did that in six years as a Gen-AR= T reviwer, of course :-) ... > > I probably lack imagination, but perhaps other readers will, also. > > In this text > > =C2=A0 =C2=A0DELTATLR =3D Send time packet 2 - Receive time packet 1 > > and > > =C2=A0 =C2=A0Delta Time Last Sent =3D Receive time packet 2 - Send time p= acket 1 > > these are mathematical expressions, aren't they? If so, that would likely= be clearer if the right side terms had parentheses around the expression. > > (It's a bit odd that the first expression uses the abbreviation DELTATLR = and the second term is spelled out as "Delta Time Last Sent" - you might th= ink about which seems clearer, and do that with both expressions) > > In text like this > > =C2=A0 =C2=A0We propose a base unit for the time. > > you probably want to use a verb like "specify" (when the draft is publish= ed as an RFC, it will no longer be a proposal). There are multiple occurren= ces of "propose" in the document, so this comment applies in multiple place= s. > > For this text > > =C2=A0 =C2=A0Assume that two packets are sent for each ACK from the serve= r. > > you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. > > In this text from 6.3 PDM Flow - Multiple Send with Errors > > =C2=A0 =C2=A0One might wonder if all of the functions of PDM might be bet= ter > =C2=A0 =C2=A0suited to TCP or a TCP option. > > that's an interesting point in the broader sense, because (duh) putting P= DM in a TCP option doesn't help you with any other transport protocol (SCTP= , QUIC, what else are we doing these days? and, of course, they're all runn= ing over UDP anyway). I wonder if that's worth pointing out earlier in the = document, perhaps in Section 1.4? > > This text > > =C2=A0 =C2=A0Let's say that packet 4 STILL does not make it. > > is probably too breezy to translate well into other languages. Perhaps "i= s also lost"? (Yes, I talk like this, too) > > In the Security Considerations section, you might want to say something a= bout (1) what watching the unencrypted PDM values might tell attackers that= are doing pervasive monitoring (RFC 7258), and possibly about (2) what hap= pens if PDM is used as a covert channel. I don't think either of these will= be showstoppers at SECDIR review time, but I'd expect that demonstrating a= wareness of at least (1) will shorten the review comments cycle. Possibly a= lot, judging by recent ballots on other drafts ... #yiv9805285447 #yiv9805285447 -- _filtered #yiv9805285447 {font-family:C= alibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv9805285447 {font-famil= y:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv9805285447 #yiv9805285447 p.yiv= 9805285447MsoNormal, #yiv9805285447 li.yiv9805285447MsoNormal, #yiv98052854= 47 div.yiv9805285447MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:1= 2.0pt;}#yiv9805285447 a:link, #yiv9805285447 span.yiv9805285447MsoHyperlink= {color:blue;text-decoration:underline;}#yiv9805285447 a:visited, #yiv98052= 85447 span.yiv9805285447MsoHyperlinkFollowed {color:purple;text-decoration:= underline;}#yiv9805285447 p {margin-right:0in;margin-left:0in;font-size:12.= 0pt;}#yiv9805285447 pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;= }#yiv9805285447 p.yiv9805285447MsoAcetate, #yiv9805285447 li.yiv9805285447M= soAcetate, #yiv9805285447 div.yiv9805285447MsoAcetate {margin:0in;margin-bo= ttom:.0001pt;font-size:8.0pt;}#yiv9805285447 span.yiv9805285447EmailStyle18= {color:black;}#yiv9805285447 span.yiv9805285447BalloonTextChar {}#yiv98052= 85447 span.yiv9805285447EmailStyle21 {color:black;}#yiv9805285447 span.yiv9= 805285447HTMLPreformattedChar {}#yiv9805285447 .yiv9805285447MsoChpDefault = {font-size:10.0pt;} _filtered #yiv9805285447 {margin:1.0in 1.0in 1.0in 1.0i= n;}#yiv9805285447 div.yiv9805285447WordSection1 {}#yiv9805285447=20 ------=_Part_908562_68355134.1473859179484 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,


 =
>I=E2=80=99m sat= isfied with this version, Last Call is next step.
>I think all my comments have been address= ed.
 
Great!

<= span style=3D"font-size:11.0pt;">...
>I=E2=80= =99m glad to see the expanded Security Considerations.
>One small clarification could be made in the *next* versio= n,
>at the end of section 8.1:
 
  >   We recommend= that implementation of PDM SHOULD have a limit on the
   >size of the control blocks used.
 
>S= ince you=E2=80=99ve already said that the control block is quite small,
>maybe this recommendation is on the number of co= ntrol blocks?
 = ;
>   We recommend that implementation of = PDM SHOULD have a limit on the
 >  numb= er of the control blocks used.
 > ^^= ^^^^

Yes.  This should more properly be the number of = entries possible for the control block table.   That is, after 500 ent= ries (or whatever the implementation chooses), then the oldest entries woul= d be dropped (or however the implementation chooses to handle it)

> = thanks authors!

Thank YOU, Al!
<= span style=3D"font-size: 11pt;">
Nalini
=
F= rom: MORTON, ALFRED C (AL)
Sent: = Tuesday, September 13, 2016 10:08 PM
To: Spencer D= awkins at IETF; Nalini Elkins
Cc: MORTON, ALFRED C= (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm-option@tools.ietf.org
Subject: RE: AD review of draft-ietf-ippm-6man-pdm-optio= n-03
 <= /div>
I=E2=80=99ll check first thing tomorrow,
thanks!
Al
 
From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@= gmail.com]
Sent: Tuesday, September 13, 2016 = 7:54 PM
To: Nalini Elkins
Cc:= MORTON, ALFRED C (AL); ippm@i= etf.org; draft-ietf-ippm-6man-pdm-optio= n@tools.ietf.org
Subject: Re: AD review of dra= ft-ietf-ippm-6man-pdm-option-03
 
Nalini,
On Sep 13, 2016 18:= 04, <nalini.elkins@insidethestack.com> wrote:
>
> Spencer,
>
> We have (we believe!) addressed your comments as well as those f= rom Al Morton as document shepherd.
>
> The new version is at:
>
>= https://tools.ietf.org/h= tml/draft-ietf-ippm-6man-pdm-option-04
>
> We have added quite a bit to the Security Considerations.&nb= sp; We have started implementation of PDM in the FreeBSD kernel, as I might= have mentioned before.   It has shed quite a bit of light on the= potential hazards which may come up as far as DOS attacks, etc.  &nbs= p;That was helpful to us in doing the Security Considerations.
>
> Many thanks to both you and Al Morton for= your help and comments.
I'm happy. Al, is this version ready for= IETF Last Call?
Thanks,
Spencer
> - Nali= ni Elkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Hamilto= n)
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8= 360
>
>
>> ________________________________
>= ; From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> To: draft-ietf-ippm-6ma= n-pdm-option@tools.ietf.org
> Cc: ippm@ietf.org
> Sent: Mo= nday, August 22, 2016 5:37 PM
> Subject: AD review of = draft-ietf-ippm-6man-pdm-option-03
>
>
>
> Dear Authors,
>
> Nice work, and this would have been v= ery valuable when I was implementing performance monitors at Tektronix, so = I imagine it's equally valuable now.
>
> I do have some comments that I'd like you let you consider before I= request IETF Last Call for this draft. Please let me know if you have any = questions, of course.
>
> Thanks,=
>
> Spencer
&g= t;
> I saw the abstract following the table of content= s mentioned in the shepherd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says
>
>    A Table of Contents (TOC) is req= uired in all RFCs.  It must be
>    pos= itioned after the Copyright Notice and before the Introduction.
>
> It's probably a good thing to use the or= ganization from RFC 7322, just to sidestep reviewers who start out complain= ing about document structure nits and then keep on typing. Not that I ever = did that in six years as a Gen-ART reviwer, of course :-) ...
>
> I probably lack imagination, but perhaps o= ther readers will, also.
>
> In t= his text
>
>    DELTATL= R =3D Send time packet 2 - Receive time packet 1
>
> and
>
>  = ;  Delta Time Last Sent =3D Receive time packet 2 - Send time packet 1=
>
> these are mathematical expre= ssions, aren't they? If so, that would likely be clearer if the right side = terms had parentheses around the expression.
>
> (It's a bit odd that the first expression uses the abbrevia= tion DELTATLR and the second term is spelled out as "Delta Time Last Sent" = - you might think about which seems clearer, and do that with both expressi= ons)
>
> In text like this
>
>    We propose a base unit= for the time.
>
> you probably w= ant to use a verb like "specify" (when the draft is published as an RFC, it= will no longer be a proposal). There are multiple occurrences of "propose"= in the document, so this comment applies in multiple places.
>
> For this text
>
>    Assume that two packets are sent for each AC= K from the server.
>
> you might = point out that TCP does this, per RFC 1122 Section 4.2.3.2.
>
> In this text from 6.3 PDM Flow - Multiple Se= nd with Errors
>
>    O= ne might wonder if all of the functions of PDM might be better
>    suited to TCP or a TCP option.
&g= t;
> that's an interesting point in the broader sense,= because (duh) putting PDM in a TCP option doesn't help you with any other = transport protocol (SCTP, QUIC, what else are we doing these days? and, of = course, they're all running over UDP anyway). I wonder if that's worth poin= ting out earlier in the document, perhaps in Section 1.4?
>
> This text
>
>    Let's say that packet 4 STILL does not make it.
>
> is probably too breezy to transla= te well into other languages. Perhaps "is also lost"? (Yes, I talk like thi= s, too)
>
> In the Security Consi= derations section, you might want to say something about (1) what watching = the unencrypted PDM values might tell attackers that are doing pervasive mo= nitoring (RFC 7258), and possibly about (2) what happens if PDM is used as = a covert channel. I don't think either of these will be showstoppers at SEC= DIR review time, but I'd expect that demonstrating awareness of at least (1= ) will shorten the review comments cycle. Possibly a lot, judging by recent= ballots on other drafts ...


------=_Part_908562_68355134.1473859179484-- From nobody Wed Sep 14 07:44:04 2016 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B698A12BCE5; Wed, 14 Sep 2016 07:43:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147386423874.1831.6478482931478241488.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 07:43:58 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 14:43:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-05.txt Pages : 29 Date : 2016-09-14 Abstract: To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 14 08:09:21 2016 Return-Path: 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 7019712BABF for ; Wed, 14 Sep 2016 08:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 EVYOOrQlJ7RX for ; Wed, 14 Sep 2016 08:09:17 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 AEE1E12BA01 for ; Wed, 14 Sep 2016 07:34:03 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u82so21485398ywc.2 for ; Wed, 14 Sep 2016 07:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7begT7yzOQPqthoDhWH/xvfsWrwRQUPK2a/mCLM9K/k=; b=u5MqhYg3eRdsH4jfdZJNl2XnqVcmXECed8AJubgUFNW5DFeXk5ruRG/P5vSmqebPqz mtWUREe20qPuU3tZrO7KJYqEM5bjeI3dOtAz6zGW0//JjSvOoMfFxkijVOmARoPSefiR vwcCWuldDSfrL9P8DNNlJzp/td3vrp6F0ETeAjQ2LEwVPAkATcXcAa6DIR8bXWs/I8eX ZCB8H8d1ktctlOY5UB4TSHwVxQD5TGWCeuJeBb06WV6SRQamMzIJQW+ifXoE8zJXk8r/ 9fz7/a+tchDEaJJVMPNo0pZbobiMBWfEpIAsPP5bQ3EnNMZaH6+wQUgw7bURhV5m9SfK BbIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7begT7yzOQPqthoDhWH/xvfsWrwRQUPK2a/mCLM9K/k=; b=N23EACHUxC2EM0BlfFFsQiPd2taJcZxZ2maJ8k9gZEP6LTlgzYZYdwiU/fCs86Xs9t QhbcuDhSDpy5utKeENHwTq0W2XGE6zASoloQ602hByCfCJ4XA/IGRk1Q1+yYUKCHXt2b HRCGo4un9n2n+3sXAVplHrvJTswIpsOovw8XDc5ZqYx8LKZW/oXekln9+dlMKlSgehiI BD3PfaWcWgVcvlgEx4o92EL+ZoqkxWgVHgb6/DMKl8o6V8GLagLg0vCfRx4NPPEqRU/I GHUvGrWM91OXzQZl+vPfBcvyn5l0/sGWUtHxRwwNS1HbYQVEGkL5dRrtGbs3r6FOgtYq G7TA== X-Gm-Message-State: AE9vXwOngMrTl6hrHiANmjdGS9zWAPBFRtagb4qp+Mofau5A2o5IPfpMxp8CcIBchIKr48djo6kJrAIBNUVD4Q== X-Received: by 10.129.93.86 with SMTP id r83mr3036620ywb.211.1473863642970; Wed, 14 Sep 2016 07:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Wed, 14 Sep 2016 07:34:02 -0700 (PDT) In-Reply-To: <1384062451.908563.1473859179499@mail.yahoo.com> References: <881483676.498721.1473807890669@mail.yahoo.com> <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D459F65BD0A@NJFPSRVEXG0.research.att.com> <1384062451.908563.1473859179499@mail.yahoo.com> From: Spencer Dawkins at IETF Date: Wed, 14 Sep 2016 09:34:02 -0500 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=001a114d805ce30131053c789e8d Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 15:09:20 -0000 --001a114d805ce30131053c789e8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Nalini, On Wed, Sep 14, 2016 at 8:19 AM, wrote: > Hi all, > > > > >I=E2=80=99m satisfied with this version, Last Call is next step. > >I think all my comments have been addressed. > > Great! > > ... > >I=E2=80=99m glad to see the expanded Security Considerations. > >One small clarification could be made in the **next** version, > >at the end of section 8.1: > > > We recommend that implementation of PDM SHOULD have a limit on the > >size of the control blocks used. > > >Since you=E2=80=99ve already said that the control block is quite small, > >maybe this recommendation is on the number of control blocks? > > > We recommend that implementation of PDM SHOULD have a limit on the > > number of the control blocks used. > > ^^^^^^ > > Yes. This should more properly be the number of entries possible for the > control block table. That is, after 500 entries (or whatever the > implementation chooses), then the oldest entries would be dropped (or > however the implementation chooses to handle it) > > > thanks authors! > > Thank YOU, Al! > Please let me know if you'd like to make that change before Last Call. (My experience as a Gen-ART reviewer is that once reviewers find one issue, they come up with more, so not giving them one to start with that you already know about is a good thing. But your mileage may differ, of course) Spencer > > Nalini > > *From:* MORTON, ALFRED C (AL) > *Sent:* Tuesday, September 13, 2016 10:08 PM > *To:* Spencer Dawkins at IETF; Nalini Elkins > *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- > option@tools.ietf.org > *Subject:* RE: AD review of draft-ietf-ippm-6man-pdm-option-03 > > I=E2=80=99ll check first thing tomorrow, > thanks! > Al > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com > ] > *Sent:* Tuesday, September 13, 2016 7:54 PM > *To:* Nalini Elkins > *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- > option@tools.ietf.org > *Subject:* Re: AD review of draft-ietf-ippm-6man-pdm-option-03 > > Nalini, > On Sep 13, 2016 18:04, wrote: > > > > Spencer, > > > > We have (we believe!) addressed your comments as well as those from Al > Morton as document shepherd. > > > > The new version is at: > > > > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-04 > > > > We have added quite a bit to the Security Considerations. We have > started implementation of PDM in the FreeBSD kernel, as I might have > mentioned before. It has shed quite a bit of light on the potential > hazards which may come up as far as DOS attacks, etc. That was helpful = to > us in doing the Security Considerations. > > > > Many thanks to both you and Al Morton for your help and comments. > I'm happy. Al, is this version ready for IETF Last Call? > Thanks, > Spencer > > - Nalini Elkins - on behalf of the PDM co-authors (Mike Ackermann and > Rob Hamilton) > > Inside Products, Inc. > > www.insidethestack.com > > (831) 659-8360 > > > > > > > > ________________________________ > > From: Spencer Dawkins at IETF > > To: draft-ietf-ippm-6man-pdm-option@tools.ietf.org > > Cc: ippm@ietf.org > > Sent: Monday, August 22, 2016 5:37 PM > > Subject: AD review of draft-ietf-ippm-6man-pdm-option-03 > > > > > > > > Dear Authors, > > > > Nice work, and this would have been very valuable when I was > implementing performance monitors at Tektronix, so I imagine it's equally > valuable now. > > > > I do have some comments that I'd like you let you consider before I > request IETF Last Call for this draft. Please let me know if you have any > questions, of course. > > > > Thanks, > > > > Spencer > > > > I saw the abstract following the table of contents mentioned in the > shepherd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 > says > > > > A Table of Contents (TOC) is required in all RFCs. It must be > > positioned after the Copyright Notice and before the Introduction. > > > > It's probably a good thing to use the organization from RFC 7322, just > to sidestep reviewers who start out complaining about document structure > nits and then keep on typing. Not that I ever did that in six years as a > Gen-ART reviwer, of course :-) ... > > > > I probably lack imagination, but perhaps other readers will, also. > > > > In this text > > > > DELTATLR =3D Send time packet 2 - Receive time packet 1 > > > > and > > > > Delta Time Last Sent =3D Receive time packet 2 - Send time packet 1 > > > > these are mathematical expressions, aren't they? If so, that would > likely be clearer if the right side terms had parentheses around the > expression. > > > > (It's a bit odd that the first expression uses the abbreviation DELTATL= R > and the second term is spelled out as "Delta Time Last Sent" - you might > think about which seems clearer, and do that with both expressions) > > > > In text like this > > > > We propose a base unit for the time. > > > > you probably want to use a verb like "specify" (when the draft is > published as an RFC, it will no longer be a proposal). There are multiple > occurrences of "propose" in the document, so this comment applies in > multiple places. > > > > For this text > > > > Assume that two packets are sent for each ACK from the server. > > > > you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. > > > > In this text from 6.3 PDM Flow - Multiple Send with Errors > > > > One might wonder if all of the functions of PDM might be better > > suited to TCP or a TCP option. > > > > that's an interesting point in the broader sense, because (duh) putting > PDM in a TCP option doesn't help you with any other transport protocol > (SCTP, QUIC, what else are we doing these days? and, of course, they're a= ll > running over UDP anyway). I wonder if that's worth pointing out earlier i= n > the document, perhaps in Section 1.4? > > > > This text > > > > Let's say that packet 4 STILL does not make it. > > > > is probably too breezy to translate well into other languages. Perhaps > "is also lost"? (Yes, I talk like this, too) > > > > In the Security Considerations section, you might want to say something > about (1) what watching the unencrypted PDM values might tell attackers > that are doing pervasive monitoring (RFC 7258), and possibly about (2) wh= at > happens if PDM is used as a covert channel. I don't think either of these > will be showstoppers at SECDIR review time, but I'd expect that > demonstrating awareness of at least (1) will shorten the review comments > cycle. Possibly a lot, judging by recent ballots on other drafts ... > > > --001a114d805ce30131053c789e8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Nalini,

On Wed, Sep 14, 2016 at 8:19 AM, <nalini.elkin= s@insidethestack.com> wrote:
Hi all,


=C2=A0
>I=E2=80=99m satisfied with this version, Last Ca= ll is next step.
>I th= ink all my comments have been addressed.
=C2=A0
Great!

...
>I=E2=80=99m glad to see the expa= nded Security Considerations.
>One small clarification could be made in the *next* version= ,
>at the end of secti= on 8.1:
=C2=A0
=C2=A0 >=C2=A0 =C2=A0We recommend that implementation of PDM SHOULD = have a limit on the
=C2= =A0 =C2=A0>size of the control blocks used.
=C2=A0
>Since you=E2=80=99ve already said that the control block is quite = small,
>maybe this rec= ommendation is on the number of control blocks?
=C2=A0
> =C2=A0 We recommend that implementation of PDM SHOULD have a limit= on the
=C2=A0> =C2=A0number of the control blocks used.
<= div style=3D"font-size:16px" dir=3D"ltr">=C2= =A0> ^^^^^^

Yes.=C2=A0 This should more properly be the number of entries p= ossible for the control block table. =C2=A0 That is, after 500 entries (or = whatever the implementation chooses), then the oldest entries would be drop= ped (or however the implementation chooses to handle it)
<= br>
>=C2=A0thanks authors!

Thank YOU, Al= !
=

Please let me know if you'd like to make that chang= e before Last Call.

(My experience as a Gen-ART re= viewer is that once reviewers find one issue, they come up with more, so no= t giving them one to start with that you already know about is a good thing= . But your mileage may differ, of course)

Spencer<= /div>
=C2=A0
=

Nalini<= /div>
=C2=A0
From: MORTON, ALF= RED C (AL)
Sent: Tuesday, September 13, 2016 10:0= 8 PM
To: Spencer Dawkins at IETF; Nalini ElkinsCc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-= pdm-option@tools.ietf.org
Subject: RE: AD= review of draft-ietf-ippm-6man-pdm-option-03
=
=C2=A0
I=E2=80=99ll check = first thing tomorrow,
tha= nks!
Al
= =C2=A0
<= div>From: Spencer Dawkins at IETF [mailto:spen= cerdawkins.ietf@gmail.com]
Sent: Tuesday= , September 13, 2016 7:54 PM
To: Nalini Elkins
Cc: MORTON, ALFRED C (AL); ippm@ietf.org= ; draft-ietf-ippm-6man-pdm-op= tion@tools.ietf.org
Subject: Re: AD review of = draft-ietf-ippm-6man-pdm-option-03
=C2= =A0
Nalini,
On Sep 13, 2016 18:04, <nalini.elkins@insidethestack.com> wrote:
>
> Spencer,
>
> We have (we believe!) addressed your comments as well as = those from Al Morton as document shepherd.
>
> The new version is at:
>
> https://tools.ie= tf.org/html/draft-ietf-ippm-6man-pdm-option-04
>
> We have added quite a bit to the Security C= onsiderations.=C2=A0 We have started implementation of PDM in the FreeBSD k= ernel, as I might have mentioned before.=C2=A0 =C2=A0It has shed quite a bi= t of light on the potential hazards which may come up as far as DOS attacks= , etc.=C2=A0 =C2=A0That was helpful to us in doing the Security Considerati= ons.
>
> Many thanks to both you = and Al Morton for your help and comments.
I'm happy. Al, is t= his version ready for IETF Last Call?
Thanks,
Spencer<= /div>
> - Nalini Elkins - on behalf of the PDM co-authors (Mike Acke= rmann and Rob Hamilton)
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
&g= t;
>
> __________________________= ______
> From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
> To: draft-ietf-ippm-6man-= pdm-option@tools.ietf.org
> Cc: ippm@= ietf.org
> Sent: Monday, August 22, 2016 5:37 PM> Subject: AD review of draft-ietf-ippm-6man-pdm-o= ption-03
>
>
&g= t;
> Dear Authors,
>
> Nice work, and this would have been very valuable when I was imp= lementing performance monitors at Tektronix, so I imagine it's equally = valuable now.
>
> I do have some = comments that I'd like you let you consider before I request IETF Last = Call for this draft. Please let me know if you have any questions, of cours= e.
>
> Thanks,
= >
> Spencer
>
> I saw the abstract following the table of contents mentioned in the = shepherd write-up, but https://tools.iet= f.org/html/rfc7322#section-4.7 says
>
> =C2=A0 =C2=A0A Table of Contents (TOC) is required in all R= FCs.=C2=A0 It must be
> =C2=A0 =C2=A0positioned after = the Copyright Notice and before the Introduction.
>> It's probably a good thing to use the organization= from RFC 7322, just to sidestep reviewers who start out complaining about = document structure nits and then keep on typing. Not that I ever did that i= n six years as a Gen-ART reviwer, of course :-) ...
><= br clear=3D"none">> I probably lack imagination, but perhaps other reade= rs will, also.
>
> In this text>
> =C2=A0 =C2=A0DELTATLR =3D Send= time packet 2 - Receive time packet 1
>
> and
>
> =C2=A0 =C2=A0De= lta Time Last Sent =3D Receive time packet 2 - Send time packet 1
>
> these are mathematical expressions, a= ren't they? If so, that would likely be clearer if the right side terms= had parentheses around the expression.
>
> (It's a bit odd that the first expression uses the abbreviat= ion DELTATLR and the second term is spelled out as "Delta Time Last Se= nt" - you might think about which seems clearer, and do that with both= expressions)
>
> In text like th= is
>
> =C2=A0 =C2=A0We propose a = base unit for the time.
>
> you p= robably want to use a verb like "specify" (when the draft is publ= ished as an RFC, it will no longer be a proposal). There are multiple occur= rences of "propose" in the document, so this comment applies in m= ultiple places.
>
> For this text=
>
> =C2=A0 =C2=A0Assume that two= packets are sent for each ACK from the server.
>
> you might point out that TCP does this, per RFC 1122 Sec= tion 4.2.3.2.
>
> In this text fr= om 6.3 PDM Flow - Multiple Send with Errors
>
> =C2=A0 =C2=A0One might wonder if all of the functions of PDM= might be better
> =C2=A0 =C2=A0suited to TCP or a TCP= option.
>
> that's an intere= sting point in the broader sense, because (duh) putting PDM in a TCP option= doesn't help you with any other transport protocol (SCTP, QUIC, what e= lse are we doing these days? and, of course, they're all running over U= DP anyway). I wonder if that's worth pointing out earlier in the docume= nt, perhaps in Section 1.4?
>
> T= his text
>
> =C2=A0 =C2=A0Let'= ;s say that packet 4 STILL does not make it.
>
> is probably too breezy to translate well into other languag= es. Perhaps "is also lost"? (Yes, I talk like this, too)
>
> In the Security Considerations sectio= n, you might want to say something about (1) what watching the unencrypted = PDM values might tell attackers that are doing pervasive monitoring (RFC 72= 58), and possibly about (2) what happens if PDM is used as a covert channel= . I don't think either of these will be showstoppers at SECDIR review t= ime, but I'd expect that demonstrating awareness of at least (1) will s= horten the review comments cycle. Possibly a lot, judging by recent ballots= on other drafts ...


--001a114d805ce30131053c789e8d-- From nobody Wed Sep 14 08:21:11 2016 Return-Path: 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 3A5DA12B46A for ; Wed, 14 Sep 2016 08:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 HQOcWkgiDjqR for ; Wed, 14 Sep 2016 08:21:05 -0700 (PDT) Received: from nm2-vm1.bullet.mail.ne1.yahoo.com (nm2-vm1.bullet.mail.ne1.yahoo.com [98.138.91.33]) (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 C9A5C12B847 for ; Wed, 14 Sep 2016 07:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473864370; bh=euhkyEOysWdSWpLASe2dQaGqzl49USQOPwVPFvThkxE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=hyUzslXcR9XrFVOg6irmYANLOgc00PuHsTL3AL3J0y3wV7SYJMaHbxiArKqurxCgeoUns6qpBTzLFmpMT/t48DiuZWtetOykAAtrwMrf7ajzg35ingll8E7VJrtI521UgPsuyJ7oJNHgMwXHr0d8np8IaHXvqYUcCzb4Qf03g2febM750mP+6gguh1hIkHfTaN2Y/xW178boer20AgGHmPfM11qI1zJ3fdMbM5FIfNK7QyzSII+JAN/ZySZyXvrsmF17BZOJJo6y/SzZEzvW2ZLG9aDT7c7O1mSqckxI4+dJpoqJsUp6aCNJifZ5M3NoZ452CVZY7nqKYsMkGukaJw== Received: from [98.138.101.128] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 14:46:10 -0000 Received: from [98.138.89.167] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 14:46:09 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 14:46:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 264159.78476.bm@omp1023.mail.ne1.yahoo.com X-YMail-OSG: Av4HCucVM1nLlYeFICGYPpC0on62w6k74IEPnhcPQUI_WoXDfeTbNcUy6lLB_qS n4Ew6KNyfcRisKvP7opclT_ksYl9spvngFoePsi0t_DDug4h0qCcRjl3B_FSH2He2nHFSt2hF0J5 tRGJvxT4RDo6qvDJKLHQqrH_bHs7RwTOc7L9eZf0Lg0YgdUIR7WTaeNCG8wj1Q.TBzQw1u5i9nNM YSBh5t8btqeprJilxG2h.XvFFXPunUwwlfWZpNAWuG2cQjlXLXoBBtFUedtPlNn9yVMgX8.pS_qP f4m4ljmq1pbyF05TYGWeQEaODc5CuSNr04w86CJYl0oTLfWgCoPzCd.zZoV.tphLMT.oaKXa6btB jmyYCXxprus2sWYIlcdasNd75XlGrkjowdg_8yWS7gXUSbrdCyU6jRvp5V_yOP1qMi13E9WMchyI 6epGt6KZDtlrc1LIjPw0KptMindxdQR7lbMCoZDnm_Q1DUxREZzk4jn.TVrgNw9T.FzJJOOTf7tV vGS72OB0pbo3GuCFzdPF_IG_FmlP9h2pf7y6bnepTzM0GWfinaLa9BpWlnxZEAELPPwQ- Received: from jws100235.mail.ne1.yahoo.com by sendmailws159.mail.ne1.yahoo.com; Wed, 14 Sep 2016 14:46:09 +0000; 1473864369.684 Date: Wed, 14 Sep 2016 14:46:08 +0000 (UTC) From: To: Spencer Dawkins at IETF Message-ID: <316291956.967191.1473864368299@mail.yahoo.com> In-Reply-To: References: <881483676.498721.1473807890669@mail.yahoo.com> <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D459F65BD0A@NJFPSRVEXG0.research.att.com> <1384062451.908563.1473859179499@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_967189_1148667825.1473864368247" Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 15:21:09 -0000 ------=_Part_967189_1148667825.1473864368247 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Spencer, >Please let me know if you'd like to make that change before Last Call. >(My experience as a Gen-ART reviewer is that once reviewers find one issue= , they come up with more, so not giving them one to start with that you alr= eady know about is a good thing. But >your mileage may differ, of course) Changes made. =C2=A0New version at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-05 Thank you for your guidance. Nalini =C2=A0 Nalini=C2=A0From: MORTON, ALFRED C (AL)=20 Sent: Tuesday, September 13, 2016 10:08 PM To: Spencer Dawkins at IETF; Nalini Elkins Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@= tools.ietf.org Subject: RE: AD review of draft-ietf-ippm-6man-pdm- option-03 =C2=A0I=E2=80= =99ll check first thing tomorrow,thanks!Al =C2=A0From: Spencer Dawkins at I= ETF [mailto:spencerdawkins.ietf@ gmail.com]=20 Sent: Tuesday, September 13, 2016 7:54 PM To: Nalini Elkins Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@= tools.ietf.org Subject: Re: AD review of draft-ietf-ippm-6man-pdm- option-03 =C2=A0Nalini,= On Sep 13, 2016 18:04, wrote: > > Spencer, > > We have (we believe!) addressed your comments as well as those from Al Mo= rton as document shepherd. > > The new version is at: > > https://tools.ietf.org/html/ draft-ietf-ippm-6man-pdm- option-04 > > We have added quite a bit to the Security Considerations.=C2=A0 We have s= tarted implementation of PDM in the FreeBSD kernel, as I might have mention= ed before.=C2=A0 =C2=A0It has shed quite a bit of light on the potential ha= zards which may come up as far as DOS attacks, etc.=C2=A0 =C2=A0That was he= lpful to us in doing the Security Considerations. > > Many thanks to both you and Al Morton for your help and comments.I'm happ= y. Al, is this version ready for IETF Last Call?Thanks, Spencer> - Nalini E= lkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Hamilton) > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ______________________________ __ > From: Spencer Dawkins at IETF > To: draft-ietf-ippm-6man-pdm- option@tools.ietf.org > Cc: ippm@ietf.org > Sent: Monday, August 22, 2016 5:37 PM > Subject: AD review of draft-ietf-ippm-6man-pdm- option-03 > > > > Dear Authors, > > Nice work, and this would have been very valuable when I was implementing= performance monitors at Tektronix, so I imagine it's equally valuable now. > > I do have some comments that I'd like you let you consider before I reque= st IETF Last Call for this draft. Please let me know if you have any questi= ons, of course. > > Thanks, > > Spencer > > I saw the abstract following the table of contents mentioned in the sheph= erd write-up, but https://tools.ietf.org/html/ rfc7322#section-4.7 says > > =C2=A0 =C2=A0A Table of Contents (TOC) is required in all RFCs.=C2=A0 It = must be > =C2=A0 =C2=A0positioned after the Copyright Notice and before the Introdu= ction. > > It's probably a good thing to use the organization from RFC 7322, just to= sidestep reviewers who start out complaining about document structure nits= and then keep on typing. Not that I ever did that in six years as a Gen-AR= T reviwer, of course :-) ... > > I probably lack imagination, but perhaps other readers will, also. > > In this text > > =C2=A0 =C2=A0DELTATLR =3D Send time packet 2 - Receive time packet 1 > > and > > =C2=A0 =C2=A0Delta Time Last Sent =3D Receive time packet 2 - Send time p= acket 1 > > these are mathematical expressions, aren't they? If so, that would likely= be clearer if the right side terms had parentheses around the expression. > > (It's a bit odd that the first expression uses the abbreviation DELTATLR = and the second term is spelled out as "Delta Time Last Sent" - you might th= ink about which seems clearer, and do that with both expressions) > > In text like this > > =C2=A0 =C2=A0We propose a base unit for the time. > > you probably want to use a verb like "specify" (when the draft is publish= ed as an RFC, it will no longer be a proposal). There are multiple occurren= ces of "propose" in the document, so this comment applies in multiple place= s. > > For this text > > =C2=A0 =C2=A0Assume that two packets are sent for each ACK from the serve= r. > > you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. > > In this text from 6.3 PDM Flow - Multiple Send with Errors > > =C2=A0 =C2=A0One might wonder if all of the functions of PDM might be bet= ter > =C2=A0 =C2=A0suited to TCP or a TCP option. > > that's an interesting point in the broader sense, because (duh) putting P= DM in a TCP option doesn't help you with any other transport protocol (SCTP= , QUIC, what else are we doing these days? and, of course, they're all runn= ing over UDP anyway). I wonder if that's worth pointing out earlier in the = document, perhaps in Section 1.4? > > This text > > =C2=A0 =C2=A0Let's say that packet 4 STILL does not make it. > > is probably too breezy to translate well into other languages. Perhaps "i= s also lost"? (Yes, I talk like this, too) > > In the Security Considerations section, you might want to say something a= bout (1) what watching the unencrypted PDM values might tell attackers that= are doing pervasive monitoring (RFC 7258), and possibly about (2) what hap= pens if PDM is used as a covert channel. I don't think either of these will= be showstoppers at SECDIR review time, but I'd expect that demonstrating a= wareness of at least (1) will shorten the review comments cycle. Possibly a= lot, judging by recent ballots on other drafts ... =20 =20 ------=_Part_967189_1148667825.1473864368247 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Spencer,


>Please let me know if you'd like to make that change before Last C= all.

>(My experie= nce as a Gen-ART reviewer is that once reviewers find one issue, they come = up with more, so not giving them one to start with that you already know ab= out is a good thing. But >your mileage may differ, of course)

Changes made.  New version at:


Thank y= ou for your guidance.

Nalini
<= div id=3D"yui_3_16_0_ym19_1_1473860450315_40677">
 
<= div style=3D"font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, L= ucida Grande, sans-serif;font-size:16px;" id=3D"yui_3_16_0_ym19_1_147386045= 0315_40730">

Nalini
 
Fr= om: MORTON, ALFRED C (AL)
Sent: Tu= esday, September 13, 2016 10:08 PM
To: Spencer Daw= kins at IETF; Nalini Elkins
Cc: MORTON, ALFRED C (= AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@tools.ietf.orgSubject: RE: AD review of draft-ietf-ippm-6man-pdm-= option-03
 
I=E2=80=99ll check first thing tomorrow,
= thanks!
Al
&n= bsp;
From: Spencer Dawkins a= t IETF [mailto:spencerdawkins.ietf@ gmail.com]
Sent= : Tuesday, September 13, 2016 7:54 PM
To: Nali= ni Elkins
Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@tools.ietf.org
<= b>Subject: Re: AD review of draft-ietf-ippm-6man-pdm- option-03<= /div>
 
Nalini,
On Sep 13, 2016 = 18:04, <nalini.elkins@insidethestack. com> wrote:
>
> Spencer,
>
> We have (we believe!) addressed your comments as well as tho= se from Al Morton as document shepherd.
>
> The new version is at:
>
= > https://tools.ietf.o= rg/html/ draft-ietf-ippm-6man-pdm- option-04
>
> We have added quite a bit to the Security Consideration= s.  We have started implementation of PDM in the FreeBSD kernel, as I = might have mentioned before.   It has shed quite a bit of light o= n the potential hazards which may come up as far as DOS attacks, etc. =  That was helpful to us in doing the Security Considerations.
>
> Many thanks to both you and Al Morto= n for your help and comments.
I'm happy. Al, is this version read= y for IETF Last Call?
Thanks,
Spencer
> -= Nalini Elkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Ha= milton)
> Inside Products, Inc.
>= www.insidethestack.com
> (831) 659-8360
>
>
>
> = ______________________________ __
> From: Spencer Dawk= ins at IETF <spencerdawkins.ietf@gmail.com >
>= To: draft-ietf-ippm-6man-pdm- option@tools= .ietf.org
> Cc: ippm@ietf.org
> Sent: Monday, August 22, 20= 16 5:37 PM
> Subject: AD review of draft-ietf-ippm-6ma= n-pdm- option-03
>
>
>
> Dear Authors,
>
> Nice work, and this would have been very valuable when I= was implementing performance monitors at Tektronix, so I imagine it's equa= lly valuable now.
>
> I do have s= ome comments that I'd like you let you consider before I request IETF Last = Call for this draft. Please let me know if you have any questions, of cours= e.
>
> Thanks,
= >
> Spencer
>
> I saw the abstract following the table of contents mentioned in the = shepherd write-up, but https://tools.iet= f.org/html/ rfc7322#section-4.7 says
>
>    A Table of Contents (TOC) is required in all RFCs.=   It must be
>    positioned after the = Copyright Notice and before the Introduction.
>
> It's probably a good thing to use the organization from RF= C 7322, just to sidestep reviewers who start out complaining about document= structure nits and then keep on typing. Not that I ever did that in six ye= ars as a Gen-ART reviwer, of course :-) ...
>
> I probably lack imagination, but perhaps other readers will,= also.
>
> In this text
>
>    DELTATLR =3D Send time p= acket 2 - Receive time packet 1
>
&g= t; and
>
>    Delta Tim= e Last Sent =3D Receive time packet 2 - Send time packet 1
>
> these are mathematical expressions, aren't th= ey? If so, that would likely be clearer if the right side terms had parenth= eses around the expression.
>
> (= It's a bit odd that the first expression uses the abbreviation DELTATLR and= the second term is spelled out as "Delta Time Last Sent" - you might think= about which seems clearer, and do that with both expressions)
>
> In text like this
><= br clear=3D"none">>    We propose a base unit for the time.>
> you probably want to use a verb= like "specify" (when the draft is published as an RFC, it will no longer b= e a proposal). There are multiple occurrences of "propose" in the document,= so this comment applies in multiple places.
>
> For this text
>
>=    Assume that two packets are sent for each ACK from the server= .
>
> you might point out that TC= P does this, per RFC 1122 Section 4.2.3.2.
>
> In this text from 6.3 PDM Flow - Multiple Send with Errors>
>    One might wonder = if all of the functions of PDM might be better
>  = ;  suited to TCP or a TCP option.
>
> that's an interesting point in the broader sense, because (duh) p= utting PDM in a TCP option doesn't help you with any other transport protoc= ol (SCTP, QUIC, what else are we doing these days? and, of course, they're = all running over UDP anyway). I wonder if that's worth pointing out earlier= in the document, perhaps in Section 1.4?
>
> This text
>
> &nbs= p;  Let's say that packet 4 STILL does not make it.
= >
> is probably too breezy to translate well into o= ther languages. Perhaps "is also lost"? (Yes, I talk like this, too)
>
> In the Security Considerations sect= ion, you might want to say something about (1) what watching the unencrypte= d PDM values might tell attackers that are doing pervasive monitoring (RFC = 7258), and possibly about (2) what happens if PDM is used as a covert chann= el. I don't think either of these will be showstoppers at SECDIR review tim= e, but I'd expect that demonstrating awareness of at least (1) will shorten= the review comments cycle. Possibly a lot, judging by recent ballots on ot= her drafts ...





------=_Part_967189_1148667825.1473864368247-- From nobody Wed Sep 14 09:10:20 2016 Return-Path: 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 72EEC12B357 for ; Wed, 14 Sep 2016 09:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 kWKZXfOafmhF for ; Wed, 14 Sep 2016 09:10:13 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 0982912B350 for ; Wed, 14 Sep 2016 08:54:55 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id d69so15065339ybf.2 for ; Wed, 14 Sep 2016 08:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UICJNeosklJnzXtQeRJOO6R5gl+Uh1jRoqNRHaWO9iw=; b=wADnBD135iXfpFukjttm8xEcngHFpYaTslgzwwVCr69Is3BiJl6VjDGiOkstiDHRxT pXLKj+MxT/3UR4gkwXxlFeUIn+MJqaXIfOlsKkqWc0qNgWbccLEjFkpctzIkPdfhTNNS iWD6rtKm1HVJ7LT/roj7BMauU1Y58tvE3jAulY6GPyv37aR5cj1gJOBUmw2N63Fpanng l6oGCGMGeuCaXOv0n9gJVD387T8+H5hEn56KTpCQ8N6dtYLSHRHk4yQVJFTnlKblUNKU m6N1qxFWy7TLeraetXGo/vgYXANW9XxzERm2gDTh9Q5Ffuhmh4iyJ5nkTREZYKF5XaUg Gp5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UICJNeosklJnzXtQeRJOO6R5gl+Uh1jRoqNRHaWO9iw=; b=hGgBuPVS5RqiEMtV7TOeHs/PX7cIfL6ZHm0RaCyicKKLz8dYHVpCBfpCKlTOpQPBxI FZoSRc8N8bLWlXmfim8EB3wmyRRXi/gHOOIfXaoziHGzatAtSa1Ph5GmUODBQHpbFiHG qen3WTJ4ZIdT/zAvULZwJnm9pgaXXqMC6CcEMwIvytgLKRhhe02566Qmo57JHk2xb1Ob +433jWqFjqMPEV0GOVpar1FTUn6BbWvxFkC5dG7ln/dM7W+I7vHPoCP2UgKCpW6FD91N AIIttX5LWx6VlZDAXogtTWOXOJPffv9KG1YCgkSS4p5Szjmz0YUA0jb4M75HzJU6qx4p /asA== X-Gm-Message-State: AE9vXwOEIEHilovh2dLtgeHzmdssCfy8rfbmhmZ1/RzgRfcWkW8+Uu/2wwxqu/CmtH0Btma9Jo78EuVMBnfdFA== X-Received: by 10.37.69.7 with SMTP id s7mr68769yba.169.1473868494140; Wed, 14 Sep 2016 08:54:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Wed, 14 Sep 2016 08:54:53 -0700 (PDT) In-Reply-To: <316291956.967191.1473864368299@mail.yahoo.com> References: <881483676.498721.1473807890669@mail.yahoo.com> <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D459F65BD0A@NJFPSRVEXG0.research.att.com> <1384062451.908563.1473859179499@mail.yahoo.com> <316291956.967191.1473864368299@mail.yahoo.com> From: Spencer Dawkins at IETF Date: Wed, 14 Sep 2016 10:54:53 -0500 Message-ID: To: Nalini Elkins Content-Type: multipart/alternative; boundary=001a11c16e6009f9eb053c79c04c Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 16:10:19 -0000 --001a11c16e6009f9eb053c79c04c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Nalini, On Wed, Sep 14, 2016 at 9:46 AM, wrote: > Spencer, > > > > >Please let me know if you'd like to make that change before Last Call. > > >(My experience as a Gen-ART reviewer is that once reviewers find one > issue, they come up with more, so not giving them one to start with that > you already know about is a good thing. But >your mileage may differ, of > course) > > Changes made. New version at: > > https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-05 > I checked the diff (and it was what I expected), and requested Last Call. > Thank you for your guidance. > Oh, thank you :-) Spencer > > Nalini > > > > > Nalini > > *From:* MORTON, ALFRED C (AL) > *Sent:* Tuesday, September 13, 2016 10:08 PM > *To:* Spencer Dawkins at IETF; Nalini Elkins > *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- > option@tools.ietf.org > *Subject:* RE: AD review of draft-ietf-ippm-6man-pdm- option-03 > > I=E2=80=99ll check first thing tomorrow, > thanks! > Al > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@ gmail.com > ] > *Sent:* Tuesday, September 13, 2016 7:54 PM > *To:* Nalini Elkins > *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- > option@tools.ietf.org > *Subject:* Re: AD review of draft-ietf-ippm-6man-pdm- option-03 > > Nalini, > On Sep 13, 2016 18:04, > wrote: > > > > Spencer, > > > > We have (we believe!) addressed your comments as well as those from Al > Morton as document shepherd. > > > > The new version is at: > > > > https://tools.ietf.org/html/ draft-ietf-ippm-6man-pdm- option-04 > > > > > We have added quite a bit to the Security Considerations. We have > started implementation of PDM in the FreeBSD kernel, as I might have > mentioned before. It has shed quite a bit of light on the potential > hazards which may come up as far as DOS attacks, etc. That was helpful = to > us in doing the Security Considerations. > > > > Many thanks to both you and Al Morton for your help and comments. > I'm happy. Al, is this version ready for IETF Last Call? > Thanks, > Spencer > > - Nalini Elkins - on behalf of the PDM co-authors (Mike Ackermann and > Rob Hamilton) > > Inside Products, Inc. > > www.insidethestack.com > > (831) 659-8360 > > > > > > > > ______________________________ __ > > From: Spencer Dawkins at IETF > > To: draft-ietf-ippm-6man-pdm- option@tools.ietf.org > > > Cc: ippm@ietf.org > > Sent: Monday, August 22, 2016 5:37 PM > > Subject: AD review of draft-ietf-ippm-6man-pdm- option-03 > > > > > > > > Dear Authors, > > > > Nice work, and this would have been very valuable when I was > implementing performance monitors at Tektronix, so I imagine it's equally > valuable now. > > > > I do have some comments that I'd like you let you consider before I > request IETF Last Call for this draft. Please let me know if you have any > questions, of course. > > > > Thanks, > > > > Spencer > > > > I saw the abstract following the table of contents mentioned in the > shepherd write-up, but https://tools.ietf.org/html/ rfc7322#section-4.7 > says > > > > A Table of Contents (TOC) is required in all RFCs. It must be > > positioned after the Copyright Notice and before the Introduction. > > > > It's probably a good thing to use the organization from RFC 7322, just > to sidestep reviewers who start out complaining about document structure > nits and then keep on typing. Not that I ever did that in six years as a > Gen-ART reviwer, of course :-) ... > > > > I probably lack imagination, but perhaps other readers will, also. > > > > In this text > > > > DELTATLR =3D Send time packet 2 - Receive time packet 1 > > > > and > > > > Delta Time Last Sent =3D Receive time packet 2 - Send time packet 1 > > > > these are mathematical expressions, aren't they? If so, that would > likely be clearer if the right side terms had parentheses around the > expression. > > > > (It's a bit odd that the first expression uses the abbreviation DELTATL= R > and the second term is spelled out as "Delta Time Last Sent" - you might > think about which seems clearer, and do that with both expressions) > > > > In text like this > > > > We propose a base unit for the time. > > > > you probably want to use a verb like "specify" (when the draft is > published as an RFC, it will no longer be a proposal). There are multiple > occurrences of "propose" in the document, so this comment applies in > multiple places. > > > > For this text > > > > Assume that two packets are sent for each ACK from the server. > > > > you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. > > > > In this text from 6.3 PDM Flow - Multiple Send with Errors > > > > One might wonder if all of the functions of PDM might be better > > suited to TCP or a TCP option. > > > > that's an interesting point in the broader sense, because (duh) putting > PDM in a TCP option doesn't help you with any other transport protocol > (SCTP, QUIC, what else are we doing these days? and, of course, they're a= ll > running over UDP anyway). I wonder if that's worth pointing out earlier i= n > the document, perhaps in Section 1.4? > > > > This text > > > > Let's say that packet 4 STILL does not make it. > > > > is probably too breezy to translate well into other languages. Perhaps > "is also lost"? (Yes, I talk like this, too) > > > > In the Security Considerations section, you might want to say something > about (1) what watching the unencrypted PDM values might tell attackers > that are doing pervasive monitoring (RFC 7258), and possibly about (2) wh= at > happens if PDM is used as a covert channel. I don't think either of these > will be showstoppers at SECDIR review time, but I'd expect that > demonstrating awareness of at least (1) will shorten the review comments > cycle. Possibly a lot, judging by recent ballots on other drafts ... > > > > > > --001a11c16e6009f9eb053c79c04c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Nalini,

On Wed, Sep 14, 2016 at 9:46 AM, <nalini.elkin= s@insidethestack.com> wrote:
Spencer,



>Pleas= e let me know if you'd like to make that change before Last Call.
=

>(My experience as a Gen-ART reviewer= is that once reviewers find one issue, they come up with more, so not givi= ng them one to start with that you already know about is a good thing. But = >your mileage may differ, of course)

Cha= nges made.=C2=A0 New version at:

I checked the diff (and it was what I expected), and requested= Last Call.
=C2=A0
<= div>
Thank you for your guidance.
=
Oh, thank you :-)

Spencer
= =C2=A0

Nalini

=C2=A0

<= /span>
Nalini
=C2=A0
From: MORTON, ALFRED C (AL)
Sent: Tuesday, September 13, 2016 10:08 PM
= To: Spencer Dawkins at IETF; Nalini Elkins
Cc:<= /b> MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@tools.ietf.org
Subject: RE: AD review of draft-ietf-ippm-6man-pdm- o= ption-03
=C2=A0
I=E2=80=99ll check first thing tomorrow,
thanks!
Al
=C2=A0
From: Spe= ncer Dawkins at IETF [mailto:spencerdawkins.ietf@ g= mail.com]
Sent: Tuesday, September 13, 2016 7= :54 PM
To: Nalini Elkins
Cc:<= /b> MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@tools.ietf.org
Subject: Re: AD review of draft-ietf-ippm-6man-pdm- o= ption-03
=C2=A0
Nalini,
On Sep 13, 2016 18:04, <nalini.elkins@insidethestack. com> wrote:
>
> Spencer,
>
> We have (we believe!) addressed your comments as well as those fro= m Al Morton as document shepherd.
>
= > The new version is at:
>
> <= a rel=3D"nofollow" shape=3D"rect" href=3D"https://tools.ietf.org/html/draft= -ietf-ippm-6man-pdm-option-04" target=3D"_blank">https://tools.ietf.org/htm= l/ draft-ietf-ippm-6man-pdm- option-04
>
> We have added quite a bit to the Security Considerations.=C2= =A0 We have started implementation of PDM in the FreeBSD kernel, as I might= have mentioned before.=C2=A0 =C2=A0It has shed quite a bit of light on the= potential hazards which may come up as far as DOS attacks, etc.=C2=A0 =C2= =A0That was helpful to us in doing the Security Considerations.
>
> Many thanks to both you and Al Morton fo= r your help and comments.
I'm happy. Al, is this version read= y for IETF Last Call?
Thanks,
Spencer
> - Nalini Elkins - on behalf of the PDM co= -authors (Mike Ackermann and Rob Hamilton)
> Inside Pr= oducts, Inc.
> www.insidethestack.co= m
> (831) 659-8= 360
>
>
>= ;
> ______________________________ __
> From: Spencer Dawkins at IETF <spencerdaw= kins.ietf@gmail.com >
> To: draft-ietf-ippm-6man-pdm- option@tools.ietf.org> Cc: ippm@ietf.org
> = Sent: Monday, August 22, 2016 5:37 PM
> Subject: AD re= view of draft-ietf-ippm-6man-pdm- option-03
>
>
>
> Dear Authors,<= br clear=3D"none">>
> Nice work, and this would hav= e been very valuable when I was implementing performance monitors at Tektro= nix, so I imagine it's equally valuable now.
>
> I do have some comments that I'd like you let you c= onsider before I request IETF Last Call for this draft. Please let me know = if you have any questions, of course.
>
> Thanks,
>
> Spencer
>
> I saw the abstract fo= llowing the table of contents mentioned in the shepherd write-up, but https://tools.ietf.org/html/ rfc7322#section-= 4.7 says
>
>= =C2=A0 =C2=A0A Table of Contents (TOC) is required in all RFCs.=C2=A0 It m= ust be
> =C2=A0 =C2=A0positioned after the Copyright N= otice and before the Introduction.
>
> It's probably a good thing to use the organization from RFC 7322,= just to sidestep reviewers who start out complaining about document struct= ure nits and then keep on typing. Not that I ever did that in six years as = a Gen-ART reviwer, of course :-) ...
>
> I probably lack imagination, but perhaps other readers will, also.<= br clear=3D"none">>
> In this text
>
> =C2=A0 =C2=A0DELTATLR =3D Send time packet 2 = - Receive time packet 1
>
> and>
> =C2=A0 =C2=A0Delta Time Last S= ent =3D Receive time packet 2 - Send time packet 1
>> these are mathematical expressions, aren't they? = If so, that would likely be clearer if the right side terms had parentheses= around the expression.
>
> (It&#= 39;s a bit odd that the first expression uses the abbreviation DELTATLR and= the second term is spelled out as "Delta Time Last Sent" - you m= ight think about which seems clearer, and do that with both expressions)>
> In text like this
>
> =C2=A0 =C2=A0We propose a base unit for th= e time.
>
> you probably want to = use a verb like "specify" (when the draft is published as an RFC,= it will no longer be a proposal). There are multiple occurrences of "= propose" in the document, so this comment applies in multiple places.<= br clear=3D"none">>
> For this text
>
> =C2=A0 =C2=A0Assume that two packets are sen= t for each ACK from the server.
>
&g= t; you might point out that TCP does this, per RFC 1122 Section 4.2.3.2.>
> In this text from 6.3 PDM Flow = - Multiple Send with Errors
>
> = =C2=A0 =C2=A0One might wonder if all of the functions of PDM might be bette= r
> =C2=A0 =C2=A0suited to TCP or a TCP option.
>
> that's an interesting point in = the broader sense, because (duh) putting PDM in a TCP option doesn't he= lp you with any other transport protocol (SCTP, QUIC, what else are we doin= g these days? and, of course, they're all running over UDP anyway). I w= onder if that's worth pointing out earlier in the document, perhaps in = Section 1.4?
>
> This text
>
> =C2=A0 =C2=A0Let's say that pac= ket 4 STILL does not make it.
>
>= is probably too breezy to translate well into other languages. Perhaps &qu= ot;is also lost"? (Yes, I talk like this, too)
><= br clear=3D"none">> In the Security Considerations section, you might wa= nt to say something about (1) what watching the unencrypted PDM values migh= t tell attackers that are doing pervasive monitoring (RFC 7258), and possib= ly about (2) what happens if PDM is used as a covert channel. I don't t= hink either of these will be showstoppers at SECDIR review time, but I'= d expect that demonstrating awareness of at least (1) will shorten the revi= ew comments cycle. Possibly a lot, judging by recent ballots on other draft= s ...






--001a11c16e6009f9eb053c79c04c-- From nobody Wed Sep 14 09:13:27 2016 Return-Path: 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 E157212B335 for ; Wed, 14 Sep 2016 09:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 YsIS-aYE4Q_6 for ; Wed, 14 Sep 2016 09:13:22 -0700 (PDT) Received: from nm11-vm5.bullet.mail.ne1.yahoo.com (nm11-vm5.bullet.mail.ne1.yahoo.com [98.138.91.233]) (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 67C1412B311 for ; Wed, 14 Sep 2016 08:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1473868791; bh=+5B844q/WR7s4Tcq7aaH9+yLYV6mK6NCmehoZBvLBGM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=CE46GQDokU38FCzsh8fpIFW8rYdm6mQuaf/Q0DSnaBYntkXLRI9d7EmaxAqQv60VPLsQA2w9bZPY0tE3UAbwymhx7DbOjK4KRtFKeCZiFcpawFxm79noRwmHtJWoB9nPsCqFtJpE4/iW+92fE0ZDZcDeagkOJRcuQndNRfCCSPJc9hVgx0WFgKIrdDFGUqtiaRr1YfLgXycBU21OLOizag7lj+s9m/EB58tyICKkEzZ7SJpOgbmIsv8BMkkCPml4FoOSNxvFo5zlYZl+Aqs+qAIHnU0pDOiQtN0vjuAdXryWe5Yajpghml4bPfS0HV9cnoOGpmm2S32Fd9nFlVLyyg== Received: from [98.138.226.179] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 15:59:51 -0000 Received: from [98.138.226.167] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 15:58:51 -0000 Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 14 Sep 2016 15:58:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 814991.44280.bm@omp1068.mail.ne1.yahoo.com X-YMail-OSG: B5onVWUVM1mnV5Eml.NIZiC9aU9oyFwS9pOTlTw9MuOs1aurJitAFstY93AdYdQ GHNtc8XzNUH.qPxBXwuVyqKmCc1K9JSv0xTIV_6QK_IlbJsvMawN0RPIKx8FqSRBEoSJbKReMK5H 85bTmm.xXxQu6h7S3ILHymNyyrVetTm9fBAoDa0P6H3BUxiwYsHat3eIG1GJgUnF2KDoHBLkE4BJ .b00hDqjQpIoCQmDze9lg47biA5alqi9TTO1Wo4LPFGlET8r4yWTDV3LxHlU0_C0woDHnxTgulaD 26bsWsfJGlMg.tiWq2ftzzQSnRZhv8H_1mHI9Zv285b6xaMDNQ5sT0JpGDnAx6t8csPi_vlmdfV2 e3YRDLbeHlvmHBd36469Q_LgWbn6p8I2YnHINqaqdd0.QVygLt7arBxyZQ1oRFT5YRvsA7sD7jbT ViZom9b6okky9WMWPBl.blqRnxHzsoiHYhNx78K2eqBZ5IVftKAnFbyM.zMcrl2FrQao6X6oLRY6 aHKX5_syeRLWvaJGaygAhZY0ij46ZYvcbMv0NRnZN6mAv9M2G1Z9DabdtgTocbhHLbIj_64Vw3ql4 Received: from jws100234.mail.ne1.yahoo.com by sendmailws163.mail.ne1.yahoo.com; Wed, 14 Sep 2016 15:58:51 +0000; 1473868731.393 Date: Wed, 14 Sep 2016 15:58:49 +0000 (UTC) From: To: Spencer Dawkins at IETF Message-ID: <696803123.1031265.1473868729656@mail.yahoo.com> In-Reply-To: References: <881483676.498721.1473807890669@mail.yahoo.com> <4AF73AA205019A4C8A1DDD32C034631D4598DC73CF@NJFPSRVEXG0.research.att.com> <4AF73AA205019A4C8A1DDD32C034631D459F65BD0A@NJFPSRVEXG0.research.att.com> <1384062451.908563.1473859179499@mail.yahoo.com> <316291956.967191.1473864368299@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1031264_821596690.1473868729632" Archived-At: Cc: "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" , "MORTON, ALFRED C \(AL\)" , "ippm@ietf.org" Subject: Re: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 16:13:25 -0000 ------=_Part_1031264_821596690.1473868729632 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Spencer, Wonderful! See you soon in Seoul.=C2=A0Thanks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 From: Spencer Dawkins at IETF To: Nalini Elkins =20 Cc: "MORTON, ALFRED C (AL)" ; "ippm@ietf.org" ; "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" Sent: Wednesday, September 14, 2016 8:54 AM Subject: Re: AD review of draft-ietf-ippm-6man-pdm-option-03 =20 Hi, Nalini, On Wed, Sep 14, 2016 at 9:46 AM, wrote: Spencer, >Please let me know if you'd like to make that change before Last Call. >(My experience as a Gen-ART reviewer is that once reviewers find one issue= , they come up with more, so not giving them one to start with that you alr= eady know about is a good thing. But >your mileage may differ, of course) Changes made.=C2=A0 New version at: https://tools.ietf.org/html/ draft-ietf-ippm-6man-pdm- option-05 I checked the diff (and it was what I expected), and requested Last Call.= =C2=A0 Thank you for your guidance. Oh, thank you :-) Spencer=C2=A0 Nalini =C2=A0 Nalini=C2=A0From: MORTON, ALFRED C (AL)=20 Sent: Tuesday, September 13, 2016 10:08 PM To: Spencer Dawkins at IETF; Nalini Elkins Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@= tools.ietf.org Subject: RE: AD review of draft-ietf-ippm-6man-pdm- option-03 =C2=A0I=E2=80= =99ll check first thing tomorrow,thanks!Al =C2=A0From: Spencer Dawkins at I= ETF [mailto:spencerdawkins.ietf@ gmail.com]=20 Sent: Tuesday, September 13, 2016 7:54 PM To: Nalini Elkins Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ietf-ippm-6man-pdm- option@= tools.ietf.org Subject: Re: AD review of draft-ietf-ippm-6man-pdm- option-03 =C2=A0Nalini,= On Sep 13, 2016 18:04, wrote: > > Spencer, > > We have (we believe!) addressed your comments as well as those from Al Mo= rton as document shepherd. > > The new version is at: > > https://tools.ietf.org/html/ draft-ietf-ippm-6man-pdm- option-04 > > We have added quite a bit to the Security Considerations.=C2=A0 We have s= tarted implementation of PDM in the FreeBSD kernel, as I might have mention= ed before.=C2=A0 =C2=A0It has shed quite a bit of light on the potential ha= zards which may come up as far as DOS attacks, etc.=C2=A0 =C2=A0That was he= lpful to us in doing the Security Considerations. > > Many thanks to both you and Al Morton for your help and comments.I'm happ= y. Al, is this version ready for IETF Last Call?Thanks, Spencer> - Nalini E= lkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Hamilton) > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > > > ______________________________ __ > From: Spencer Dawkins at IETF > To: draft-ietf-ippm-6man-pdm- option@tools.ietf.org > Cc: ippm@ietf.org > Sent: Monday, August 22, 2016 5:37 PM > Subject: AD review of draft-ietf-ippm-6man-pdm- option-03 > > > > Dear Authors, > > Nice work, and this would have been very valuable when I was implementing= performance monitors at Tektronix, so I imagine it's equally valuable now. > > I do have some comments that I'd like you let you consider before I reque= st IETF Last Call for this draft. Please let me know if you have any questi= ons, of course. > > Thanks, > > Spencer > > I saw the abstract following the table of contents mentioned in the sheph= erd write-up, but https://tools.ietf.org/html/ rfc7322#section-4.7 says > > =C2=A0 =C2=A0A Table of Contents (TOC) is required in all RFCs.=C2=A0 It = must be > =C2=A0 =C2=A0positioned after the Copyright Notice and before the Introdu= ction. > > It's probably a good thing to use the organization from RFC 7322, just to= sidestep reviewers who start out complaining about document structure nits= and then keep on typing. Not that I ever did that in six years as a Gen-AR= T reviwer, of course :-) ... > > I probably lack imagination, but perhaps other readers will, also. > > In this text > > =C2=A0 =C2=A0DELTATLR =3D Send time packet 2 - Receive time packet 1 > > and > > =C2=A0 =C2=A0Delta Time Last Sent =3D Receive time packet 2 - Send time p= acket 1 > > these are mathematical expressions, aren't they? If so, that would likely= be clearer if the right side terms had parentheses around the expression. > > (It's a bit odd that the first expression uses the abbreviation DELTATLR = and the second term is spelled out as "Delta Time Last Sent" - you might th= ink about which seems clearer, and do that with both expressions) > > In text like this > > =C2=A0 =C2=A0We propose a base unit for the time. > > you probably want to use a verb like "specify" (when the draft is publish= ed as an RFC, it will no longer be a proposal). There are multiple occurren= ces of "propose" in the document, so this comment applies in multiple place= s. > > For this text > > =C2=A0 =C2=A0Assume that two packets are sent for each ACK from the serve= r. > > you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. > > In this text from 6.3 PDM Flow - Multiple Send with Errors > > =C2=A0 =C2=A0One might wonder if all of the functions of PDM might be bet= ter > =C2=A0 =C2=A0suited to TCP or a TCP option. > > that's an interesting point in the broader sense, because (duh) putting P= DM in a TCP option doesn't help you with any other transport protocol (SCTP= , QUIC, what else are we doing these days? and, of course, they're all runn= ing over UDP anyway). I wonder if that's worth pointing out earlier in the = document, perhaps in Section 1.4? > > This text > > =C2=A0 =C2=A0Let's say that packet 4 STILL does not make it. > > is probably too breezy to translate well into other languages. Perhaps "i= s also lost"? (Yes, I talk like this, too) > > In the Security Considerations section, you might want to say something a= bout (1) what watching the unencrypted PDM values might tell attackers that= are doing pervasive monitoring (RFC 7258), and possibly about (2) what hap= pens if PDM is used as a covert channel. I don't think either of these will= be showstoppers at SECDIR review time, but I'd expect that demonstrating a= wareness of at least (1) will shorten the review comments cycle. Possibly a= lot, judging by recent ballots on other drafts ... =20 =20 =20 ------=_Part_1031264_821596690.1473868729632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Spencer,

Wonderful!

See you soon in Seoul.<= /div>
 
Than= ks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360


From: Spencer Dawkins at IETF <spencerdawkin= s.ietf@gmail.com>
To: Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: "MORTON, ALFRED C (AL)" <acmorto= n@att.com>; "ippm@ietf.org" <ippm@ietf.org>; "draft-ietf-ippm-6man= -pdm-option@tools.ietf.org" <draft-ietf-ippm-6man-pdm-option@tools.ietf.= org>
Sent: Wednesda= y, September 14, 2016 8:54 AM
Sub= ject: Re: AD review of draft-ietf-ippm-6man-pdm-option-03

Hi, Nalini,

On Wed, Sep 14, 2016 at 9:46 AM, <nalini.e= lkins@insidethestack.com> wrote:
S= pencer,



>Please let me know if you'd like to make that chan= ge before Last Call.

>(My experi= ence as a Gen-ART reviewer is that once reviewers find one issue, they come= up with more, so not giving them one to start with that you already know a= bout is a good thing. But >your mileage may differ, of course)

Changes made.  New version at:


I checked the diff (and it= was what I expected), and requested Last Call.
 
Thank you for your guidance.

Oh, thank you :-)

Spencer
 

Nalini
 

Nalini
 
From: MORTON, ALFRED C (AL)
Sent: Tuesday, September 13, 2016 10:08 PM
= To: Spencer Dawkins at IETF; Nalini Elkins
Cc:<= /b> MORTON, ALFRED C (AL); ippm@ie= tf.org; draft-ietf-ippm-6man-pdm- optio= n@tools.ietf.org
Subject: RE: AD review of dra= ft-ietf-ippm-6man-pdm- option-03
 
=
I=E2=80=99ll check first thing tomor= row,
thanks!
Al
 
From: Spencer Dawkins at IETF [mailto:s= pencerdawkins.ietf@ gmail.com]
Sent: Tuesday,= September 13, 2016 7:54 PM
To: Nalini Elkins
Cc: MORTON, ALFRED C (AL); ippm@ietf.org; draft-ie= tf-ippm-6man-pdm- option@tools.ietf.org
Subject: Re: AD review of draft-ietf-ippm-6man-pdm- option-03
<= /div>
 
Nalini,
On Sep 13, 2016 18:04, <nalini.elkins@insidethestack. com> wrote:
>
> Spencer,
>
> We have (we believe!) addressed your= comments as well as those from Al Morton as document shepherd.
>
> The new version is at:
>
> https://tools.ietf.org/html/ draft-ietf-ippm-6man-pdm- option-04>
> We have added quite a bit to th= e Security Considerations.  We have started implementation of PDM in t= he FreeBSD kernel, as I might have mentioned before.   It has she= d quite a bit of light on the potential hazards which may come up as far as= DOS attacks, etc.   That was helpful to us in doing the Security= Considerations.
>
> Many thanks = to both you and Al Morton for your help and comments.
I'm happy. = Al, is this version ready for IETF Last Call?
Thanks,
= Spencer
> - Na= lini Elkins - on behalf of the PDM co-authors (Mike Ackermann and Rob Hamil= ton)
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
&g= t;
>
>
> ___= ___________________________ __
> From: Spencer Dawkins= at IETF <spencerdawkins.ietf@gmail.com >
> To= : draft-ietf-ippm-6man-pdm- option@tools.ie= tf.org
> Cc: ippm@ietf.org
> Sent: Monday, August 22, 2016 = 5:37 PM
> Subject: AD review of draft-ietf-ippm-6man-p= dm- option-03
>
>
>
> Dear Authors,
>
> Nice work, and this would have been very valuable when I wa= s implementing performance monitors at Tektronix, so I imagine it's equally= valuable now.
>
> I do have some= comments that I'd like you let you consider before I request IETF Last Cal= l for this draft. Please let me know if you have any questions, of course.<= br clear=3D"none">>
> Thanks,
>= ;
> Spencer
>
<= /div>
> I saw the abstract following the table of contents mentione= d in the shepherd write-up, but https:= //tools.ietf.org/html/ rfc7322#section-4.7 says
>
>    A Table o= f Contents (TOC) is required in all RFCs.  It must be
>    positioned after the Copyright Notice and before the In= troduction.
>
> It's probably a g= ood thing to use the organization from RFC 7322, just to sidestep reviewers= who start out complaining about document structure nits and then keep on t= yping. Not that I ever did that in six years as a Gen-ART reviwer, of cours= e :-) ...
>
> I probably lack ima= gination, but perhaps other readers will, also.
>
> In this text
>
&g= t;    DELTATLR =3D Send time packet 2 - Receive time packet 1
>
> and
>
>    Delta Time Last Sent =3D Receive time packet= 2 - Send time packet 1
>
> these= are mathematical expressions, aren't they? If so, that would likely be cle= arer if the right side terms had parentheses around the expression.
>
> (It's a bit odd that the first expre= ssion uses the abbreviation DELTATLR and the second term is spelled out as = "Delta Time Last Sent" - you might think about which seems clearer, and do = that with both expressions)
>
> I= n text like this
>
>    = ;We propose a base unit for the time.
>
> you probably want to use a verb like "specify" (when the draft is = published as an RFC, it will no longer be a proposal). There are multiple o= ccurrences of "propose" in the document, so this comment applies in multipl= e places.
>
> For this text
>
>    Assume that two packe= ts are sent for each ACK from the server.
>
> you might point out that TCP does this, per RFC 1122 Section= 4.2.3.2.
>
> In this text from 6= .3 PDM Flow - Multiple Send with Errors
>
>    One might wonder if all of the functions of PDM mig= ht be better
>    suited to TCP or a TCP opt= ion.
>
> that's an interesting po= int in the broader sense, because (duh) putting PDM in a TCP option doesn't= help you with any other transport protocol (SCTP, QUIC, what else are we d= oing these days? and, of course, they're all running over UDP anyway). I wo= nder if that's worth pointing out earlier in the document, perhaps in Secti= on 1.4?
>
> This text
>
>    Let's say that packet 4 STI= LL does not make it.
>
> is proba= bly too breezy to translate well into other languages. Perhaps "is also los= t"? (Yes, I talk like this, too)
>
&= gt; In the Security Considerations section, you might want to say something= about (1) what watching the unencrypted PDM values might tell attackers th= at are doing pervasive monitoring (RFC 7258), and possibly about (2) what h= appens if PDM is used as a covert channel. I don't think either of these wi= ll be showstoppers at SECDIR review time, but I'd expect that demonstrating= awareness of at least (1) will shorten the review comments cycle. Possibly= a lot, judging by recent ballots on other drafts ...








------=_Part_1031264_821596690.1473868729632-- From nobody Wed Sep 14 11:53:32 2016 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A012B453; Wed, 14 Sep 2016 11:53:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147387920600.19686.14698855205891210842.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 11:53:26 -0700 Archived-At: Cc: ippm-chairs@ietf.org, Al Morton , ippm@ietf.org, Bill Cerveny , draft-ietf-ippm-6man-pdm-option@ietf.org Subject: [ippm] Last Call: (IPv6 Performance and Diagnostic Metrics (PDM) Destination Option) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 18:53:26 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'IPv6 Performance and Diagnostic Metrics (PDM) Destination Option' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-09-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2815/ From nobody Fri Sep 23 08:07:44 2016 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0312C084; Fri, 23 Sep 2016 08:07:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147464325946.376.14645717902224176920.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2016 08:07:39 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 15:07:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-06.txt Pages : 30 Date : 2016-09-23 Abstract: To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 23 08:07:51 2016 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 844D112C08F; Fri, 23 Sep 2016 08:07:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147464325953.368.7010913826359408541.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2016 08:07:39 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 15:07:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-06.txt Pages : 30 Date : 2016-09-23 Abstract: To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 26 09:22:56 2016 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02BB12B305; Mon, 26 Sep 2016 09:22:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147490697367.5049.8239954548815230841.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2016 09:22:53 -0700 Archived-At: Cc: ippm-chairs@ietf.org, ippm@ietf.org Subject: [ippm] ippm - New Meeting Session Request for IETF 97 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 16:22:54 -0000 A new meeting session request has just been submitted by Brian Trammell, a Chair of the ippm working group. --------------------------------------------------------- Working Group Name: IP Performance Metrics Area Name: Transport Area Session Requester: Brian Trammell Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm taps bmwg lmap xrblock quic Second Priority: v6ops 6man 6lo sunset4 opsec tcpinc Third Priority: cdni alto rmcat Special Requests: Please try not to schedule opposite irtfopen, iccrg, maprg --------------------------------------------------------- From nobody Tue Sep 27 00:35:08 2016 Return-Path: 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 77B8912B379 for ; Tue, 27 Sep 2016 00:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4CNydwgihSeV for ; Tue, 27 Sep 2016 00:35:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F4112B3A8 for ; Tue, 27 Sep 2016 00:35:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRZ02011; Tue, 27 Sep 2016 07:34:59 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 27 Sep 2016 08:34:53 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.199]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 27 Sep 2016 15:34:46 +0800 From: Qin Wu To: IETF IPPM WG Thread-Topic: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt Thread-Index: AQHR2GOkS1kzwnBKcEyj2tK2HIdYDqCD840AgAl5YyA= Date: Tue, 27 Sep 2016 07:34:46 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.112] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57EA2125.019E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 20e57eea6c649536a149924ac939a310 Archived-At: Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 07:35:07 -0000 Hi, Giuseppe: I have taken a pass on this document and have the following comments and su= ggestions: Minor issues: 1. Introduction, paragraph 4 said: " It doesn't require any protocol extension or interaction with existing protocols, thus avoiding any interoperability issue. Even if the method doesn't raise any specific need for standardization, it could be further improved by means of some extension to existing protocols, but this aspect is left for further study and it is out of the scope of this document. " Do we really need this paragraph, it confuses me a lot. in the first senten= ce, it said protocol extension is not needed, in the second sentence, it s= aid extension to existing protocol can be used to improve this method, thes= e two sentences are not consistent, in addition, it said this method doesn'= t need to be standardized in some case, I am wondering if it doesn't need t= o be standardized, why produce this document? Suggest to remove these two sentences. 2.Introduction, paragraph 5 said: " The method described in this document, also called PNPM (Packet Network Performance Monitoring), has been invented and engineered in Telecom Italia and it's currently being used in Telecom Italia's network. " I can see this method has been implemented in TI network, but it doesn't ne= ed to be emphasized in the introduction and abstract, It make people to fee= l this spec is TI specific standard, :-),which is not true. I would suggest to remove this statement from spec or move them to implemen= tation report section. 3.Introduction, paragraph 5 said: " The previous IETF drafts about this technique were: [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. There are some references to this methodology in other IETF works (e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation], [I-D.mirsky-bier-pmmm-oam] [I-D.chen-ippm-coloring-based-ipfpm-framework]). " It doesn't need to emphasize the history of this document, I would suggest = to create acknowledgement section, move text there. 4. Section 3.1 What is clock error? How this is related to wait L/2 time units after color switching based on f= ixed timer? In this document, it introduce two color switching method, one is based on = fixed number of packet, the other is based on fixed timer, I am wondering w= hether clock error is only applied to color switching based on fixed timer,= or applied to both? 5.Section 3.2.3, paragraph 1 Why the second marking is needed? Why we can not calculate minimum and maxi= mum delay based on single marking methodology? 6. Section 3.2.3, paragraph 2 said: " Basically, the idea is to use the first marking to create the alternate flow and, within this colored flow, a second marking to select the packets for measuring delay/jitter . " Is second marking and first marking applied to the same colored flow? Can y= ou give an example to explain what double marking looks like? Why measure jitter is needed in the one way delay measurement? 7. Section 3.3 Can you detail on how delay variation is calculated in this case? 8.Section 4.1, paragraph 1 Not sure packet loss measurement requires synchronization between two netwo= rk devices? 9.Section 4.1, paragraph 3 said: " The synchronization requirement can be satisfied even with a relatively inaccurate synchronization method. " Give you give an example of inaccurate sync method? This sentence needs to = be expanded to add more details. 10. Section 4.2 Why Data correlation is required in this method? It will be great to see so= me justification text at the beginning of this section before touching data= correlation details. 11.Section 5 Not sure implementation and deployment is part of this spec, either move th= em to appendix or removed it from this spec. 12. Section 6 paragraph 1 said: " The method has been explicitly designed for passive measurements but it can also be used with active measurements . " This section seems not discuss how method is used in the active measurement= ? Why active measurement should use this method? 13. Section 6 paragraph 1 said: " In order to have both end to end measurements and intermediate measurements (hybrid measurements ) two end points can exchanges artificial traffic flows and apply alternate marking over these flows. In the intermediate points artificial traffic is managed in the same way as real traffic and measured as specified before. " Is hybrid measurement about combination of passive measurement and active m= easurement or combination of end to end measurement and intermediate measur= ement? Editorial issues and Nits 1. Section 1, 3rd paragraph: OLD TEXT: " A lot of work related to OAM, that includes also performance monitoring techniques, has been done by Standards Developing Organizations: " NEW TEXT: " A lot of work related to OAM, that includes also performance monitoring techniques, has been done by Standards Developing Organizations(SDOs): " 2.Section 1, 3rd paragraph OLD TEXT: " The IPPM WG has defined standard metrics to measure network performance; however, the methods developed in the WG mainly refer to refer to active measurement techniques. " NEW TEXT: " The IPPM WG has defined standard metrics to measure network performance; however, the methods developed in this WG mainly refer to focus on active measurement techniques. " 3.Section 4.2 and 4.3 2nd paragraph OLD TEXT: " In the following paragraphs an example data correlation mechanism is explained and could be use independently of the adopted solutions. " NEW TEXT: " In the following paragraphs an example of data correlation mechanism is explained and could be use independently of the adopted solutions. " 4.Section 9 OLD TEXT: " The method doesn't raise any specific need for standardization, but it could be further improved by means of some extension to existing protocols. " NEW TEXT: " The method doesn't raise any specific need for protocol extension, but it could be further improved by means of some extension to existing protocols. " -Qin -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Fioccola Giuseppe Inviato: gioved=EC 7 luglio 2016 17:24 A: ippm@ietf.org; ippm-chairs@tools.ietf.org Oggetto: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt Hi All, This new version of draft-ietf-ippm-alt-mark includes part of the contents = of draft-chen-ippm-coloring-based-ipfpm-framework. The authors have merged some Sections regarding Re-ordering Tolerance, Sync= hronization Aspects, Security Considerations and other general concepts. Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet-drafts@ietf.o= rg Inviato: gioved=EC 7 luglio 2016 16:33 A: i-d-announce@ietf.org Cc: ippm@ietf.org Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics of the IETF. Title : Alternate Marking method for passive performance = monitoring Authors : Giuseppe Fioccola Alessandro Capello Mauro Cociglio Luca Castaldelli Mach(Guoyi) Chen Lianshu Zheng Greg Mirsky Tal Mizrahi Filename : draft-ietf-ippm-alt-mark-01.txt Pages : 29 Date : 2016-07-07 Abstract: This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-alt-mark-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Sep 28 10:59:26 2016 Return-Path: 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 CAF9312B436 for ; Wed, 28 Sep 2016 10:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 t1e3aCd55v_H for ; Wed, 28 Sep 2016 10:59:20 -0700 (PDT) Received: from TELEDG001RM001.telecomitalia.it (teledg001rm001.telecomitalia.it [217.169.121.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C87212B62E for ; Wed, 28 Sep 2016 10:59:19 -0700 (PDT) Received: from TELMBXA02RM001.telecomitalia.local (10.14.252.26) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 28 Sep 2016 19:59:16 +0200 Received: from TELMBXB02RM001.telecomitalia.local (10.14.252.27) by TELMBXA02RM001.telecomitalia.local (10.14.252.26) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 28 Sep 2016 19:59:16 +0200 Received: from TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844]) by TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844%20]) with mapi id 15.00.1178.000; Wed, 28 Sep 2016 19:59:16 +0200 From: Fioccola Giuseppe To: Qin Wu , IETF IPPM WG Thread-Topic: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt Thread-Index: AQHR2GOkPiEM6SRp0UufJeNX6xaZdqCD840AgAl5YyCAABSx8A== Date: Wed, 28 Sep 2016 17:59:16 +0000 Message-ID: <8fa05f8408a349918235fd9658b162b4@TELMBXB02RM001.telecomitalia.local> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.254] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_8fa05f8408a349918235fd9658b162b4TELMBXB02RM001telecomit_" MIME-Version: 1.0 Archived-At: Subject: [ippm] R: I: I-D Action: draft-ietf-ippm-alt-mark-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 17:59:25 -0000 --_000_8fa05f8408a349918235fd9658b162b4TELMBXB02RM001telecomit_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Qin, Thanks for your detailed reviews and valuable suggestions. I will address your comments in the next version of the draft. Please see my answers inline. Best Regards, Giuseppe -----Messaggio originale----- Da: Qin Wu [mailto:bill.wu@huawei.com] Inviato: marted=EC 27 settembre 2016 09:35 A: IETF IPPM WG Cc: Fioccola Giuseppe Oggetto: RE: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt Hi, Giuseppe: I have taken a pass on this document and have the following comments and su= ggestions: Minor issues: 1. Introduction, paragraph 4 said: " It doesn't require any protocol extension or interaction with existing protocols, thus avoiding any interoperability issue. Even if the method doesn't raise any specific need for standardization, it could be further improved by means of some extension to existing protocols, but this aspect is left for further study and it is out of the scope of this document. " Do we really need this paragraph, it confuses me a lot. in the first senten= ce, it said protocol extension is not needed, in the second sentence, it s= aid extension to existing protocol can be used to improve this method, thes= e two sentences are not consistent, in addition, it said this method doesn'= t need to be standardized in some case, I am wondering if it doesn't need t= o be standardized, why produce this document? Suggest to remove these two sentences. [GF] I fully agree. These sentences are inherited by oldest version of the = draft so are now obsolete. For instance in this version we mention the RFC6= 374 and Overlay OAM use case where a protocol modification is needed. 2.Introduction, paragraph 5 said: " The method described in this document, also called PNPM (Packet Network Performance Monitoring), has been invented and engineered in Telecom Italia and it's currently being used in Telecom Italia's network. " I can see this method has been implemented in TI network, but it doesn't ne= ed to be emphasized in the introduction and abstract, It make people to fee= l this spec is TI specific standard, :-),which is not true. I would suggest to remove this statement from spec or move them to implemen= tation report section. [GF] I agree. I will move it to implementation/report section. 3.Introduction, paragraph 5 said: " The previous IETF drafts about this technique were: [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. There are some references to this methodology in other IETF works (e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation], [I-D.mirsky-bier-pmmm-oam] [I-D.chen-ippm-coloring-based-ipfpm-framework]). " It doesn't need to emphasize the history of this document, I would suggest = to create acknowledgement section, move text there. [GF] I agree. I will move it to acknowledgements section. 4. Section 3.1 What is clock error? How this is related to wait L/2 time units after color switching based on f= ixed timer? In this document, it introduce two color switching method, one is based on = fixed number of packet, the other is based on fixed timer, I am wondering w= hether clock error is only applied to color switching based on fixed timer,= or applied to both? [GF] It is only applied to color switching based on fixed timer. This is pr= eferable to the method based on a fixed number of packets. I agree, we need to explain better this concept. In case we have only clock error between network devices, they must be sync= hronized to the same clock reference with an accuracy of +/- L/2 time units= . In this way, in theory, you are able to recognize the right packet marked= batch along your path. But, in practice, you can have also out of order at batch boundaries, stric= tly related to the maximum delay between measurement points, so, without co= nsidering clock error, we wait L/2 after color switching to be sure to take= a still counter. In summary we have two errors: clock error between network devices and the = interval we need to wait to avoid out of order because of network delay. If= we consider one-by-one these two problems the limit value is L/2. If we consider both issues we should say: -L/2 < (maximum clock error + maximum network delay) < L/2 I want to add this formula in the next version. This will address also the suggestion from Jose Ignacio during Berlin prese= ntation. 5.Section 3.2.3, paragraph 1 Why the second marking is needed? Why we can not calculate minimum and maxi= mum delay based on single marking methodology? [GF] We can do that also with single marking methodology: we store timestam= p of the first or last packet of a batch and that timestamp can be compared= with the timestamp of the same packet along the path. But this option does not work in case of out of order. The option in case o= f single marking, that escapes out of order issue, is average delay. 6. Section 3.2.3, paragraph 2 said: " Basically, the idea is to use the first marking to create the alternate flow and, within this colored flow, a second marking to select the packets for measuring delay/jitter . " Is second marking and first marking applied to the same colored flow? Can y= ou give an example to explain what double marking looks like? Why measure jitter is needed in the one way delay measurement? [GF] Second marking selects some packets dedicated for delay measurement wi= thin first marking. This option works in case of out of order because you c= an always recognize the second marked packets. But between this second marked packets we need a security gap in order to a= void out of order issue between these packets. 7. Section 3.3 Can you detail on how delay variation is calculated in this case? [GF] The calculation of delay variation is similar to the delay. We refer t= o the definition in RFC 3393. But I will explain how to do in the next vers= ion. 8.Section 4.1, paragraph 1 Not sure packet loss measurement requires synchronization between two netwo= rk devices? [GF] The strength of this method is that it needs a synchronization accurac= y of +/- L/2 (without considering network delay), in this way all network d= evices consistently match the color bit to the correct block. 9.Section 4.1, paragraph 3 said: " The synchronization requirement can be satisfied even with a relatively inaccurate synchronization method. " Give you give an example of inaccurate sync method? This sentence needs to = be expanded to add more details. [GF] For instance, if you choose a marking interval of 5minutes, you can ha= ve all network devices 2m and 30s asynchronous (without considering network= delay). 10. Section 4.2 Why Data correlation is required in this method? It will be great to see so= me justification text at the beginning of this section before touching data= correlation details. [GF] We need data correlation to compare counters and timestamps for packet= loss, delay and jitter calculation. I will add some text to explain better= . 11.Section 5 Not sure implementation and deployment is part of this spec, either move th= em to appendix or removed it from this spec. [GF] We could move that to appendix. 12. Section 6 paragraph 1 said: " The method has been explicitly designed for passive measurements but it can also be used with active measurements . " This section seems not discuss how method is used in the active measurement= ? Why active measurement should use this method? [GF] This is explained in draft-fioccola-ippm-alt-mark-active. But the appl= ication of marking method can simplify also the active measurement and can = enable hybrid measurements. 13. Section 6 paragraph 1 said: " In order to have both end to end measurements and intermediate measurements (hybrid measurements ) two end points can exchanges artificial traffic flows and apply alternate marking over these flows. In the intermediate points artificial traffic is managed in the same way as real traffic and measured as specified before. " Is hybrid measurement about combination of passive measurement and active m= easurement or combination of end to end measurement and intermediate measur= ement? [GF] Both Editorial issues and Nits 1. Section 1, 3rd paragraph: OLD TEXT: " A lot of work related to OAM, that includes also performance monitoring techniques, has been done by Standards Developing Organizations: " NEW TEXT: " A lot of work related to OAM, that includes also performance monitoring techniques, has been done by Standards Developing Organizations(SDOs): " 2.Section 1, 3rd paragraph OLD TEXT: " The IPPM WG has defined standard metrics to measure network performance; however, the methods developed in the WG mainly refer to refer to active measurement techniques. " NEW TEXT: " The IPPM WG has defined standard metrics to measure network performance; however, the methods developed in this WG mainly refer to focus on active measurement techniques. " 3.Section 4.2 and 4.3 2nd paragraph OLD TEXT: " In the following paragraphs an example data correlation mechanism is explained and could be use independently of the adopted solutions. " NEW TEXT: " In the following paragraphs an example of data correlation mechanism is explained and could be use independently of the adopted solutions. " 4.Section 9 OLD TEXT: " The method doesn't raise any specific need for standardization, but it could be further improved by means of some extension to existing protocols. " NEW TEXT: " The method doesn't raise any specific need for protocol extension, but it could be further improved by means of some extension to existing protocols. " [GF] Thanks for all editorial changes. -Qin -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Fioccola Giuseppe Inviato: gioved=EC 7 luglio 2016 17:24 A: ippm@ietf.org; ippm-chairs@tools.ietf.org Oggetto: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-01.txt Hi All, This new version of draft-ietf-ippm-alt-mark includes part of the contents = of draft-chen-ippm-coloring-based-ipfpm-framework. The authors have merged some Sections regarding Re-ordering Tolerance, Sync= hronization Aspects, Security Considerations and other general concepts. Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet-drafts@ietf.o= rg Inviato: gioved=EC 7 luglio 2016 16:33 A: i-d-announce@ietf.org Cc: ippm@ietf.org Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics of the IETF. Title : Alternate Marking method for passive performance = monitoring Authors : Giuseppe Fioccola Alessandro Capello Mauro Cociglio Luca Castaldelli Mach(Guoyi) Chen Lianshu Zheng Greg Mirsky Tal Mizrahi Filename : draft-ietf-ippm-alt-mark-01.txt Pages : 29 Date : 2016-07-07 Abstract: This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-alt-mark-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_8fa05f8408a349918235fd9658b162b4TELMBXB02RM001telecomit_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Q= in,

Than= ks for your detailed reviews and valuable suggestions.

I wi= ll address your comments in the next version of the draft.

 

Plea= se see my answers inline.

 

Best Regards,<= /o:p>

 

Giuseppe=

 

-----Messaggio originale-----

Da: Qin Wu [mailto:bill.wu@huawei.com]

Inviato: marted=EC 27 settembre 2016 09:35

A: IETF IPPM WG

Cc: Fioccola Giuseppe

Oggetto: RE: [ippm] I: I-D Action: draft-ietf-ipp= m-alt-mark-01.txt

 

Hi, Giuseppe:

I have taken a pass on this = document and have the following comments and suggestions:=

Minor issues:

1. Introduction, paragraph 4= said:

"

  It doesn't=

   require any pro= tocol extension or interaction with existing

   protocols, thus= avoiding any interoperability issue.  Even if the

   method doesn't = raise any specific need for standardization, it could

   be further impr= oved by means of some extension to existing protocols,

   but this aspect= is left for further study and it is out of the scope

   of this documen= t.

"

Do we really need this parag= raph, it confuses me a lot. in the first sentence, it said  protocol e= xtension is not needed, in the second sentence, it said extension to existi= ng protocol can be used to improve this method, these two sentences are not consistent, in addition, it said this method d= oesn't need to be standardized in some case, I am wondering if it doesn't n= eed to be standardized, why produce this document?

Suggest to remove these two = sentences.

 

[GF]= I fully agree. These sentences are inherited by oldest version of the draf= t so are now obsolete. For instance in this version we mention the RFC6374 = and Overlay OAM use case where a protocol modification is needed.

 

2.Introduction, paragraph 5 = said:

"

   The method desc= ribed in this document, also called PNPM (Packet

   Network Perform= ance Monitoring), has been invented and engineered in

   Telecom Italia = and it's currently being used in Telecom Italia's

   network.

"

I can see this method has be= en implemented in TI network, but it doesn't need to be emphasized in the i= ntroduction and abstract, It make people to feel this spec is TI specific s= tandard, :-),which is not true.

I would suggest to remove th= is statement from spec or move them to implementation report section.<= /o:p>

 

[GF]= I agree. I will move it to implementation/report section.

 

3.Introduction, paragraph 5 = said:

"

The previous IETF drafts abo= ut this technique were:

   [I-D.cociglio-m= boned-multicast-pm] and [I-D.tempia-opsawg-p3m].

   There are some = references to this methodology in other IETF works

   (e.g.  [I-= D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework]<= /p>

   [I-D.bryant-mpl= s-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation],

   [I-D.mirsky-bie= r-pmmm-oam]

   [I-D.chen-ippm-= coloring-based-ipfpm-framework]).

"

It doesn't need to emphasize= the history of this document, I would suggest to create acknowledgement se= ction, move text there.

 

[GF]= I agree. I will move it to acknowledgements section.

 

4. Section 3.1

What is clock error?

How this is related to wait = L/2 time units after color switching based on fixed timer?

In this document, it introdu= ce two color switching method, one is based on fixed number of packet, the = other is based on fixed timer, I am wondering whether clock error is only a= pplied to color switching based on fixed timer, or applied to both?

 

[GF]= It is only applied to color switching based on fixed timer. This is prefer= able to the method based on a fixed number of packets.

I ag= ree, we need to explain better this concept. 

In c= ase we have only clock error between network devices, they must be synchron= ized to the same clock reference with an accuracy of +/- L/2 time units= . In this way, in theory, you are able to recognize the right packet marked batch along your path.

But,= in practice, you can have also out of order at batch boundaries, strictly = related to the maximum delay between measurement points, so, without consid= ering clock error, we wait L/2 after color switching to be sure to take a still counter.

In s= ummary we have two errors: clock error between network devices and the inte= rval we need to wait to avoid out of order because of network delay. If we = consider one-by-one these two problems the limit value is L/2.

If w= e consider both issues we should say:

 

-L/2= < (maximum clock error + maximum network delay) < L/2

 

I wa= nt to add this formula in the next version.

This= will address also the suggestion from Jose Ignacio during Berlin presentat= ion.

 

5.Section 3.2.3, paragraph 1=

Why the second marking is ne= eded? Why we can not calculate minimum and maximum delay based on single ma= rking methodology?

 

[GF]= We can do that also with single marking methodology: we store timestamp of= the first or last packet of a batch and that timestamp can be compared wit= h the timestamp of the same packet along the path.

But = this option does not work in case of out of order. The option in case of si= ngle marking, that escapes out of order issue, is average delay.=

 

6. Section 3.2.3, paragraph = 2 said:

"

Basically, the idea is to us= e the first marking to create the

   alternate flow = and, within this colored flow, a second marking  to<= /p>

   select the pack= ets for measuring delay/jitter .

"

Is second marking and first = marking applied to the same colored flow? Can you give an example to explai= n what double marking looks like?

Why measure jitter is needed= in the one way delay measurement?

 

[GF]= Second marking selects some packets dedicated for delay measurement within= first marking. This option works in case of out of order because you can a= lways recognize the second marked packets.

But = between this second marked packets we need a security gap in order to avoid= out of order issue between these packets.

 

7. Section 3.3

Can you detail on how delay = variation is calculated in this case?

 

[GF]= The calculation of delay variation is similar to the delay. We refer to th= e definition in RFC 3393. But I will explain how to do in the next version.

 

8.Section 4.1, paragraph 1

Not sure packet loss measure= ment requires synchronization between two network devices?

 

[GF]= The strength of this method is that it needs a synchronization accuracy of= +/- L/2 (without considering network delay), in this way all network d= evices consistently match the color bit to the correct block.

 

9.Section 4.1, paragraph 3 s= aid:

"

The synchronization requirem= ent can be satisfied even with a

   relatively inac= curate synchronization method.

"

Give you give an example of = inaccurate sync method? This sentence needs to be expanded to add more deta= ils.

 

[GF]= For instance, if you choose a marking interval of 5minutes, you can have a= ll network devices 2m and 30s asynchronous (without considering network del= ay).

 

10. Section 4.2

Why Data correlation is requ= ired in this method? It will be great to see some justification text at the= beginning of this section before touching data correlation details.

 

[GF]= We need data correlation to compare counters and timestamps for packet los= s, delay and jitter calculation. I will add some text to explain better.

 

11.Section 5

Not sure implementation and = deployment is part of this spec, either move them to appendix or removed it= from this spec.

 

[GF]= We could move that to appendix.

 

12. Section 6 paragraph 1 sa= id:

"

The method has been explicit= ly designed for passive measurements but

   it can also be = used with active measurements .

"

This section seems not discu= ss how method is used in the active measurement? Why active measurement sho= uld use this method?

 

[GF]= This is explained in draft-fioccola-ippm-alt-mark-active. But the applicat= ion of marking method can simplify also the active measurement and can enab= le hybrid measurements.

 

13. Section 6 paragraph 1 sa= id:

"

In order to have both

   end to end meas= urements and intermediate measurements (hybrid

   measurements ) = two end points can exchanges artificial traffic flows

   and apply alter= nate marking over these flows.  In the intermediate<= /p>

   points artifici= al traffic is managed in the same way as real traffic

   and measured as= specified before.

"

Is hybrid measurement about = combination of passive measurement and active measurement or combination of= end to end measurement and intermediate measurement?

 

[GF]= Both

 

Editorial issues and Nits

1. Section 1, 3rd paragraph:=

OLD TEXT:<= /p>

"

A lot of work related to OAM= , that includes also performance

   monitoring tech= niques, has been done by Standards Developing

   Organizations:<= o:p>

"

NEW TEXT:<= /p>

"

A lot of work related to OAM= , that includes also performance

   monitoring tech= niques, has been done by Standards Developing

   Organizations(S= DOs):

"

2.Section 1, 3rd paragraph

OLD TEXT:<= /p>

"

The IPPM WG has defined stan= dard metrics to

   measure network= performance; however, the methods developed in the WG

   mainly refer to= refer to active measurement techniques.

"

NEW TEXT:<= /p>

"

The IPPM WG has defined stan= dard metrics to

   measure network= performance; however, the methods developed in this WG

   mainly refer to= focus on active measurement techniques.

"

3.Section 4.2 and 4.3 2nd pa= ragraph

OLD TEXT:<= /p>

"

   In the followin= g paragraphs an example data correlation mechanism is

   explained and c= ould be use independently of the adopted solutions.

"

NEW TEXT:<= /p>

"

   In the followin= g paragraphs an example of data correlation mechanism is<= /p>

   explained and c= ould be use independently of the adopted solutions.

"

4.Section 9

OLD TEXT:<= /p>

"

The method doesn't raise any= specific need for standardization, but

   it could be fur= ther improved by means of some extension to existing

   protocols.=

"

NEW TEXT:<= /p>

"

The method doesn't raise any= specific need for protocol extension, but

   it could be fur= ther improved by means of some extension to existing

   protocols.=

"

 

[GF]= Thanks for all editorial changes.

 

-Qin

 

-----Messaggio originale-----

Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di Fioccola Giuseppe

Inviato: gioved=EC 7 luglio 2016 17:24=

A: ippm@ietf.org= ; ippm-chairs@tools.ietf.org

Oggetto: [ippm] I: I-D Actio= n: draft-ietf-ippm-alt-mark-01.txt

 

Hi All,

This new version of draft-ie= tf-ippm-alt-mark includes part of the contents of draft-chen-ippm-coloring-= based-ipfpm-framework.

The authors have merged some= Sections regarding Re-ordering Tolerance, Synchronization Aspects, Securit= y Considerations and other general concepts.

 

Best Regards,

 

Giuseppe

 

-----Messaggio originale-----

Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet-drafts@ietf.org

Inviato: gioved=EC 7 luglio 2016 16:33=

A: i-d-a= nnounce@ietf.org

Cc: ippm@ietf.org

Oggetto: [ippm] I-D Action: = draft-ietf-ippm-alt-mark-01.txt

 

 

A New Internet-Draft is avai= lable from the on-line Internet-Drafts directories.

This draft is a work item of= the IP Performance Metrics of the IETF.

 

    &nbs= p;   Title         &= nbsp; : Alternate Marking method for passive performance monitoring

    &nbs= p;  Authors        = ; : Giuseppe Fioccola

        &= nbsp;           &nbs= p;     Alessandro Capello

        &= nbsp;           &nbs= p;     Mauro Cociglio

        &= nbsp;           &nbs= p;     Luca Castaldelli=

    &nbs= p;            &= nbsp;        Mach(Guoyi) Chen=

    &nbs= p;            &= nbsp;        Lianshu Zheng

    &nbs= p;            &= nbsp;       Greg Mirsky

    &nbs= p;            &= nbsp;        Tal Mizrahi

    &nbs= p;   Filename        : draft-i= etf-ippm-alt-mark-01.txt

    &nbs= p;   Pages         &= nbsp; : 29

    &nbs= p;   Date         &n= bsp;  : 2016-07-07

 

Abstract:<= /p>

   This document d= escribes a passive method to perform packet loss,

   delay and jitte= r measurements on live traffic.  This method is based

   on Alternate Ma= rking (Coloring) technique.  A report on the

   operational exp= eriment done at Telecom Italia is explained in order

   to give an exam= ple and show the method applicability.  This technique

   can be applied = in various situations as detailed in this document.

 

 

The IETF datatracker status = page for this draft is:

https://datatracker.ietf.org/doc= /draft-ietf-ippm-alt-mark/

 

There's also a htmlized vers= ion available at:

https://tools.ietf.org/html/draft-i= etf-ippm-alt-mark-01

 

A diff from the previous ver= sion is available at:

https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-ippm-alt-mark-01

 

 

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.

 

Internet-Drafts are also ava= ilable by anonymous FTP at:

<= span lang=3D"EN-US">ftp://ftp.ietf.org/internet-drafts/

 

____________________________= ___________________

ippm mailing list=

ippm@ietf.org

https://www.ietf.org/mailman/listinfo/ippm

 

Questo messaggio e i suoi allegati sono indirizza= ti esclusivamente alle persone indicate. La diffusione, copia o qualsiasi a= ltra azione derivante dalla conoscenza di queste informazioni sono rigorosa= mente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata = comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

 

This e-mail and any attachme= nts is confidential and may contain privileged information intended for the= addressee(s) only. Dissemination, copying, printing or use by anybody else= is unauthorised. If you are not the intended recipient, please delete this message and any attachments and adv= ise the sender by return e-mail, Thanks.

 

____________________________= ___________________

ippm mailing list=

ippm@ietf.org

https://www.ietf.org/mailman/listinfo/ippm

--_000_8fa05f8408a349918235fd9658b162b4TELMBXB02RM001telecomit_--