IETF Logo Mail Archive

Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

Ted Lemon <mellon@fugue.com> Thu, 11 July 2019 23:31 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14DF120182 for <dnssd@ietfa.amsl.com>; Thu, 11 Jul 2019 16:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.603
X-Spam-Level:
X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 k9ADWkdhHG6f for <dnssd@ietfa.amsl.com>; Thu, 11 Jul 2019 16:31:54 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 10E7E12016B for <dnssd@ietf.org>; Thu, 11 Jul 2019 16:31:53 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id m14so5060230qka.10 for <dnssd@ietf.org>; Thu, 11 Jul 2019 16:31:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EnOEV60aYGQPgoapxQ7F5YGZ9++ecAShHEhHGWxceVY=; b=k5Av0fF97dTEqPUtCObNvFSq7Ff20dq3VQT59NAjIN3LnlEx2bF7umaa89UVuJnPBd 9UJH6IonzYHSzGmk9uGBE1N4soDmxOdA98kaBYb9tfWZCNRmdTz5QQvqYRvpBqr/BzvV cDLQ4vN5iHaqAeC0/zQ4DN7uOt5hi8jsp6Y/0hxpESsvCKuHfPzmoWi0Wh/OKqaTscVD 6yIUbBH+bttL5Ccjqnt1uPY7iK6fkLDr/81EuoIjU2gd0ioLNnJmmwTvXBL2ycNffeCk FoXiaaQgFzp2COI3zzqxwA3Ffllkzwk0MBCFPFg75Cgv8xH+tcTM+t7ho9g9RsJ1UKaO cNYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EnOEV60aYGQPgoapxQ7F5YGZ9++ecAShHEhHGWxceVY=; b=bQpjNkzyN79a4jAXStzSGKuGR9QIHs2M6NEQ55iiSXb8jV2QqSFhWbMJ3Q4rUBjJBh +/1Ebs70d6t0AvN1u/jnhLh8IC46aeaRtqwBppkFhdebV9mZwul5W7RwVDpjBZ3z3MGG jSmAxrr5CJHY1dj05RwOMd4uiXvWzhwIa7lRM3vK1vKBdriZHX/g2aBIRAEqOnEdNQht QL4dLXXMdKmoLn0/5pUoHHH/bGJsN1h8t6UWT8nm0HhNo3IdLInL6wGUR7RfKCaV82ef xsk6IEe8LvR07m/paJ/nnOH8SNDOz18S2XW71oZcR7hMxyi57F/7HLxbDxZyyQ2Zjoln Y3Cg==
X-Gm-Message-State: APjAAAXpR1IvKMz+5LFhFPsFzx3f0tWz2y1JZjksa35zc/QbLc+W9m0f i8+TSrhcGbAMgIsbl+pRPFyRMw==
X-Google-Smtp-Source: APXvYqzM4bAIwKELVP9isgS841AP+oB4lTXOHrEWtoeUxGyP1GJwpQmBkBvHUaKYcg/XPSLnvj1ClA==
X-Received: by 2002:a37:d95:: with SMTP id 143mr3884849qkn.132.1562887912097; Thu, 11 Jul 2019 16:31:52 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by smtp.gmail.com with ESMTPSA id v28sm2646201qkj.11.2019.07.11.16.31.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 16:31:51 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <60198834-66F0-4CF0-BB09-B987684F3616@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8F54A151-5562-45D6-BB4E-A5DADED5F4AE"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 11 Jul 2019 19:31:49 -0400
In-Reply-To: <FC48248A-51E9-421A-8C91-B4DD41C9FC2F@bangj.com>
Cc: Stuart Cheshire <cheshire=40apple.com@dmarc.ietf.org>, Eric Rescorla <ekr@rtfm.com>, DNSSD <dnssd@ietf.org>, draft-ietf-dnssd-push.all@ietf.org, David Schinazi <dschinazi.ietf@gmail.com>, Robert Sparks <rjsparks@nostrum.com>
To: Tom Pusateri <pusateri@bangj.com>
References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <CAPDSy+7om=cBW51cyuPea9nabgJuRV3M+++gA7sy8VzfNpkn6Q@mail.gmail.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <CAPDSy+6V+ooWDe7XezmWA_XKNQXRAOex8DE5CiTnZdz8zc-9CA@mail.gmail.com> <F6DD5CEF-E644-46E3-84B5-18309F6B44C5@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <BF75518F-25E9-4283-B647-6382F50A5CCA@bangj.com> <ED99C670-3149-417C-B465-99A48D70C584@bangj.com> <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> <FC48248A-51E9-421A-8C91-B4DD41C9FC2F@bangj.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/n6YMFN_mL5_jLBu-ii2EyIthA0Y>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2019 23:31:56 -0000

On Jul 11, 2019, at 7:03 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> The SERVER may want to conserve resources from broken clients. The RETRY DELAY is for the SERVER’s protection and it’s thoughtfully informing the CLIENT how long it has to wait before the SERVER will accept a connection from it. It doesn’t matter if the CLIENT agrees or not or whether the CLIENT follows the spec or not.

Okay, so we have the following scenarios:

1. Server sends RETRY-DELAY, client honors it.   Result: client goes away for a long time and does polling instead of push.  Behavior on client is not great, but probably won’t be noticed by a typical end-user other than as an inexplicable inconvenience.   Vendor will have no strong motivation to fix.
2. Server sends RETRY-DELAY, client ignores it.  Result: whatever broken behavior the client exhibits, up to and including back-to-back reconnects.  UX may degrade substantially: in particular, this will affect battery life for mobile devices.  Practically speaking, in this case the vendor will be motivated to fix.
3. Server sends RST.   Result: same as 2.

So the question is, do we want outcome (1) or outcome (2)?

v2.23.0 | Report a Bug | By Email