From D.Malas@cablelabs.com Tue Feb 10 10:22:54 2009 Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCB83A6C73; Tue, 10 Feb 2009 10:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5kVUKvvczD9; Tue, 10 Feb 2009 10:22:53 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id D9D803A6C28; Tue, 10 Feb 2009 10:22:52 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n1AIMrsX021622; Tue, 10 Feb 2009 11:22:54 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 10 Feb 2009 11:22:53 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2009 11:22:53 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B0CB@srvxchg3.cablelabs.com> In-Reply-To: <4919AC64.206@kth.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] [Sipping] RE: draft-ietf-pmol-sip-perf-metrics-02 Thread-Index: AclEF4CgQrsRbXnGRZ6vvYWp3tWNahHgvUww References: <4919AC64.206@kth.se> From: "Daryl Malas" To: "Gerald Q. Maguire Jr." X-Approved: ondar Cc: sipping@ietf.org, pmol@ietf.org Subject: [PMOL] [Sipping] RE: draft-ietf-pmol-sip-perf-metrics-02 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 18:22:54 -0000 Gerald, Thank you for the review and detailed feedback. I made changes in the draft per all of your suggestions; however, I modified some of them. See commments in-line... Regards, Daryl ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com =20 > -----Original Message----- > From: Gerald Q. Maguire Jr. [mailto:maguire@kth.se]=20 > Sent: Tuesday, November 11, 2008 9:02 AM > To: Daryl Malas > Subject: draft-ietf-pmol-sip-perf-metrics-02 >=20 > http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-02 >=20 > When measurement results will be correlated with other results or > information using time-of-day stamps, then the time clock that > supplies T1 SHOULD be synchronized to a primary time source, to > minimize the time offset. > should be: >=20 > When measurement results will be correlated with other results or > information using time-of-day stamps, then the time clock that > supplies T1 SHOULD be synchronized to a primary time source, to > minimize the error in the time offset. >=20 > This change is important as otherwise you have used "time=20 > offset" in a different meaning that you defined it in the=20 > prior paragraph. After considering your suggestion, I modified the paragraph to read: When measurement results will be correlated with other results or information using time-of-day stamps, then the time clock that supplies T1 SHOULD be synchronized to a primary time source, to minimize the error in the time offset. The time offset MUST be reported with each measurement. >=20 > -- > =20 > The accuracy of the T4-T1 interval is also critical to maintain and > report. The relevant definition from [12=20 > 2#ref-12>] is "skew": the difference > between time offsets at T1 and T4 is the error for the measurement > interval associated with the clock's skew. > should be: >=20 > The accuracy of the T4-T1 interval is also critical to maintain and > report. The difference in errors=20 > between the the time offsets at T1 and T4 is associated=20 > with the clock's skew[12=20 > 2#ref-12>]. I used the above paragraph suggestion. >=20 > Skew is according to the definition you cite in [12] related=20 > to the difference in clock frequency between a true clock and=20 > the local clock. > ("A clock's "skew" at a particular moment is the frequency difference > (first derivative of its offset with respect to true time) between > the clock and true time.[12]) >=20 > More properly the statement might be: > The accuracy of the measurement of the T4-T1 interval is critical and > should be reported. The difference in errors=20 > between the the time offsets at T1 and T4 is associated=20 > with the clock's skew[12=20 > 2#ref-12>] and the clock's "drift". >=20 > Even more formally this is because the (local) clock's=20 > "offset" at T1 and the (local) clock's "offset" at T4 are not=20 > the same, due to the (local) clock's skew and drift (the 1st=20 > and 2nd derivatives of the clock's frequency). >=20 > Here I have used "clock's offset" as defined in [12]. >=20 > --- >=20 > The clock error SHOULD > be constrained to less than +/- 1 ms, implying 1 part per 1000 > frequency accuracy for a 1 second interval. > should be: > The clock error SHOULD > be constrained to less than +/- 1 ms. This implies a=20 > frequency stability of greater 1 part per 1000 > for a 1 second interval. This implies greater stability is=20 > required as the length of the T4-T1 increases, > in order to constrain the error to be less than +/- 1 ms. >=20 > --- > The following statement, seems to imply that reading the time=20 > from a clock requires interrupt processing and this need not=20 > be the case. >=20 > The physical operation of reading time from a clock may be > constrained by the delay to service the interrupt. Therefore, the > accuracy of the time stamp read at T1 or T4 always includes the > interrupt delay, and this source of error SHOULD be known and > included in the error assessment. > =20 > It would be better to say: > The physical operation of reading time from a clock may be > constrained by the delay to service the interrupt.=20 > Therefore, if the > accuracy of the time stamp read at T1 or T4 includes > interrupt delay, then this source of error SHOULD be known and > included in the error assessment. >=20 > --- >=20 > There is also some confusion when you introduce the statement: > =20 > 2. If a free-running clock is used to make the time interval > measurement, then value of T1 reported SHOULD be derived from a > different clock that meets the time of day accuracy requirements >=20 > Since if you are measuring the T1 to T4 interval using such a=20 > clock, then there need not be a time of day measurement for=20 > T4, but rather an estimate of T4 based upon the measured=20 > intervals (measured using the free running clock) described=20 > above. Thus it is quite common today to measure a short time=20 > interval using the CPU's internal counter driven by the CPU=20 > clock (often as a RTC), this time interval can often be much=20 > higher resolution and have a much higher stability that the=20 > time of day clock. > Additionally this clock generally is accessed by a read=20 > register operation and not an interrupt. (Note that you still=20 > have to state the relationship between this clock and the=20 > time of day clock in order to specify when the measurement=20 > occurred - the time of day of T1.) >=20 I modified the paragraph to read: If a free-running clock is used to make the time interval measurement, then the time of day reported with the measurement (which is normally timestamp T1) SHOULD be derived from a different clock that meets the time of day accuracy requirements... > --- >=20 > I do not think that the following statement is correct - from=20 > a statistical data analysis point of view: > =20 > In regards to all of the metrics, the output values are directly > related to the accuracy and the equivalent level of granularity of > the input values. >=20 > The word "directly" is not strictly true. Perhaps the=20 > following might be better: >=20 > In regards to all of the metrics, the accuracy and=20 > granularity of the output values are > related to the accuracy and granularity of > the input values. >=20 > --- > Registration Request Delay is utilized to detect failures or > impairments causing delays in responding to a UAC REGISTER request. > RRD SHALL be measured and reported only for successful REGISTER > requests, and Ineffective Registration Attempts (Section=20 > 4.2=20 > 2#section-4.2>) SHALL > be reported for failures. This metric is measured at the UAC. The > output value of this metric is numerical and SHOULD be adjusted to > indicate milliseconds. The following represents the=20 > calculation for > this metric: > should be: >=20 > Registration Request Delay is a measurement of the delay in=20 > responding to a UAC REGISTER request. > RRD SHALL be measured and reported only for successful REGISTER > requests, while Ineffective Registration Attempts (Section=20 > 4.2=20 > 2#section-4.2>) SHALL > be reported for failures. This metric is measured at the UAC. The > output value of this metric is numerical and SHOULD be=20 > stated in units of milliseconds. > The following represents the calculation for this metric: >=20 > The changes are necessary since: > 1. RRD does not provide any information in the case of failures! > 2. The measured value is stated in milliseconds - since you=20 > have previously > stated that the clock error should be less than +/- 1=20 > millisecond. Of course from > a statistical point of view - the measured value can only=20 > be considered to be in units > of 2 milliseconds - since if you want to have 1=20 > millisecond accuracy, then the clock > has to be accurate to better than +/- 0.5 milliseconds=20 > (since the measurement is an > interval between to clock values). >=20 > Note that throughout the text you should be stating that it=20 > is not an adjustment to milliseconds, but rather that this is=20 > simply the units used for this measurement. >=20 > --- > In a successful registration attempt, RRD is defined as the time > interval from the moment the initial REGISTER message=20 > containing the > necessary information is passed by the originating UAC to the > intended registrar until the 200 OK is received indicating the > registration attempt has completed successfully. This dialog > includes an expected authentication challenge prior to=20 > receiving the > 200 OK as describe in the following registration flow examples. >=20 > In a successful registration attempt, RRD is defined as the time > interval from the first bit of the initial REGISTER message being > transmitted by the originating UAC to the > intended registrar until the 200 OK is last bit of the=20 > response indicating the > registration attempt has completed successfully has been=20 > received. This dialog > includes any expected authentication challenge prior to=20 > receiving the > 200 OK as describe in the following registration flow examples. >=20 > I think that the above changes are necessary because of the=20 > way you defined T1 and T4; and the fact that an challenge=20 > might not occur (or even need to occur) - thus the interval=20 > only includes the challenge and response if they are expected. Taking into consideration your suggestion, I have modified the paragraph to read: In a successful registration attempt, RRD is defined as the time=20 interval from the first bit of the initial REGISTER message containing the=20 necessary information is passed by the originating UAC to the=20 intended registrar until the last bit of the 200 OK is received indicating the=20 registration attempt has completed successfully. This dialog=20 includes an expected authentication challenge prior to receiving the=20 200 OK as describe in the following registration flow examples. I also updated all other metrics with a result of time to align with this. > --- >=20 >=20 > Ineffective registration attempts are utilized to detect failures or > impairments causing an inability for a registrar to receive or > respond to a UAC REGISTER request. This metric is measured at the > UAC. The output value of this metric is numerical and SHOULD be > adjusted to indicate a percentage of registration attempts. > should be: > Ineffective registration attempts are utilized to monitor=20 > registration failures, > i.e. the inability for a registrar to receive or > respond to a UAC REGISTER request. This metric is measured at the > UAC. The output value of this metric is numerical and SHOULD be > reported as a percentage of registration attempts. > --- > You say: > IRA may be > used to detect problems in downstream signaling functions,=20 > which may > be impairing the REGISTER message from reaching the intended > registrar; or, it may indicate a registrar has become=20 > overloaded and > is unable to respond to the request. >=20 > However, I would think of the first problem being upstream=20 > signaling - affecting the REGISTER message from reaching the=20 > registration, while downstream signaling problems would be=20 > reflected in the register's response not being able to reach the UAC. >=20 This was not worded well in the last revision and was noted to create confusion during the last working group session, so I have modified the paragraph to read: Ineffective registration attempts are utilized to detect failures or=20 impairments causing an inability for a registrar to receive a UAC REGISTER request. This metric is measured at the UAC. The output value of this metric is numerical and SHOULD be reported as a percentage of registration attempts. > --- >=20 > There should also be a statement with regard to the first=20 > figure on page 8 of if the Total number of REGISTER Requests=20 > increases by 3 or if these 3 attempts at transmission are=20 > part of a single registration attempt. I agree this is confusing. I have added the following paragraph under the signaling flow example: In the previous message flow the UAC retries a REGISTER request multiple times before the timer, indicating the failure, expires. Only the first REGISTER request MUST used for input to the calculation and an IRA. Subsequent REGISTER retries are identified by the same Call-ID and MUST be ignored for purposes of metric calculation. This ensures an accurate representation of the metric output.=20 >=20 > --- >=20 >=20 > Session Request Delay (SRD)is not a metric, but rather a set of > metrics. This is the case because you do not combine successful > and failed responses in the same result. Thus any=20 > result has to be > reported also stateing which type of SRD it is. The following sentence has been added to the SRD introduction paragraph: The output value of this metric=20 MUST indicate whether the output is for successful or failed session requests and SHOULD be stated in units of seconds. >=20 > --- >=20 > The output value of this metric is > numerical and SHOULD be adjusted to indicate seconds. > should be: >=20 > The output value of this metric is > numerical and SHOULD be reported in units of seconds.=20 >=20 > --- >=20 > Regards, > G. Q. "Chip" Maguire Jr. >=20 >=20 >=20 From marian.delkinov@ericsson.com Fri Feb 20 02:42:23 2009 Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DF028C15B for ; Fri, 20 Feb 2009 02:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7ffnDrSYn3q for ; Fri, 20 Feb 2009 02:42:22 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E742128C15A for ; Fri, 20 Feb 2009 02:42:21 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CF5E21CD4; Fri, 20 Feb 2009 11:42:35 +0100 (CET) X-AuditID: c1b4fb3e-af0c1bb000001315-fa-499e891a57fd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E0FAA21B18; Fri, 20 Feb 2009 11:42:34 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Feb 2009 11:42:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 11:42:33 +0100 Message-ID: <40D78CDB69283744A4B07581DDFDEB5501EC7DBC@esealmw106.eemea.ericsson.se> In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1B0DF@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Draft: SIP Performance Metrics-03 Thread-Index: AcmLtlWZPOXhD9n3TOSSKt3F+SngYQCUsoAgASfEgjA= References: <160DE07A1C4F8E4AA2715DEC577DA491B1B0DF@srvxchg3.cablelabs.com> From: "Marian Delkinov" To: "Daryl Malas" X-OriginalArrivalTime: 20 Feb 2009 10:42:34.0656 (UTC) FILETIME=[F0AC6200:01C99347] X-Brightmail-Tracker: AAAAAA== Cc: pmol@ietf.org Subject: Re: [PMOL] IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 10:42:23 -0000 =20 Daryl,=20 Sorry, for my perhaps delayed feedback! (I'm back after a long absence). I checked the new version (03) of the draft. All the texts that I had comments before are fine.=20 However, I found some changes in other texts, based on other people's comments, that I have to disagree with.=20 --- Chapter 3, page 5: As defined above, T1 is associated with the start of a request and also serves as the time-of-day stamp associated with a single specific measurement. The time offset [RFC2330] is the difference between T1 and a recognized primary source of time, such as UTC (offset =3D T1- UTC). Instead of using the term "time offset" above, I suggest "clock's offset". Thus the text will comply with the terminology used in RFC2330, chapter 10.1. --- Same page, the text: When measurement results will be correlated with other results or information using time-of-day stamps, then the time clock that supplies T1 SHOULD be synchronized to a primary time source, to minimize the error in the time offset. The time offset MUST be reported with each measurement. I fail to understand the sentence "to minimize the error in the time offset". There is no ERROR in the time offset, because the time offset IS the error. Moreover RFC2330 doesn't define such error, the draft doesn't define it either, so better avoid using it. I suggest keeping the text as in version-02, but using "clock's offset".=20 In addition, when correlating measurements, it's much more important all clocks used at the measurement sources to be synchronized to each other, rather than be synchronized to primary time source. Thus the relative offset should be minimized.=20 So the text should be: When measurement results will be correlated with other results or information using time-of-day stamps, then the time clock that supplies T1 SHOULD be synchronized to a primary time source, to minimize clock's offset. The clocks used at the different=20 measurement sources SHOULD be synchronized to each other, to minimize the relative offset (as defined in RFC2330). The=20 clock's offset and the relative offset MUST be reported with=20 each measurement. --- Respectively and for the same reasons, the following text: The accuracy of the T4-T1 interval is also critical to maintain and report. The difference in errors between the time offsets at T1 and T4 is associated with the clock's skew [RFC2330]. Should be kept as in version -02, but use the "clock's offset" term: The accuracy of the T4-T1 interval is also critical to maintain and report. The difference between clock's offsets at T1 and T4 is the error for the measurement and is associated with the clock's skew [RFC2330]. I'm OK with all other changes in version -03 compared to version -02. Best regards! Mario. >=20 > I am about to submit a new revision of the SIP Performance Metrics=20 > draft. I have attached the new revision and a diff. > Many of the changes you will see in this version are related to the=20 > source draft conversion to xml. I plan to submit the new revision in=20 > a few days. If you have any comments or feedback it is appreciated. >=20 > Regards, >=20 > Daryl >=20 >=20 > ---------------- > Daryl Malas > CableLabs > (o) +1 303 661 3302 > (f) +1 303 661 9199 > mailto:d.malas@cablelabs.com >=20 From D.Malas@cablelabs.com Tue Feb 24 10:51:53 2009 Return-Path: X-Original-To: pmol@core3.amsl.com Delivered-To: pmol@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A407F3A68A7 for ; Tue, 24 Feb 2009 10:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKfZIt4W8TXc for ; Tue, 24 Feb 2009 10:51:52 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A460A3A6B38 for ; Tue, 24 Feb 2009 10:51:52 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n1OIqA8K020101 for ; Tue, 24 Feb 2009 11:52:11 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 24 Feb 2009 11:52:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2009 11:52:11 -0700 Message-ID: <160DE07A1C4F8E4AA2715DEC577DA491B1B13B@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 Thread-Index: AcmLtlWZPOXhD9n3TOSSKt3F+SngYQCUsoAgASfEgjABAioUoA== From: "Daryl Malas" To: X-Approved: ondar Subject: [PMOL] FW: IETF Draft: SIP Performance Metrics-03 X-BeenThere: pmol@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Performance Metrics at Other Layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:51:53 -0000 Forwarding comments on behalf of Mario, because I never saw them hit the mailing list... ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com =20 > -----Original Message----- > From: Marian Delkinov [mailto:marian.delkinov@ericsson.com]=20 > Sent: Friday, February 20, 2009 3:43 AM > To: Daryl Malas > Cc: pmol@ietf.org > Subject: RE: IETF Draft: SIP Performance Metrics-03 >=20 > =20 > Daryl,=20 >=20 > Sorry, for my perhaps delayed feedback! (I'm back after a=20 > long absence). >=20 > I checked the new version (03) of the draft. All the texts=20 > that I had comments before are fine.=20 >=20 > However, I found some changes in other texts, based on other=20 > people's comments, that I have to disagree with.=20 >=20 > --- > Chapter 3, page 5: > As defined above, T1 is associated with the start of a request and > also serves as the time-of-day stamp associated with a single > specific measurement. The time offset [RFC2330] is the difference > between T1 and a recognized primary source of time, such as UTC > (offset =3D T1- UTC). >=20 > Instead of using the term "time offset" above, I suggest=20 > "clock's offset". Thus the text will comply with the=20 > terminology used in RFC2330, chapter 10.1. >=20 > --- > Same page, the text: > When measurement results will be correlated with other results or > information using time-of-day stamps, then the time clock that > supplies T1 SHOULD be synchronized to a primary time source, to > minimize the error in the time offset. The time offset MUST be > reported with each measurement. >=20 > I fail to understand the sentence "to minimize the error in=20 > the time offset". There is no ERROR in the time offset,=20 > because the time offset IS the error. Moreover RFC2330=20 > doesn't define such error, the draft doesn't define it=20 > either, so better avoid using it. I suggest keeping the text=20 > as in version-02, but using "clock's offset".=20 >=20 > In addition, when correlating measurements, it's much more=20 > important all clocks used at the measurement sources to be=20 > synchronized to each other, rather than be synchronized to=20 > primary time source. Thus the relative offset should be minimized.=20 >=20 > So the text should be: >=20 > When measurement results will be correlated with other results or > information using time-of-day stamps, then the time clock that > supplies T1 SHOULD be synchronized to a primary time source, to > minimize clock's offset. The clocks used at the different=20 > measurement sources SHOULD be synchronized to each other, to > minimize the relative offset (as defined in RFC2330). The=20 > clock's offset and the relative offset MUST be reported with=20 > each measurement. >=20 > --- > Respectively and for the same reasons, the following text: > The accuracy of the T4-T1 interval is also critical to maintain and > report. The difference in errors between the time offsets=20 > at T1 and > T4 is associated with the clock's skew [RFC2330]. >=20 > Should be kept as in version -02, but use the "clock's offset" term: >=20 > The accuracy of the T4-T1 interval is also critical to maintain and > report. The difference between clock's offsets at T1 and T4 is the > error for the measurement and is associated with the=20 > clock's skew [RFC2330]. >=20 >=20 > I'm OK with all other changes in version -03 compared to version -02. >=20 > Best regards! > Mario. >=20 >=20