From nobody Wed Aug 3 08:50:48 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 8B0AB12DCE0 for ; Wed, 3 Aug 2016 08:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 hJqcyg5WRQnh for ; Wed, 3 Aug 2016 08:50:42 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC5D12D0CF for ; Wed, 3 Aug 2016 08:49:44 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id DCDF6DC55F8FA; Wed, 3 Aug 2016 15:49:40 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u73Fng7q023528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2016 15:49:43 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u73Fng4G022334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Aug 2016 15:49:42 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.152]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 3 Aug 2016 11:49:42 -0400 From: "Foote, Footer (Nokia - CA)" To: LUIS MIGUEL CONTRERAS MURILLO , "ippm@ietf.org" Thread-Topic: Comments on draft-mirsky-ippm-twamp-refl-registered-port Thread-Index: AdHpEqjbCkSnwpUnRrO4SExRsAA5TQAiZCWAAAYfrhAA+mz9AA== Date: Wed, 3 Aug 2016 15:49:42 +0000 Message-ID: <66C18DD753765D43B123935C5F27625E012FFC2F2A@US70UWXCHMBA03.zam.alcatel-lucent.com> References: <66C18DD753765D43B123935C5F27625E012FFBE29D@US70UWXCHMBA03.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Comments on draft-mirsky-ippm-twamp-refl-registered-port 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, 03 Aug 2016 15:50:46 -0000 Hi Luis, I think that is a good suggestion. We should consider this strongly for th= e next draft. Thanks, Footer -----Original Message----- From: LUIS MIGUEL CONTRERAS MURILLO [mailto:luismiguel.contrerasmurillo@tel= efonica.com]=20 Sent: Friday, July 29, 2016 12:24 PM To: Foote, Footer (Nokia - CA); ippm@ietf.org Subject: RE: Comments on draft-mirsky-ippm-twamp-refl-registered-port Hi Footer Thanks so much for the clarifications. One further comment about the first topic. I think it has also to be taken into consideration the concurrency in the n= umber of the sessions against the same well know port on a given device, I = mean, the potential impact of multiple sessions being active at the same ti= me on the same device. Maybe some recommendation or some guidance should be= included in the document about that. It could be the case that so many sim= ultaneous sessions could impact to some extent the reported TWAMP result (b= ecause of number of sessions, device architecture, etc) depending on variab= les like the frequency of the (simultaneous) tests. So some words about tha= t would be needed, in my opinion. As mentioned before I think this is a quite valuable idea. I'm open to help= on this in the way you consider more appropriate. Best regards Luis -----Mensaje original----- De: Foote, Footer (Nokia - CA) [mailto:footer.foote@nokia.com] Enviado el: = viernes, 29 de julio de 2016 15:40 Para: LUIS MIGUEL CONTRERAS MURILLO ; ippm@ietf.org Asunto: RE: Comments on draft-mirsky-ippm-twamp-refl-registered-port Hi Luis, Thank you for your comments. I have included some notes below. Footer Nokia From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of LUIS MIGUEL CONTRERA= S MURILLO Sent: Thursday, July 28, 2016 4:59 PM To: ippm@ietf.org Subject: [ippm] Comments on draft-mirsky-ippm-twamp-refl-registered-port Hi, I've gone through the draft, which presents an interesting idea from an ope= rator perspective. However there are some points not yet clear for me, that= maybe need to be clarified in the draft. Please, find here below a number = of comments: . What about scenarios where one endpoint is simultaneously tested = from several other flow generators? I'm referring for instance to cases lik= e the testing of X2 interfaces in LTE scenarios. For example, and eNB could= receive a number of testing flows from other neighboring eNBs. Just using = (or having) one well-known port could not be sufficient for cases like this= . [Footer - If I understand correctly, the X2 reference point is a logical IP= connection between neighboring EnodeBs. The IP flows (sessions) can be dis= tinguished by the tuple of SIP, DIP, SP, DP. If multiple IP flows (session= s) are coming from the same SourceIP (e.g. multiple test sessions say with = different QoS marking) the Source UPD Port will be different. If multiple = IP flows (sessions) are coming from different sources (e.g. testing an X2 m= esh), then the SourceIP will be different. All that is required to disting= uish the IP flow (session) is one different variable.] . The objective of using this well-known port approach seems to be = justified as a way of simplifying the logic of the reflector. However secti= on 3, last paragraph, seems to state (in my understanding) that in case of = any issue it will be possible to rely on the conventional TWAMP signaling. = Then it seems that the support of the signaling is yet required because of = the backward compatibility. Then, what is the real advantage for the end de= vice, if finally we need the signaling suite for backward compatibility any= way? [Footer - The paragraph may need some rewording. It is meant to say that t= he TWAMP Receiver UDP Port number (tbd) can also be used in the client/serv= er negotiation when TWAMP Client/Server model is deployed. It does not cau= se any backward compatibility for operators that have already deployed TWAM= P or wish to deploy TWAMP using the Client/Server model. The client should = accept the UDP port the Server responds with, in this case that port could = be the well-known UDP port.] . I'm not so sure that further security considerations could not be= needed in this case. As far as the port is defined, DoS attacks and other = malicious behaviors could be focus on it. Also it is required to understand= what could be the port to be used when the reflector is also sender, in or= der to avoid fraudulent use as well by third parties or man-in-the-middle a= ttacks [Footer - Some examples to enhance security could be: filtering access to t= he UDP port by access lists, using non-routable IPs outside of the domain f= or the TWAMP loopback, etc. I think you are correct. This section may nee= d to be expanded. On the second point, I would also agree that the well-kn= own UDP port not be used as a source port.] Thanks in advance for any further clarification. As mentioned, I see potent= ial advantages by using this approach, but probably some refinements are ye= t needed (or even recommendations of usage) in order to have a real operati= onal case. Thanks Best regards Luis __________________________________ Luis M. Contreras Technology and Planning Transport, IP and Interconnection Networks Telef=F3nica I+D / Global CTO un= it / Telef=F3nica Distrito Telef=F3nica, Edificio Sur 3, Planta 3 28050 Madrid Espa=F1a / Spain Skype (Lync): +34 91 312 9084 Mobile: +34 680 947 650 luismiguel.contrerasmurillo@telefonica.com ________________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Tue Aug 9 04:35:18 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 710BF12D606 for ; Tue, 9 Aug 2016 04:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, 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 vq4uxfcu7iOK for ; Tue, 9 Aug 2016 04:35:15 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9F63812D7C2 for ; Tue, 9 Aug 2016 04:35:15 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 3E3D91A104A for ; Tue, 9 Aug 2016 13:35:13 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_B0A6BE50-240A-4271-BD9C-A89CF797A983"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 9 Aug 2016 13:35:11 +0200 Message-Id: <47BFD285-9057-4FD4-B662-1340006DC882@trammell.ch> To: IETF IPPM WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] Draft minutes posted... 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, 09 Aug 2016 11:35:17 -0000 --Apple-Mail=_B0A6BE50-240A-4271-BD9C-A89CF797A983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ...at https://www.ietf.org/proceedings/96/minutes/minutes-96-ippm. = Please send corrections to ippm-chairs@tools.ietf.org. Thanks, cheers, Brian (chair hat) --Apple-Mail=_B0A6BE50-240A-4271-BD9C-A89CF797A983 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXqb/wAAoJEIoSt78L6kajA1YQAL6dp7zkMDulK4n8Td5QeIOd Ryk/LYPVoDYs3OalA1HXbK+GgNguBbsx8+Lk1VyU3PAlUWkNg2mXx/SCYDk/AMGk 132exyhUJ7qQrymflUEC/4czAPAs+SxECRZhEgXSgUSuw85r9eQDLXYOMZFfxL/l dsBT6mWEOzFu0Wk6Io+IwOkg7pDf/5FkcOV4odSDs8VlqxLYJz7kX/90hPKHoefw wzmfnT0rKamx5gcLUxc7jXBlDaxUlaIToS2M/67QbkuWx/J2s050mayMnntep+Pu aca6znH73Go6rYxC9vJn8Yuscr4KxnIrvowNchJmKfTQuxx+RRc0gXWTMUrmyL0I dlzizASJ3BI8dSLNz1GZlZGMgXrLAbbhjb85sfi4MZDyksKrhoc4AawbG0ABxhtS zIrB4ZhXujCFoF4ZIzRDEGgLWB8qtKlSArPETzu+z/WuBy0djT68aKi8OScMJzxw JAzg5fJEn9mroe3L2KxM5o0tX0ypQjpiGwyvV94m/epfqjGIP3Ew1snW8Zc5TAO+ gtHZk9OoRs3OOBzvwL46aTHmcaoMc2cRhxMkSEbiTTE4b1h9aRQMi5xE50RwxBJ3 00BKxW0zs7ujen5HXvXaL5A1CZR+Ju/xSJWlS5nd/GX0dMVCHcAOSA0z0ZiniIlu 8yk7Z2KlcJeKttK5dZCB =hEDI -----END PGP SIGNATURE----- --Apple-Mail=_B0A6BE50-240A-4271-BD9C-A89CF797A983-- From nobody Mon Aug 15 09:30: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 B848C12D685; Mon, 15 Aug 2016 09:30:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147127865074.31627.8217964450606522535.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2016 09:30:50 -0700 Archived-At: Cc: ipr-announce@ietf.org, ippm@ietf.org Subject: [ippm] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-mirsky-ippm-time-format and draft-ietf-ippm-twamp-time-format 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, 15 Aug 2016 16:30:51 -0000 Dear Greg Mirsky, Israel Meilik: An IPR disclosure that pertains to your Internet-Draft entitled "Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)" (draft-ietf-ippm-twamp-time-format) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2851/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-mirsky-ippm-time-format and draft-ietf-ippm-twamp-time-format" Thank you IETF Secretariat From nobody Mon Aug 15 09:32: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 532DF12D916; Mon, 15 Aug 2016 09:32:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147127875633.31632.5089722916739944533.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2016 09:32:36 -0700 Archived-At: Cc: ipr-announce@ietf.org, ippm@ietf.org Subject: [ippm] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-mirsky-ippm-time-format and draft-ietf-ippm-twamp-time-format 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, 15 Aug 2016 16:32:36 -0000 Dear Greg Mirsky, Israel Meilik: An IPR disclosure that pertains to your Internet-Draft entitled "Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)" (draft-ietf-ippm-twamp-time-format) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2850/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-mirsky-ippm-time-format and draft-ietf-ippm-twamp-time-format" Thank you IETF Secretariat From nobody Mon Aug 15 09:58:22 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 3BBAB12D5D1 for ; Mon, 15 Aug 2016 09:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.191 X-Spam-Level: X-Spam-Status: No, score=-4.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 1FagtVcT-PJR for ; Mon, 15 Aug 2016 09:58:18 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127C312D8F0 for ; Mon, 15 Aug 2016 09:55:09 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-6a-57b1f4c183ad Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 0B.FC.02568.1C4F1B75; Mon, 15 Aug 2016 18:58:41 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0301.000; Mon, 15 Aug 2016 12:51:28 -0400 From: Gregory Mirsky To: Brian Trammell , IETF IPPM WG Thread-Topic: [ippm] Working Group Last Call on draft-ietf-ippm-twamp-time-format Thread-Index: AQHR4ciV5ae58Acdiki6d4l2+kJ0fqBKZcHA Date: Mon, 15 Aug 2016 16:51:27 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221B03F8C@eusaamb103.ericsson.se> References: <268D94BF-FC05-4CCC-9B2B-EAE9C06A147C@trammell.ch> In-Reply-To: <268D94BF-FC05-4CCC-9B2B-EAE9C06A147C@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221B03F8Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPoO7BLxvDDe4sNbfY2PKOzaLnwTtm ByaPJUt+Mnk82T+TJYApissmJTUnsyy1SN8ugSvj71qtgu0uFZuvnmVtYJxt08XIySEhYCLR ePw3YxcjF4eQwAZGiWe/DrNBOMsZJf4/ucMGUsUmYCTxYmMPO4gtIuAsMfHdTFYQW1ggSGLz 7GnMXYwcQPFgiW0HtSBMI4mZfbwgFSwCqhJrzkwB6+QV8JXo6ehjBrGFBOwkzrz7CGZzCthL tN38AmYzCohJfD+1hgnEZhYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwphK0lMWnqOFaI+X6Kl 6SczxC5BiZMzn7BMYBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM HKXFBTm56UYGmxiBEXJMgk13B+P96Z6HGAU4GJV4eBds3BAuxJpYVlyZe4hRgoNZSYR3+8eN 4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5xR4phgsJpCeWpGanphakFsFkmTg4pRoYuSptpY8u cLRewDBZ5cSn5Xu8Jpsf3HvzYUTPoYbKrAK+0z9mFN1+JqXdkvGsrcvRo2rxhDkrJod6vH/j Ndvkfo58d6ONkIB95jfNY0zzeLmiF/56+Ynp6JTltp073N/LSx5aZNV7t1ZQ65TcseIl8t3p 1yLirSUund6YytMb9dWgru7MqpWqSizFGYmGWsxFxYkA4Z065IwCAAA= Archived-At: Subject: Re: [ippm] Working Group Last Call on draft-ietf-ippm-twamp-time-format 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: Mon, 15 Aug 2016 16:58:20 -0000 --_000_7347100B5761DC41A166AC17F22DF11221B03F8Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Brian, Bill, et. al, I may have missed the IPR call on this draft. Two IPR disclosures being published that, to the best of my knowledge and u= nderstanding, may be related to the draft-ietf-ippm-twamp-time-format-00: * https://datatracker.ietf.org/ipr/2850/ * https://datatracker.ietf.org/ipr/2851/ I don't know of any other IPR related to this draft. And yes, I support progress of this draft. Regards, Greg -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Tuesday, July 19, 2016 6:39 AM To: IETF IPPM WG Subject: [ippm] Working Group Last Call on draft-ietf-ippm-twamp-time-forma= t Greetings, all, This message begins a Working Group Last Call on draft-ietf-ippm-twamp-time= -format-00 (https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-fo= rmat/), to end on Friday 19 August 2016. Please post comments and feedback = to the ippm@ietf.org list. Thanks, cheers, Brian and Bill (as chairs) --_000_7347100B5761DC41A166AC17F22DF11221B03F8Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Brian, Bill, et. al,

