IETF Logo Mail Archive

Re: [core] 🔔 WGLC for Resource Directory

Ted Lemon <mellon@fugue.com> Thu, 23 May 2019 13:27 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913211200B3 for <core@ietfa.amsl.com>; Thu, 23 May 2019 06:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 PQPepdSQBst2 for <core@ietfa.amsl.com>; Thu, 23 May 2019 06:27:19 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 8E9AD120048 for <core@ietf.org>; Thu, 23 May 2019 06:27:19 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id z19so3808194qtz.13 for <core@ietf.org>; Thu, 23 May 2019 06:27:19 -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=gipmwGQ1ua/zBBu+zku0MfiKNEfEmU/FnOvu0L6gR1c=; b=sO5UXvYuLuUdEUz6yZRNKuix7Q+LD8PkKP/5qH0GuC3tbtMe3zAJh6PDYdliw8etO0 OtZwSXQZSxDqIJi/68QQO7CJ5laIzdqGDjM03Kpg5zhkUaU2K+AA8m4X79gyKuxseoeK OTfsXRyaHySAAhhzfISmneUtG3Eha8Z4I0JEV4jsGpWu4LAJFOszi6j10v9x2wu4tEfm BKL//P0mHZq6Jv8H396YNwNgIZ/aMUk+GgUJSMvk/2XWRZ+Wjm30HftXke/lOTXmzRI4 eVV10kYRJWmzvPpbTdDyzGJ9lQqN8Ck7xktlTzpy9Aun33M/qSR9rm45Le6/Dii5oDtP kMbA==
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=gipmwGQ1ua/zBBu+zku0MfiKNEfEmU/FnOvu0L6gR1c=; b=ZYa5twb/wId7AUQaBMEvIoRIohCBU3iL5bzNKcqKYuarlNi5oNQmqhSar4Bxepo5UZ 5oxSoNfxHUDJbczYxN5tBtl+lh5f/5m6d2Kd2cCJpsCDoj4bSyleEiN7W50W5j7MAbIZ A8OhzNmpxD9Gi40xlpkAXEWhA9ak3SWNJUVokXVJfajjxRi824Wgay8XRby4SMLmppLi v9thQRcBa8sY3d+tahztJIs6iUuBqPE6iBEhfQ+zX6Y9eNRXkHoDfx/g7/WBPbT63J5q 5gDFwqyMZ0l8kcbasuJiW3QDaLMrnmx0iOjIx/kahIb9ZnPLqx7Ru4gbhCJGWOj3WUPV 33zw==
X-Gm-Message-State: APjAAAWjxmbmji6I5VWZumj53It08m99blQ+xaC1Wu4LAZg/RInTGMhB P1azR4ULIunaRBzNEQNDrO457Q==
X-Google-Smtp-Source: APXvYqwUWokxmtvCc/Z4azbs9/nSYmSk7mgcy2ThjDOgDyEklbFggr3lKHFR928ZjPbJ/2wmOrvH2A==
X-Received: by 2002:ac8:2ca5:: with SMTP id 34mr153468qtw.246.1558618038465; Thu, 23 May 2019 06:27:18 -0700 (PDT)
Received: from [10.0.30.16] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id d30sm13366923qtc.93.2019.05.23.06.27.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 06:27:17 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8CDC1789-D0E3-4AB0-8DEB-29EFC01FF63D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Thu, 23 May 2019 09:27:14 -0400
In-Reply-To: <498bff27c1804f08365f0e11e6d24050@bbhmail.nl>
Cc: core@ietf.org, Stuart Cheshire <cheshire@apple.com>
To: consultancy@vanderstok.org
References: <AM5PR0701MB230754CF5CD643B6B7DC1A7697420@AM5PR0701MB2307.eurprd07.prod.outlook.com> <EBFF17D7-86DF-4C3E-B69E-EF69206A6D17@fugue.com> <02585a832a91742de93f6d311259ae61@bbhmail.nl> <CF34C053-A417-4914-BB28-B4E47E97A625@fugue.com> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/pIRhmMFgQz4HnjZGnWgZKlISxko>
Subject: Re: [core] 🔔 WGLC for Resource Directory
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 13:27:21 -0000

On May 23, 2019, at 3:08 AM, Peter van der Stok <stokcons@bbhmail.nl> wrote:
> If so, should I mention in the text that a selection of supported discovery methods for a given RD configuration may be specified by a SDO?

If that is what you intend to have happen, then yes, you should say that explicitly.   You might also explicitly discuss the problems with doing that:
Increased complexity of deployments
Lack of interoperability
Likelihood of infrastructure (as opposed to leaf) devices not actually supporting all the possible discovery methods

I suspect the reason we’re having this conversation is that we don’t yet know what to recommend, and that’s understandable.   But the reason I’m pushing the point is because at some point it would be of great benefit to the end-user to be able to say what to do.   Leaving it up to each app-layer vendor is not a good solution.   So if this document is not going to say what to do, we should at least be thinking in terms of discovering what we should recommend, and not simply decide that we are not going to solve that problem.

v2.23.0 | Report a Bug | By Email