IETF Logo Mail Archive

Re: [xrblock] AD evaluation: draft-ietf-xrblock-independent-burst-gap-discard-01

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 18 May 2016 11:49 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BA812D0EA for <xrblock@ietfa.amsl.com>; Wed, 18 May 2016 04:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.345
X-Spam-Level:
X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 jGn9uiyRm5gQ for <xrblock@ietfa.amsl.com>; Wed, 18 May 2016 04:49:52 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 EAB9E12D107 for <xrblock@ietf.org>; Wed, 18 May 2016 04:49:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2BBAgABVjxX/yYyC4ddHAGCTyEqVX4GuW0BDYF1hhECHIEiOBQBAQEBAQEBZSeEQgEBAQEDEhEKXAIBCA0EBAEBCx0DAgICMBQJCAIEARIIGogNAaYbilCRTQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJoRMhEE0gkorgi4FmCsBl3aFQ49JHgEBQoI4gTVuhwcBfgEBAQ
X-IPAS-Result: A2BBAgABVjxX/yYyC4ddHAGCTyEqVX4GuW0BDYF1hhECHIEiOBQBAQEBAQEBZSeEQgEBAQEDEhEKXAIBCA0EBAEBCx0DAgICMBQJCAIEARIIGogNAaYbilCRTQEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJoRMhEE0gkorgi4FmCsBl3aFQ49JHgEBQoI4gTVuhwcBfgEBAQ
X-IronPort-AV: E=Sophos;i="5.26,328,1459828800"; d="scan'208,217";a="175659679"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 May 2016 07:49:49 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 18 May 2016 07:49:49 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 18 May 2016 13:49:47 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Alissa Cooper <alissa@cooperw.in>, xrblock <xrblock@ietf.org>
Thread-Topic: [xrblock] AD evaluation: draft-ietf-xrblock-independent-burst-gap-discard-01
Thread-Index: AQHRsGFn21fpIIbSKUqs2zxvN74CLJ++lUoA
Date: Wed, 18 May 2016 11:49:47 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA751E6C8C@AZ-FFEXMB04.global.avaya.com>
References: <78605AD7-F16C-47F0-AD97-334A4E7B7E70@cooperw.in>
In-Reply-To: <78605AD7-F16C-47F0-AD97-334A4E7B7E70@cooperw.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.48]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA751E6C8CAZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/xrblock/0gO7sgo52t-jn1ZNnmfHcyqCSEk>
Subject: Re: [xrblock] AD evaluation: draft-ietf-xrblock-independent-burst-gap-discard-01
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2016 11:49:56 -0000

Thanks, Alissa, for the AD review.

I agree that the Security Considerations need to be aligned with the respective sections of RFC 6958 and RFC 7002 respectively.

On terminology – I would rather keep the section verbose as it is now. We discussed this in the past  and reached the conclusion that it’s preferable to not create (more) dependencies between the different metrics documents.

Regards,

Dan


From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Alissa Cooper
Sent: Tuesday, May 17, 2016 8:27 PM
To: xrblock
Subject: [xrblock] AD evaluation: draft-ietf-xrblock-independent-burst-gap-discard-01

I have reviewed this document in preparation for IETF last call. Overall it looks good. I have just one question I’d like to discuss before issuing the LC.

Both RFC 6958 and RFC 7002 mention security considerations that are not mentioned in this document. But it seems like similar considerations apply to this block. Why are these not discussed in Section 7?

There are also a few nits that should be resolved together with any last call comments:

= Section 1.1 =

s/the method used to distinguish between bursts and gaps shall use/the method used to distinguish between bursts and gaps uses/

= Section 2 =

In retrospect it would have been nice to have all of these terms defined once in one document that the other documents could have referred to. Not sure it makes sense to change course now, although it seems you could just refer to the definitions in RFC 7003 rather than repeating them here.

= Section 4 =

s/the burst and gap duration shall be determined as if/the burst and gap duration is determined as if/


= Section 6.3 =


s/art-ads@tools.ietf.org<mailto:art-ads@tools.ietf.org>/art-ads@ietf.org/

v2.23.0 | Report a Bug | By Email