I may have missed the IPR call on this draft.

Two IPR disclosures being published that, to the = best of my knowledge and understanding, may be related to the draft-ietf-ip= pm-twamp-time-format-00:

·         https://datatracker.ietf.org/ipr/2850/

·         https://datatracker.ietf.org/ipr/2851/

 

I don’t know of any other IPR related to th= is draft.

 

 

And yes, I support progress of this draft.

 

        &= nbsp;       Regards,

        &= nbsp;           &nbs= p;           Greg

 

-----Original Message-----
From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Brian Trammell
Sent: Tuesday, July 19, 2016 6:39 AM
To: IETF IPPM WG <ippm@ietf.org>
Subject: [ippm] Working Group Last Call on draft-ietf-ippm-twamp-time-forma= t

 

Greetings, all,

 

This message begins a Working Group Last Call on = draft-ietf-ippm-twamp-time-format-00  (https://datatracker.ietf.org/doc/draft-ietf-ipp= m-twamp-time-format/), to end on Friday 19 August 2016. Please post comments and feedback to the = ippm@ietf.org<= /a> list.

 

Thanks, cheers,

 

Brian and Bill (as chairs)

--_000_7347100B5761DC41A166AC17F22DF11221B03F8Ceusaamb103erics_-- From nobody Fri Aug 19 06:41: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 25AFD12DA2E for ; Fri, 19 Aug 2016 06:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 QphQg3JQQdLd for ; Fri, 19 Aug 2016 06:41:24 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8848B12DAC3 for ; Fri, 19 Aug 2016 06:39:18 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DD3A320663 for ; Fri, 19 Aug 2016 09:39:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Fri, 19 Aug 2016 09:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=m3lDJe26NPQmwYl C0mPPbYRhXbI=; b=AFzEFLe58rRrSf3IWboPQXPbFOiRgbHXQUDAePzyIKyswSs deBjNadzEIPvpyNbbrh9pIptidBVdVX0cGwus+9jUF5JL0B8gHOnK1OGJHDAtoxF uXRoA4qAX2TrbwfIeXvfFPlvKh2M89lrl4GqgCxhcym7Z10FI1Q65BsapSKo= X-Sasl-enc: KIwSt0QlhmyifrpbAaYKx2f12ZfK/M8nPjd30VCLw4+b 1471613957 Received: from eng-6-21.aa.arbor.net (unknown [216.130.192.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 89C95F2D2B for ; Fri, 19 Aug 2016 09:39:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bill Cerveny In-Reply-To: Date: Fri, 19 Aug 2016 09:39:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <157A1EBF-DE34-4872-8C43-50B808B2EC33@wjcerveny.com> References: To: IETF IPPM WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Working Group Last Call on draft-ietf-ippm-model-based-metrics 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: Fri, 19 Aug 2016 13:41:26 -0000 Dear IPPM participants: As far as I can tell, there has not been any discussion on this revision = of draft-ippm-model-based-metrics since WGLC was announced a month ago. Please read this draft and send comments to the list, even if your = comments are that you=E2=80=99ve read the draft and think it is ready = for publication. Thanks, Bill Cerveny > On Jul 19, 2016, at 9:36 AM, Brian Trammell wrote: >=20 > Greetings, all, >=20 > This message begins a Working Group Last Call on = draft-ietf-ippm-model-based-metrics-08 = (https://datatracker.ietf.org/doc/draft-ietf-ippm-model-based-metrics/), = to end on Friday 19 August 2016. Please post comments and feedback to = the ippm@ietf.org list. >=20 > Note that the draft's working copy is at = https://github.com/mattmathis/draft-ietf-ippm-mbm. If you send comments = as pull requests against the author's repository, please post the = suggested diffs for discussion on the list. >=20 >=20 > Thanks, cheers, >=20 > Brian and Bill (as chairs) > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Mon Aug 22 17:37:54 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 02ED612D103 for ; Mon, 22 Aug 2016 17:37:52 -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 HL8DdxnDpaTD for ; Mon, 22 Aug 2016 17:37:50 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 BE7BE12B05B for ; Mon, 22 Aug 2016 17:37:49 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id d10so45527708ybi.1 for ; Mon, 22 Aug 2016 17:37:49 -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:cc; bh=jnCono8ns6OER1w45Cmt4SHLKbONhinlFMhqJPLbdWM=; b=kKrIOvxPOrybH3PtW9h6S98LvgdX3kcgqR015gSZ23E2xjAXwBi7TRXSCtGIhZmzyI h3qH6MKqPHyQnxwwLsgpims2mgjN9vfA1JKZocaZ1wknTEaRQ6tdNEmH9Qy0bwvwhyIZ DrpGjontKkEcnZN75AQOdDB6mFG3rM1Sze8c4PxUPgUAriC5o0zDubcTZiLG92zw8GRV OwDBAH6a1yeAXAbM+YS8b3+YdZOnRPUG89wrdS6qphwsYIdp2l3VXO/gG3QJ1/Erga6a HJacRTJ4D2D5SXrqpKixzNs0dPx4W0rl2g8nBbk6mpiwV40sK6D3RvhNdkhqw7uEH1ec eChA== 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:cc; bh=jnCono8ns6OER1w45Cmt4SHLKbONhinlFMhqJPLbdWM=; b=Y7ZQ8tvJNGoW0IgNMhBADFF7PYt4p++kXB8WArnh3oXoxI81rrcPUSGxO0MEKOd9oq R41zciA5bAK3XvTp1FuRwCGgxcTgbxHBVpwZOjw1eiq9CI+3HMTdU0auQg2D+IEkH3H9 mNDfUAsvjKdign5dzInWyqiqo46Sr8W3OLqE2t71DVqk4k+5s8fHMqR+8lcqFoUlUsnO LpByAqXD91sSQewITQ/MqIlPy/7whq7Xa4hvCBv53HWOCJ4hylXBnrnIX+XBn7Yvxhsv lPa33uIIMF30FOrFlWlADhEsDKJUezDXOw+Z1cdXSCJ3d2Lh2XLcyZdi2SYtspSfRCyS 1Gyw== X-Gm-Message-State: AEkoouvNeTx3t0Hby0tvYUynEUP0iD9QCvXcKRbQm3l5AktCMtxlhempde0GGnwc651K5vkPjQRcu4+AJxNqWw== X-Received: by 10.37.99.65 with SMTP id x62mr18064779ybb.76.1471912668819; Mon, 22 Aug 2016 17:37:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.72.132 with HTTP; Mon, 22 Aug 2016 17:37:48 -0700 (PDT) From: Spencer Dawkins at IETF Date: Mon, 22 Aug 2016 19:37:48 -0500 Message-ID: To: draft-ietf-ippm-6man-pdm-option@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c150eec417bf053ab25fbd Archived-At: Cc: ippm@ietf.org Subject: [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, 23 Aug 2016 00:37:52 -0000 --001a11c150eec417bf053ab25fbd Content-Type: text/plain; charset=UTF-8 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 ... --001a11c150eec417bf053ab25fbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0 =C2=A0
It's probably a good thing to= use the organization from RFC 7322, just to sidestep reviewers who start o= ut complaining about document structure nits and then keep on typing. Not t= hat I ever did that in six years as a Gen-ART reviwer, of course :-) ...

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
=C2=A0 =C2=A0
and

=C2=A0 =C2=A0De= lta Time Last Sent =3D Receive time packet 2 - Send time packet 1
=C2=A0 =C2=A0
these are mathematical expressions, aren't the= y? If so, that would likely be clearer if the right side terms had parenthe= ses around the expression.

(It's a bit odd tha= t the first expression uses the abbreviation DELTATLR and the second term i= s spelled out as "Delta Time Last Sent" - you might think about w= hich seems clearer, and do that with both expressions)

=
In text like this

=C2=A0 =C2=A0We propose a b= ase unit for the time. =C2=A0
=C2=A0 =C2=A0
you probabl= y 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 multipl= e places.

For this text

= =C2=A0 =C2=A0Assume that two packets are sent for each ACK from the server.=
=C2=A0 =C2=A0
you might point out that TCP does this, = per RFC 1122 Section 4.2.3.2.=C2=A0

In this text f= rom 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.
=C2=A0 =C2= =A0
that's an interesting point in the broader sense, because= (duh) putting PDM in a TCP option doesn't help you with any other tran= sport protocol (SCTP, QUIC, what else are we doing these days? and, of cour= se, they're all running over UDP anyway). I wonder if that's worth = pointing out earlier in the document, perhaps in Section 1.4?=C2=A0

This text

=C2=A0 =C2=A0Let's= say that packet 4 STILL does not make it.
=C2=A0 =C2=A0
is probably too breezy to translate well into other languages. Perhaps &q= uot;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 tha= t are doing pervasive monitoring (RFC 7258), and possibly about (2) what ha= ppens 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 demons= trating awareness of at least (1) will shorten the review comments cycle. P= ossibly a lot, judging by recent ballots on other drafts ... --001a11c150eec417bf053ab25fbd-- From nobody Tue Aug 23 06:42:25 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 D722412D191 for ; Tue, 23 Aug 2016 06:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 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=-0.548] 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 e0ocmpJ8AHY7 for ; Tue, 23 Aug 2016 06:42:20 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2952C12D18E for ; Tue, 23 Aug 2016 06:42:19 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 23 Aug 2016 15:42:17 +0200 X-IronPort-AV: E=Sophos;i="5.28,566,1464645600"; d="scan'208";a="518421981" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by qde0ps.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2016 15:42:17 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Aug 2016 15:42:13 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1210.000; Tue, 23 Aug 2016 15:42:12 +0200 From: To: Thread-Topic: [ippm] Working Group Last Call on draft-ietf-ippm-model-based-metrics Thread-Index: AQHR+h9nNo6fjPTb1EOu4SU/mgHlHaBWkb+Q Date: Tue, 23 Aug 2016 13:42:12 +0000 Message-ID: <2ccf42b0c2af40068b450f4c1ac16a98@HE101653.emea1.cds.t-internal.com> References: <157A1EBF-DE34-4872-8C43-50B808B2EC33@wjcerveny.com> In-Reply-To: <157A1EBF-DE34-4872-8C43-50B808B2EC33@wjcerveny.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.171.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ippm@ietf.org Subject: Re: [ippm] Working Group Last Call on draft-ietf-ippm-model-based-metrics 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, 23 Aug 2016 13:42:25 -0000 SGkgQmlsbCwNCg0KSSB0aGluaywgdGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24u DQoNCkkndmUgcmVhZCBkcmFmdC1pZXRmLWlwcG0tbW9kZWwtYmFzZWQtbWV0cmljcy0wNy50eHQg YW5kIHRoZSBEaWZmIG9mIC0wOCB0byAtMDcuIEkgZm91bmQgb25seSBuaXRzIGluIC0wNyB3aGlj aCB3ZXJlIGNvcnJlY3RlZCBpbiAtMDgsIHNvIEkgaGFkIG5vIGNvbW1lbnRzLg0KDQpJJ3ZlIGNv bW1lbnRlZCBhbiBlYXJsaWVyIHZlcnNpb24gaW50ZW5zaXZlbHkuIE15IHRoYW5rcyB0byBBbCBh bmQgTWF0dCBmb3IgdGhlaXIgd29yayBhbmQgdGhlIHJldmlld2VkIHZlcnNpb24gdGhleSd2ZSBw cm9kdWNlZC4gIA0KDQpSZWdhcmRzLCBSdWVkaWdlcg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5h Y2hyaWNodC0tLS0tDQpWb246IGlwcG0gW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIElt IEF1ZnRyYWcgdm9uIEJpbGwgQ2VydmVueQ0KR2VzZW5kZXQ6IEZyZWl0YWcsIDE5LiBBdWd1c3Qg MjAxNiAxNTozOQ0KQW46IElFVEYgSVBQTSBXRw0KQmV0cmVmZjogUmU6IFtpcHBtXSBXb3JraW5n IEdyb3VwIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWlwcG0tbW9kZWwtYmFzZWQtbWV0cmljcw0K DQpEZWFyIElQUE0gcGFydGljaXBhbnRzOg0KDQpBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhlcmUg aGFzIG5vdCBiZWVuIGFueSBkaXNjdXNzaW9uIG9uIHRoaXMgcmV2aXNpb24gb2YgZHJhZnQtaXBw bS1tb2RlbC1iYXNlZC1tZXRyaWNzIHNpbmNlIFdHTEMgd2FzIGFubm91bmNlZCBhIG1vbnRoIGFn by4NCg0KUGxlYXNlIHJlYWQgdGhpcyBkcmFmdCBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgbGlz dCwgZXZlbiBpZiB5b3VyIGNvbW1lbnRzIGFyZSB0aGF0IHlvdeKAmXZlIHJlYWQgdGhlIGRyYWZ0 IGFuZCB0aGluayBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNClRoYW5rcywNCg0KQmls bCBDZXJ2ZW55DQoNCj4gT24gSnVsIDE5LCAyMDE2LCBhdCA5OjM2IEFNLCBCcmlhbiBUcmFtbWVs bCA8aWV0ZkB0cmFtbWVsbC5jaD4gd3JvdGU6DQo+IA0KPiBHcmVldGluZ3MsIGFsbCwNCj4gDQo+ IFRoaXMgbWVzc2FnZSBiZWdpbnMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiBkcmFmdC1p ZXRmLWlwcG0tbW9kZWwtYmFzZWQtbWV0cmljcy0wOCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLW1vZGVsLWJhc2VkLW1ldHJpY3MvKSwgdG8gZW5kIG9u IEZyaWRheSAxOSBBdWd1c3QgMjAxNi4gUGxlYXNlIHBvc3QgY29tbWVudHMgYW5kIGZlZWRiYWNr IHRvIHRoZSBpcHBtQGlldGYub3JnIGxpc3QuDQo+IA0KPiBOb3RlIHRoYXQgdGhlIGRyYWZ0J3Mg d29ya2luZyBjb3B5IGlzIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9tYXR0bWF0aGlzL2RyYWZ0LWll dGYtaXBwbS1tYm0uIElmIHlvdSBzZW5kIGNvbW1lbnRzIGFzIHB1bGwgcmVxdWVzdHMgYWdhaW5z dCB0aGUgYXV0aG9yJ3MgcmVwb3NpdG9yeSwgcGxlYXNlIHBvc3QgdGhlIHN1Z2dlc3RlZCBkaWZm cyBmb3IgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4NCj4gDQo+IA0KPiBUaGFua3MsIGNoZWVycywN Cj4gDQo+IEJyaWFuIGFuZCBCaWxsIChhcyBjaGFpcnMpDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1A aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1h aWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHBtDQo= From nobody Tue Aug 23 10:42:09 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 3117412D115 for ; Tue, 23 Aug 2016 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_H2=-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 Xe6McqAOyQaE for ; Tue, 23 Aug 2016 10:42:06 -0700 (PDT) Received: from nm8-vm0.bullet.mail.ne1.yahoo.com (nm8-vm0.bullet.mail.ne1.yahoo.com [98.138.91.23]) (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 F24C412D11C for ; Tue, 23 Aug 2016 10:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1471974125; bh=jLCgD1gcsBJvfcW22o2yAkNBPMHoDIJe21zpXPI31QU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Iez5KMNyDlF9+oa4n8rFIhWWaRhEseWSHaYzZEl+X/H9lnXSSy47Br+jGT+aWLSWbBkmFv2dhoxiMSycR5PZXAU9qjMr3I2bzEYb++Y7R4zYt7cwn4KxR8ChHtHMSjrVovGvh9+HrdtJ3m0r6VBrMNsjzMAtWLU3/ePGLr6p2qN3+rc/WVCoMwE4zjGnjud2hhKRMqY8KYuUNxc80734T0Mb/4wFwL1YkLYjWyYoTlh7QKNaFloUUUeTVlFItEVB1kGsy91HraQUeOtc+7S2z+qGrTvjEC40lLgwZd6B16nmzzU1v+B7nNXl/ZAKpNgabkfAL3G38c7Y5LNRH2YMpQ== Received: from [98.138.100.103] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 23 Aug 2016 17:42:05 -0000 Received: from [98.138.88.232] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 23 Aug 2016 17:42:05 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 23 Aug 2016 17:42:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 443956.64555.bm@omp1032.mail.ne1.yahoo.com X-YMail-OSG: qSR5CTEVM1k85fnQkCA4HGO9VN5d9Jf.U8Z1_yqHc7TuTkAF4yRopFw0.cy5qwF FuMxEAPVNFmK9LkxaVmth6PYKBrfEKVf.OuKH7P8q2vNgHyjXHZ12kpgE0mtStLNnSLR7IL40iPc QPVUpRBj0nzhoi4NGExpyqp.1tGqFEVkjFx8sqMZo5qds4PgZzzOazXZnRyEGDYj_pQke8caUxh0 j5xuXraBXo0VjJfpmRdBHIaIWMnX0kuV8xraVjJQ9nb_s38Bt62NH3tb6D9QWboHUdWD0_BoVnX9 0w1y17FKjB3Vs8JnoUaOvZwFudspBYJXT9BlvboI8JaFfEkAsOb7Y4oo0_EyTWD8Pgin_smLd1Em bSzB50selqXAGomqLuJeCX.pXMUEofwb1sg9cQW5yz.M.hN_.il0SRI5Kut.ZazHrAn0XBO5fi48 pl8vjjm1gPPksXp0PmQYO0hebzyss2Rdev2l5nP1kthWaSfWm1JkQ609D3mczGUfZFa8sXfjCg54 mhobjBlCW9J6tVauG6OQUAYTocP4vA0gYGeeIuH_aaL0AL2w4oycicRpNX1hnXkzi7HpzLlch6Dp mKQPctJM0gOd.tO6NQQ-- Received: from jws100219.mail.ne1.yahoo.com by sendmailws138.mail.ne1.yahoo.com; Tue, 23 Aug 2016 17:42:05 +0000; 1471974125.050 Date: Tue, 23 Aug 2016 17:42:04 +0000 (UTC) From: To: Spencer Dawkins at IETF , "draft-ietf-ippm-6man-pdm-option@tools.ietf.org" Message-ID: <232473065.1009747.1471974124161@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1009746_656491069.1471974124151" 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, 23 Aug 2016 17:42:08 -0000 ------=_Part_1009746_656491069.1471974124151 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Spencer, Thanks for the kind words and the review. The authoring team will meet and discuss how to respond & get back to you. Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 From: Spencer Dawkins at IETF To: draft-ietf-ippm-6man-pdm-option@tools.ietf.org=20 Cc: ippm@ietf.org Sent: Monday, August 22, 2016 5:37 PM Subject: AD review of draft-ietf-ippm-6man-pdm-option-03 =20 Dear Authors, Nice work, and this would have been very valuable when I was implementing p= erformance 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 question= s, of course. Thanks, Spencer I saw the abstract following the table of contents mentioned in the shepher= d write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says=C2=A0 =C2=A0 =C2=A0A Table of Contents (TOC) is required in all RFCs.=C2=A0 It mu= st be=C2=A0 =C2=A0positioned after the Copyright Notice and before the Intr= oduction.=C2=A0 =C2=A0It's probably a good thing to use the organization fr= om RFC 7322, just to sidestep reviewers who start out complaining about doc= ument structure nits and then keep on typing. Not that I ever did that in s= ix 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=C2=A0 = =C2=A0and =C2=A0 =C2=A0Delta Time Last Sent =3D Receive time packet 2 - Send time pac= ket 1=C2=A0 =C2=A0these are mathematical expressions, aren't they? If so, t= hat 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 an= d the second term is spelled out as "Delta Time Last Sent" - you might thin= k 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. =C2=A0=C2=A0 =C2=A0you pr= obably 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 =C2=A0 =C2=A0Assume that two packets are sent for each ACK from the server.= =C2=A0 =C2=A0you might point out that TCP does this, per RFC 1122 Section 4= .2.3.2.=C2=A0 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.=C2=A0 =C2=A0that's an interest= ing point in the broader sense, because (duh) putting PDM in a TCP option d= oesn't help you with any other transport protocol (SCTP, QUIC, what else ar= e 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?=C2=A0 This text =C2=A0 =C2=A0Let's say that packet 4 STILL does not make it.=C2=A0 =C2=A0is= probably too breezy to translate well into other languages. Perhaps "is al= so lost"? (Yes, I talk like this, too) In the Security Considerations section, you might want to say something abo= ut (1) what watching the unencrypted PDM values might tell attackers that a= re doing pervasive monitoring (RFC 7258), and possibly about (2) what happe= ns if PDM is used as a covert channel. I don't think either of these will b= e showstoppers at SECDIR review time, but I'd expect that demonstrating awa= reness of at least (1) will shorten the review comments cycle. Possibly a l= ot, judging by recent ballots on other drafts ... =20 ------=_Part_1009746_656491069.1471974124151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Spencer,

Thanks for the kind words and the review.

The authoring team will meet and discuss how to respond & ge= t back to you.

=
Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
<= div id=3D"yui_3_16_0_ym19_1_1471972813308_23285">(831) 659-8360
=
<= br>
From: Spencer Dawkins at IETF <spenc= erdawkins.ietf@gmail.com>
To:<= /span> draft-ietf-ippm-6man-pdm-option@tools.ietf.org
Cc: ippm@ietf.org
Sent: Monday, August 22, 2016 5:37 PM
<= b>Subject: AD review of draft= -ietf-ippm-6man-pdm-option-03

Dear Authors,

Nice work, and this wou= ld 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 reques= t IETF Last Call for this draft. Please let me know if you have any questio= ns, of course.

Thanks,

Sp= encer

I saw the abstract following the table of co= ntents 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 a= nd before the Introduction.
   
It's probably= a good thing to use the organization from RFC 7322, just to sidestep revie= wers 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 c= ourse :-) ...

I probably lack imagination, but per= haps other readers will, also.

In this text
<= div>
   DELTATLR =3D Send time packet 2 - Receive t= ime packet 1
   
and

   Delta Time Last Sent =3D Receive time packet 2 - Send time pa= cket 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 secon= d term is spelled out as "Delta Time Last Sent" - you might think about whi= ch seems clearer, and do that with both expressions)

In text like this

   We propose a bas= e unit for the time.  
   
you probably = want to use a verb like "specify" (when the draft is published as an RFC, i= t 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 tha= t 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 - Mult= iple Send with Errors

   One might wonde= r if all of the functions of PDM might be better
   sui= ted to TCP or a TCP option.
   
that's an int= eresting point in the broader sense, because (duh) putting PDM in a TCP opt= ion doesn't help you with any other transport protocol (SCTP, QUIC, what el= se are we doing these days? and, of course, they're all running over UDP an= yway). I wonder if that's worth pointing out earlier in the document, perha= ps in Section 1.4? 

This text

<= /div>
   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 e= ither of these will be showstoppers at SECDIR review time, but I'd expect t= hat demonstrating awareness of at least (1) will shorten the review comment= s cycle. Possibly a lot, judging by recent ballots on other drafts ...


------=_Part_1009746_656491069.1471974124151-- From nobody Sun Aug 28 20:56:14 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 5303012B061 for ; Sun, 28 Aug 2016 20:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 h2pTEKU7Szfn for ; Sun, 28 Aug 2016 20:56:09 -0700 (PDT) Received: from mailrelay22.naist.jp (mailrelay22.naist.jp [IPv6:2001:200:16a:50::91]) by ietfa.amsl.com (Postfix) with ESMTP id C566A12B057 for ; Sun, 28 Aug 2016 20:56:08 -0700 (PDT) Received: from mailpost22.naist.jp (mailscan22.naist.jp [163.221.80.59]) by mailrelay22.naist.jp (Postfix) with ESMTP id C52C928E for ; Mon, 29 Aug 2016 12:56:06 +0900 (JST) Received: from naist-wavenet124-244.naist.jp (naist-wavenet124-244.naist.jp [163.221.124.244]) by mailpost22.naist.jp (Postfix) with ESMTPSA id AEF4028D for ; Mon, 29 Aug 2016 12:56:06 +0900 (JST) From: Marius Georgescu Content-Type: multipart/alternative; boundary="Apple-Mail=_063C2DA3-DE2D-4B19-9F04-BC2AA510E081" Message-Id: Date: Mon, 29 Aug 2016 12:56:06 +0900 To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSS-7.1.0.1392-8.0.0.1202-22542.005 X-TM-AS-Result: No--17.057-5.0-31-10 X-imss-scan-details: No--17.057-5.0-31-10 X-TMASE-MatchedRID: 66BtJSlJtHc7MwFDNigBPl4t42nqFS2wItBV90o9GGap+po932P8HgZy C1572Xh+lyrPeDQDh/KXDMTJgOHid1G/eE72T0NC0mAM2eipqlqBRRUvxeOobRt3C8tYRJi1CHQ 4KYyl5dhveCKWtaLcaLMsPmSZxbpk1zuqJnnszJW/wPtA9baOj2+3hLAz/YUdSc0TqfOgD8IVVy +twYNPEtg/6HMUnrlaRlqShqb35p4UkWvaqUqLHwKzHKFHzLsJ0p32J58WZrJr2ha0EjaJJAbbw bvky5uPok7b0Yft8KFoOA9kFf9sy+q9xwosX7inDC/Vm90If4WRbaihAmSwd1BQks/Le550KGI9 r3kB/qjQf/Mt4GBfb1gowyUWHgGdX6IRwqkp2m72AfVfUVx7i+ay3Mi+QGaXnDg49iZvbHPhgM0 hZwY6yVWO/JP5vQHd5BgEdUqqANR9LQinZ4QefK9dKZJ2Vxiasuf7RWbvUtyMHAKgQAZ4Ms/8zK 5WVP8LS0iSG6xyIZejPxW4TOhT9svEltKczvfVK+MvwHH8ZIKobyTCH74+AimyBew10KuatAJ0v EUDi9TNAO9Y8IkJxjG+IsOdYHoH8AfhBMF+EOW6B46gJv8BFuUH2+bY0IGE Archived-At: Subject: [ippm] Review of the YANG data model in draft-ietf-ippm-twamp-yang-01 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: Mon, 29 Aug 2016 03:56:11 -0000 --Apple-Mail=_063C2DA3-DE2D-4B19-9F04-BC2AA510E081 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello IPPM, Following the promise I made in IETF96, this is my review of the YANG = data model in https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-01 = . As a disclaimer, I have to note that I am quite new to both TWAMP and = YANG. Nevertheless, here are some comments that might be relevant: -1-=20 typedef twamp-modes { type bits { bit unauthenticated { position 0; description "Unauthenticated mode. See RFC 7717 Section=C2=A07 = ."; } The description refers to RFC7717 Section 7, which in turn refers to = RFC4656 Section 3.4 . I was wondering if a short description wouldn=E2=80=99= t be more disambiguating.=20 The comment applies for the authenticated and encrypted modes as well.=20= -2-=20 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."; } I was wondering what a =E2=80=9Csignificant amount of time=E2=80=9D = means, or if any reference value should be given. -3-=20 leaf server-start-time { type uint64; config false; description "The Start-Time advertized by the Server in the Server-Start message (RFC 4656, Section=C2=A03.1 = ). This is a timestamp representing the time when the current instantiation of the Server started operating."; } Maybe a time format would help. I think the same applies for leaf = start-time { -4- leaf max-interval { type uint32; description "Indicates the maximum time between packet transmissions."; } Maybe a time unit should be mentioned.=20 -5- 203.0.113.1 203.0.113.2 Test1 10.1.1.1 While the client/server IPs are using the RFC5737 documentation class, I = was wondering why the sender-IP is not.=20 Considering it is a private class, I am assuming a NAT box is considered = along the path. If that=E2=80=99s the case, maybe it should be = specified.=20 Best regards, Marius Georgescu --Apple-Mail=_063C2DA3-DE2D-4B19-9F04-BC2AA510E081 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello IPPM,

Following the promise I made in IETF96, = this is my review of the YANG data model in https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-01&n= bsp;.
As a disclaimer, I have to note that I am = quite new to both TWAMP and YANG.
Nevertheless, = here are some comments that might be relevant:

-1- 
    typedef twamp-modes {
      type bits {
        bit unauthenticated {
          position 0;
          description
              "Unauthenticated mode. See RFC =
7717 Section 7.";
        }
The description refers to RFC7717 Section = 7, which in turn refers to RFC4656 Section 3.4 . I was wondering if a = short description wouldn=E2=80=99t be more = disambiguating. 
The comment applies for = the authenticated and encrypted modes as well. 

-2- 

          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.";
          }

I was wondering what a =E2=80=9Csignificant amount of time=E2=80= =9D means, or if any reference value should be given.

-3- 

leaf server-start-time {
            type uint64;
            config false;
            description
              "The Start-Time advertized by the Server in the
              Server-Start message (RFC =
4656, Section 3.1). This is
              a timestamp representing the time when the =
current
            =
  instantiation of the Server started operating.";
          }

Maybe a time format would help. I think the same applies = for leaf start-time {

-4-
              leaf =
max-interval {
                type uint32;
                description
                  "Indicates the maximum time between packet
                  transmissions.";
              }
Maybe a time unit should be = mentioned. 

-5-
 <client-ip>203.0.113.1</client-ip>
               <server-ip>203.0.113.2</server-ip>
               <test-session-request>
                  <name>Test1</name>
                  <sender-ip>10.1.1.1</sender-ip>

While the = client/server IPs are using the RFC5737 documentation class, I was = wondering why the sender-IP is not. 
Considering= it is a private class, I am assuming a NAT box is considered along the = path. If that=E2=80=99s the case, maybe it should be = specified. 


Best regards,
Marius = Georgescu



= --Apple-Mail=_063C2DA3-DE2D-4B19-9F04-BC2AA510E081--