Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt

Benjamin Kaduk <bkaduk@akamai.com> Mon, 02 December 2019 19:34 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFCF120045; Mon, 2 Dec 2019 11:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 01PvrHCgQGvL; Mon, 2 Dec 2019 11:34:03 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2B33312003F; Mon, 2 Dec 2019 11:34:02 -0800 (PST)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB2JQiY1012883; Mon, 2 Dec 2019 19:34:00 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=qcUETTB43O14McFZBgPJ3MAVzJAQeSzCzPK/lT0ML5g=; b=dgFgJZoiQ3acrZcAIncL1C/R88dDDoMBI2RUx76Rvk8qGR4+HHUyqrNUwJDUt76eCXiC cCbxfJV0KlUzMjHirOJXtTxWpLbqC6jT6N9ksjP2vJL5yjuHlnEhtStrJvph1xYjsVwB w+VZQewhEHnJvkxmPLeq4JLQM0BOzYAeNOxoPuACR5rF2F6AY+bX/vw9bH4gDfzGoi0f d9IoKE+ED/cJ3kw6IPLDSu4mpk4vwPOb8E2aXJA7Mk7W4ttZZiYRvY37cF4nWFqrdQyb KebV2bmDoOWu7KU0aUgMMf55wTYOtWGBnqbMTN170zYyi3Ljzn2cW/LWlvPu/mEE/6KM zA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wkvjrj2vn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Dec 2019 19:34:00 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xB2JWG4R022219; Mon, 2 Dec 2019 14:33:59 -0500
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2wkmmyb6et-1; Mon, 02 Dec 2019 14:33:58 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 132661FC95; Mon, 2 Dec 2019 19:33:32 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1ibrRq-0006Ne-Mz; Mon, 02 Dec 2019 11:33:30 -0800
Date: Mon, 2 Dec 2019 11:33:30 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Dave Lawrence <tale@dd.org>, dnsop@ietf.org, gen-art@ietf.org
Message-ID: <20191202193329.GK3397@akamai.com>
References: <157194421575.11362.4964821589228085335@ietfa.amsl.com> <23985.64786.138127.971733@gro.dd.org> <ec55975c-3250-dc87-5cb8-c82164368d36@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ec55975c-3250-dc87-5cb8-c82164368d36@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-12-02_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1912020166
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-02_04:2019-11-29,2019-12-02 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 clxscore=1011 mlxscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912020165
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/rbmPH98e9lE-zPOnlKOCFk9dfoQ>
Subject: Re: [Gen-art] [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-09.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2019 19:34:06 -0000

Hi Brian,

I agree that this updated text provides more clarity about why the
change is being made, but I am not sure that it fully addresses all of
the concerns you raised, and would appreciate your thoughts.

Specifically, you had raised the possibility of existing, fielded,
implementations that would behave poorly when presented with input that
has the sign bit set.  The DNS-OARC data that indicates such packets have
not been seen in the wild serves only to amplify this uncertainty, since
we have no reason to believe that such a codepath would have been triggered
already and diagnosed.  Isn't there still some latent risk of such
fielded implementations that would be incompatible with this change if it
ever did show up on the wire?

Thanks,

Ben

On Fri, Oct 25, 2019 at 11:23:42AM +1300, Brian E Carpenter wrote:
> Hi Dave,
> 
> Thanks. I think that covers it. I still suspect that the original reason
> was concern about int versus uint confusion, but the new text is fine.
> 
> Regards
>    Brian Carpenter
> 
> On 25-Oct-19 08:35, Dave Lawrence wrote:
> > internet-drafts@ietf.org writes:
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-serve-stale-09
> > 
> > This revision addressed the one remaining outstanding issue that Brian
> > Carpenter raised in the Gen-ART Last Call Review.  The following text
> > was added to explain why a TTL with the high-order bit set is now
> > handles as a large positive number (then capped down) rather than a
> > negative number (and treated as zero).
> > 
> >     As for the change to treat a TTL with the high-order bit set as
> >     positive and then clamping it, as opposed to [RFC2181] treating it as
> >     zero, the rationale here is basically one of engineering simplicity
> >     versus an inconsequential operational history.  Negative TTLs had no
> >     rational intentional meaning that wouldn't have been satisfied by just
> >     sending 0 instead, and similarly there was realistically no practical
> >     purpose for sending TTLs of 2^25 seconds (1 year) or more.  There's
> >     also no record of TTLs in the wild having the most significant bit set
> >     in DNS-OARC's "Day in the Life" samples.  With no apparent reason for
> >     operators to use them intentionally, that leaves either errors or
> >     non-standard experiments as explanations as to why such TTLs might be
> >     encountered, with neither providing an obviously compelling reason as
> >     to why having the leading bit set should be treated differently from
> >     having any of the next eleven bits set and then capped per Section 4.
> > 
> > I also removed the phrasing about 2181's handling of this issue as a
> > "curious suggestion".  I recognize it could have an unintended
> > negative connotation against the original authors, though when I wrote
> > the sentence originally I meant it only with its neutral denotation.
> > It was curious to me only because no rationale was provided as to why
> > that particular choice had been made, despite the current assertion
> > that it was obvious as to why.
> > 
> > 
>