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

Varun Singh <> Thu, 19 May 2016 00:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF6B512D11C for <>; Wed, 18 May 2016 17:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BeUfNfQ5qhNN for <>; Wed, 18 May 2016 17:50:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1EED812D105 for <>; Wed, 18 May 2016 17:50:09 -0700 (PDT)
Received: by with SMTP id m64so26723619lfd.1 for <>; Wed, 18 May 2016 17:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OgvCHZd7KuYgAUCoVkpSxbglPuhe5B1fFrpH7LpVMgE=; b=GvIsVitw5XN2CjqBq0jLwRjtWuwA0UUHslZcbs6y4JigwYEVw75OeYUr3y0nBq/XG0 /kAg9TZhtQQViHMGWkBIAlZs3wWNZ3nuDEKPyW0rcpRpjo+eLlASfEQQjGU5g12r4jO2 EOyd9sr+5f4qXkYrieYqDbyGdp5sjuU6iI0ipGteTQo882DsCerjmUH+hZfbgBn81vb+ lV0135tWfJHyurNYE+YBwbtB1L0BcyfrjXAxOIPom0YELiSs1xfMeGhPwpayJZTYZCmh oREpKKblVUrmvweysbeKPYRrKVL8h5PLMbSJjomUK8dDawbhmiCkrQowH88ZaagwlBui OXHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OgvCHZd7KuYgAUCoVkpSxbglPuhe5B1fFrpH7LpVMgE=; b=BwtuGboBu346oE1YKPfL0bUkZyGM6gKwiXW/v8yr75DCk3yO/sXx4nTyiprF36V/YC MXpCmBk9ut+RMZ0rvcudv1MsPbIxgZJwFhE9yesvG+FZaOwBVUD4ZjE+lxhRfUMhZS/o QF+em1XAcDMcIjrsZV0S9wJmUxG1xUrpc56BtATUF2ur/u79XCuDk1DwG1zuUpfPtTqw DSlsNbz0Pwy98o4EDXDnYXo1rlcNAJIERRq2wF76BP9PJdlgru1q4obPB5I1uPC7GepW XpbbDy+6TmwUVmcY7L1/jpEqcObWOiz378A2M9g+Wr6lZeChmRfmRq8Vk+n68ZaMXAjZ dUNg==
X-Gm-Message-State: AOPr4FVVy5UbvVRuP5eK+6/wlcYhOmD3ang+9HrjsnNX2zeN/SP6X4Vhpt6a+SHw1sL942o2Arrm4Ke1sjzM2g==
X-Received: by with SMTP id 89mr3102031lfv.58.1463619007013; Wed, 18 May 2016 17:50:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 May 2016 17:49:47 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Varun Singh <>
Date: Thu, 19 May 2016 03:49:47 +0300
Message-ID: <>
To: Alissa Cooper <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: xrblock <>
Subject: Re: [xrblock] AD evaluation: draft-ietf-xrblock-independent-burst-gap-discard-01
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 May 2016 00:50:11 -0000

Hi Alissa,

Thank you for the review. My comments are inline.

On Tue, May 17, 2016 at 8:26 PM, Alissa Cooper <> wrote:
> 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?

I believe this might have been carried through from RFC7003, which has
the same text.

However, adding the considerations from RFC6958 + RFC7003 is more
appropriate here.
I will send a proposal before the end of next week.

> There are also a few nits that should be resolved together with any last
> call comments:
> = 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.

Keeping the definitions here would avoid confusion of reading two
specs to implement this.
Although, I do not feel strongly about this.

Will fix the other nits.