From nobody Thu Jan 24 12:20:37 2019 Return-Path: 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 70918126DBF for ; Thu, 24 Jan 2019 12:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 fnzlRVCLb0TT for ; Thu, 24 Jan 2019 12:20:33 -0800 (PST) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1AB123FFD for ; Thu, 24 Jan 2019 12:20:33 -0800 (PST) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 8F2EF24F68 for ; Thu, 24 Jan 2019 15:20:31 -0500 (EST) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <8AB7CD9B-E9A4-42B3-AED0-2A8E8E1D3FA8@bangj.com> Date: Thu, 24 Jan 2019 15:20:30 -0500 To: dnssd X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [dnssd] feedback on draft-sekar-dns-ul-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 20:20:35 -0000 Since this is an individual contribution yet it is related to work going = on here, I=E2=80=99m sending this to the WG. I expect this draft to get = adopted by the working group in the future if this work continues. This version of Update Leases adds a new field to the UPDATE-LEASE = option that provides a KEY lease in seconds. The length of the OPT is = either 4 or 8 depending on if the KEY-LEASE is present. While I understand the need to solve a specific problem, I don=E2=80=99t = think this format is general enough for future extensions. While the = authors may not believe there is a need for future extensions, the = addition of the KEY-LEASE is a counter example. Therefore, I think some = method of determining which extra options are included is needed. If a = future extension adds a new field but the KEY-LEASE is not included, it = will be difficult to tell how to interpret the OPT value. In this case, = a new OPT code will be needed. It is certainly possible to get a new OPT = value in the future should a new extension arise but it seems wasteful = to not just handle a slightly more general case at the time of writing. Thanks, Tom= From nobody Thu Jan 24 14:47:33 2019 Return-Path: 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 6A2B31311F3 for ; Thu, 24 Jan 2019 14:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 0u-7Csq7dHT6 for ; Thu, 24 Jan 2019 14:47:29 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 C44891311DE for ; Thu, 24 Jan 2019 14:47:28 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id n32so8654145qte.11 for ; Thu, 24 Jan 2019 14:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hw9869lLGI4yDDcwf+VBC438GlpFN9vShJM/urLxKMU=; b=xVvsz0wJuE3i6h7IW7v6oqzgsoVGlfTHJNxdKMta1LkEPx4OS/zkUJcpVFpGlP17V/ 1ItwECSKA1XJ1QXEQG5OqZewOzcTTnkfhhTER4FvKPhT6UWEwiQhcJADBgRU9WyGGhO7 3+LZ0Hak+tZtTPIPIdDkHKs5YUUneHowdYg1ds/A10wUOyRvySxoOxUytmPX+Rx2x7f3 d3MjRKsFeRQeM3C1mtjl4B7Ss+UiAvOcf+TJn+oU7K3SSgarML2dxtzbo+60PdJcemOr P3oCR5TjxJIUXQXAu/pmU9TXBL6xCHJal+t8hljU4NTfI3Y4EGvDIjEaKk3VxWm5M0Tx vWGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hw9869lLGI4yDDcwf+VBC438GlpFN9vShJM/urLxKMU=; b=GT3yhaTa6vvMy0SZSdfUo6lTwdPnWT6ylyZkNkvXcBf398aWz+wKbxfWQnjcaCeCtc dxIx7AIf5OdbRBlQOISrKj/anjNm3N2erFwxs8EbW7hQ1Qg9dqsJW4YsfH83yUdwJ7z7 Gu5rXs7386E7c+kMOV0M82JAxSbisP//4t/oSqgvc/8CIV5hHD0YtxwJQgHV8z+K6SLo KiI46ZOM1Hc/7g4h03Urv2Nb/Vpz6rhqZCEKmWbZanPDgQfeJbswlaVJzNhWf7dIQaoO Ibazft5IWFtRx5k8cS01Ig5c+IQ5D85vJGsQ/4Fmyf/4g/WaynTlMzpM/ZwoNHfDr1QZ iB4g== X-Gm-Message-State: AJcUuke5zYactejMe24bKuMAbGL40khL8q/3D1K8onjkRMIeo7mOBumP cUzoq5cJqLqZzC/sjk8rMYAwAX+hnuaZ5mvdAmeX5a+/ X-Google-Smtp-Source: ALg8bN6b6ZRIt7/yQmzOgVfALAPjhMZLbtQp91IjLk0OEHVnSq/FgfxGqqheWWQIFEyVuCMiWvq7e6ZlpuUxKOfWwGw= X-Received: by 2002:a0c:b527:: with SMTP id d39mr7985706qve.201.1548370047713; Thu, 24 Jan 2019 14:47:27 -0800 (PST) MIME-Version: 1.0 References: <8AB7CD9B-E9A4-42B3-AED0-2A8E8E1D3FA8@bangj.com> In-Reply-To: <8AB7CD9B-E9A4-42B3-AED0-2A8E8E1D3FA8@bangj.com> From: Ted Lemon Date: Thu, 24 Jan 2019 17:46:52 -0500 Message-ID: To: Tom Pusateri Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000acdd0005803bfeb4" Archived-At: Subject: Re: [dnssd] feedback on draft-sekar-dns-ul-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 22:47:32 -0000 --000000000000acdd0005803bfeb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The reason the KEY-LEASE value is included in this option is that we know now that we need it; the 4-byte version of the option is for backwards compatibility. If, in the future, we need more information, the solution is to add another OPT RR option, not to extend this one. Personally my preference would be to make this 8 bytes all the time, and not have the option of only sending 4 bytes. If we were concerned at that time about wasting space in the packet, the new OPT RR option could subsume the values included in this option. But I really don't think that's going to be an issue. On Thu, Jan 24, 2019 at 3:20 PM Tom Pusateri wrote: > Since this is an individual contribution yet it is related to work going > on here, I=E2=80=99m sending this to the WG. I expect this draft to get a= dopted by > the working group in the future if this work continues. > > This version of Update Leases adds a new field to the UPDATE-LEASE option > that provides a KEY lease in seconds. The length of the OPT is either 4 o= r > 8 depending on if the KEY-LEASE is present. > > While I understand the need to solve a specific problem, I don=E2=80=99t = think > this format is general enough for future extensions. While the authors ma= y > not believe there is a need for future extensions, the addition of the > KEY-LEASE is a counter example. Therefore, I think some method of > determining which extra options are included is needed. If a future > extension adds a new field but the KEY-LEASE is not included, it will be > difficult to tell how to interpret the OPT value. In this case, a new OPT > code will be needed. It is certainly possible to get a new OPT value in t= he > future should a new extension arise but it seems wasteful to not just > handle a slightly more general case at the time of writing. > > Thanks, > Tom > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --000000000000acdd0005803bfeb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The reason the KEY-LEASE value is included in this option = is that we know now that we need it; the 4-byte version of the option is fo= r backwards compatibility.=C2=A0 =C2=A0If, in the future, we need more info= rmation, the solution is to add another OPT RR option, not to extend this o= ne.=C2=A0 =C2=A0Personally my preference would be to make this 8 bytes all = the time, and not have the option of only sending 4 bytes.=C2=A0 =C2=A0If w= e were concerned at that time about wasting space in the packet, the new OP= T RR option could subsume the values included in this option.=C2=A0 =C2=A0B= ut I really don't think that's going to be an issue.

On Thu, Jan 24,= 2019 at 3:20 PM Tom Pusateri <pus= ateri@bangj.com> wrote:
Since this is an individual contribution yet it is related t= o work going on here, I=E2=80=99m sending this to the WG. I expect this dra= ft to get adopted by the working group in the future if this work continues= .

This version of Update Leases adds a new field to the UPDATE-LEASE option t= hat provides a KEY lease in seconds. The length of the OPT is either 4 or 8= depending on if the KEY-LEASE is present.

While I understand the need to solve a specific problem, I don=E2=80=99t th= ink this format is general enough for future extensions. While the authors = may not believe there is a need for future extensions, the addition of the = KEY-LEASE is a counter example. Therefore, I think some method of determini= ng which extra options are included is needed. If a future extension adds a= new field but the KEY-LEASE is not included, it will be difficult to tell = how to interpret the OPT value. In this case, a new OPT code will be needed= . It is certainly possible to get a new OPT value in the future should a ne= w extension arise but it seems wasteful to not just handle a slightly more = general case at the time of writing.

Thanks,
Tom
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000acdd0005803bfeb4--