Re: [core] πŸ”” WGLC for Resource Directory

Peter van der Stok <stokcons@bbhmail.nl> Fri, 24 May 2019 09:24 UTC

Return-Path: <stokcons@bbhmail.nl>
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 45C841200E0 for <core@ietfa.amsl.com>; Fri, 24 May 2019 02:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl
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 kjRoIX4ifDCt for <core@ietfa.amsl.com>; Fri, 24 May 2019 02:24:39 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B5712009C for <core@ietf.org>; Fri, 24 May 2019 02:24:38 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id ABB99837F24D; Fri, 24 May 2019 09:24:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=9pqpaceYUWcVwCimGQ v5JlXWaTUux/eNl3sAhVp3rOQ=; b=qF0Lz/+nmIU9iXs+fku/bzfyLe8N11zyJU tbpkBOp6GMMO1N2K9O6RWu2B9kodEFn/4ZLySpsRLyr/KsD9vC3EbTKUdHkFwaBj HA3O+8GddTFDQynBasczinWK6bQmv8GGsm8nZeehzdu9yKdAUpqPuZ+3fDTEvdFS 0fhkBtZfY=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379:421:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2527:2528:2553:2557:2559:2562:2693:3138:3139:3140:3141:3142:3353:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4117:4250:4321:4362:4470:5007:6117:6119:6261:6298:6657:6659:6678:7875:7903:8603:8957:9036:9177:10004:10400:10848:11232:11658:11914:11984:12043:12114:12555:12663:12740:12895:12986:13071:13137:13139:13146:13150:13161:13229:13230:13231:13255:13439:14039:14040:14093:14096:14180:14181:14721:21060:21080:21433:21451:21625:21740:21795:21810:30003:30054:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:27, LUA_SUMMARY:none
X-HE-Tag: knee26_7faa737f6de4d
X-Filterd-Recvd-Size: 6580
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf06.hostedemail.com (Postfix) with ESMTPA; Fri, 24 May 2019 09:24:37 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_262b012a03669233e645905c7b4bbbf2"
Date: Fri, 24 May 2019 11:24:36 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Ted Lemon <mellon@fugue.com>
Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire <cheshire@apple.com>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com>
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> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com>
Message-ID: <a97554a90cfd49ce21fb59e43ff0ed63@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [86.203.245.197]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/nvvyOKVeS2alZOgZNpl4EY5RFDQ>
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: Fri, 24 May 2019 09:24:41 -0000

Hi Ted,

thanks for the feedback. 

I was thinking of the following recommendations (based on my background
and experience) for the RD discovery.
Given the large range of deployment conditions, the use of conditional
recommendations seemed appropriate.

In managed networks which are (often) not connected to a border router,
the use of a preconfigured address is recommended. 
In managed networks with border routers that need stand-alone-operation,
the RDA0 option recommended.
The use of multicast discovery in mesh networks is NOT recommended. The
use of DNS facilities is described in draft-ietf-core-rd-dns-sd.

Comments on these recommendations will be appreciated.

Peter
Ted Lemon schreef op 2019-05-23 15:27:

> 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.