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

Peter van der Stok <stokcons@bbhmail.nl> Mon, 27 May 2019 07:31 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 12F5C1200E9 for <core@ietfa.amsl.com>; Mon, 27 May 2019 00:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, SPF_HELO_NONE=0.001, SPF_NONE=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 7Y3BehSkL6On for <core@ietfa.amsl.com>; Mon, 27 May 2019 00:31:36 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6606120099 for <core@ietf.org>; Mon, 27 May 2019 00:31:36 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 4B74B180A812A; Mon, 27 May 2019 07:31:35 +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=XIxdoTS8uT4vT3fXI1 MfdpV4J3MyC1YIFJzB7k6VwdY=; b=cdng4JKlY9d70Md9oZ70tlHCPVsgks2fF5 uM+MRL/8PiDtvqgTqtsicHUT8yD8UL2p8APcPCfBEsS9fQw4bpfN4yWLkPGs+ov3 CATIvJ9IfuTMGkuxuhlCS8yDSGder/3F0a0hSjEcij+ySPgYzGdNAAq/igkUBFBI 1cI5mbquU=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379: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:1544:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2527:2528:2553:2557:2559:2562:2900:2902:2912:3138:3139:3140:3141:3142:3354:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4119:4250:4321:5007:6117:6119:6261:6298:6657:6678:7875:7903:8603:9036:9177:10004:10226:10848:11232:11657:11658:11914:11984:12043:12050:12114:12555:12740:12895:12986:13139:13161:13229:13255:13439:14093:14096:14180:14181:14721:21060:21063:21080:21433:21451:21625:21740:21810:30003:30030:30054:30070: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:25, LUA_SUMMARY:none
X-HE-Tag: knee85_2ae5459d9ca0b
X-Filterd-Recvd-Size: 8800
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Mon, 27 May 2019 07:31:34 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_8b985c6dc90bc80c6de7f1a77b7de365"
Date: Mon, 27 May 2019 09:31:34 +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: <33B4FD70-E650-47E4-A603-BD4928E4C47F@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> <a97554a90cfd49ce21fb59e43ff0ed63@bbhmail.nl> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com>
Message-ID: <f7fe549e40f879c6f46a0a7d8242241a@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/ujyfxuq8hA-imvGdpitvap7KIJM>
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: Mon, 27 May 2019 07:31:39 -0000

Hi Ted,

The use cases for networks without border router are;
A mesh network configured on a gletcher in the Alps to measure the ice
movements.
A mesh network dropped from a plane over a forest.
A mesh network in a building under construction not connected to any
outside service.

For example, in those cases a border router is present once a month for
a few hours to read out data.

No RDA0 option,  avoid multicast, no host names. Therefore, the
configured RD IP address seems reasonable. 

Peter
Ted Lemon schreef op 2019-05-24 15:11:

> On May 24, 2019, at 5:24 AM, Peter van der Stok <stokcons@bbhmail.nl> wrote: 
> 
>> In managed networks which are (often) not connected to a border router, the use of a preconfigured address is recommended.
> 
> I can't think of a time when this would be the right recommendation.   Just because there is no border router doesn't mean that there isn't a service discovery mechanism.   If you have something on the network providing core RD service, then you have a "server," and that "server" should also be able to provice service discovery.   DNS-SD is actually a pretty easy way to do this--presumably you're already configuring a DNS server in RA or DHCP, and if not it's easy to do, and you don't need to write any new specifications.   The server can be very lightweight. 
> 
> If manual configuration is indicated, then what should be configured is the hostname of the RD server, not the IP address, which is simply too likely to change.   This avoids the risk that you would have to go out and manually reconfigure every device on the network when you change your network configuration.  
> 
> But really, the RDA0 works just fine in this case, and that's what I'd recommend if I were writing the document, unless you are thinking that on a network of this type, hosts are just communicating using link-local addresses.   If they are using mesh-local addresses, then whatever mechanism configures mesh-local addressing should also be able to convey the RD IP address. 
> 
>> In managed networks with border routers that need stand-alone-operation, the RDA0 option recommended.
> 
> Sure. 
> 
>> 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.
> 
> Yup.