Re: [Snac] I-D Action: draft-ietf-snac-simple-00.txt

Ted Lemon <mellon@fugue.com> Tue, 21 February 2023 13:26 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: snac@ietfa.amsl.com
Delivered-To: snac@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553C2C1524AC for <snac@ietfa.amsl.com>; Tue, 21 Feb 2023 05:26:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3-55jCKqGzV for <snac@ietfa.amsl.com>; Tue, 21 Feb 2023 05:26:11 -0800 (PST)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCB3C1524AA for <snac@ietf.org>; Tue, 21 Feb 2023 05:26:11 -0800 (PST)
Received: by mail-qk1-x72f.google.com with SMTP id f20so659731qka.7 for <snac@ietf.org>; Tue, 21 Feb 2023 05:26:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XN/cuKN9Qg/rT31/tOBoV/dc49lgQq5bWOOo3HU9JX0=; b=XtBRxHlw1BquafP0GsT4Y2QU+xlamRoXxcbjpcC2VKJQ29UwBhnfUS/F9toxQCXUca QrMj0b5MJ7t2a9LGhSmiF7gxqwVgZHMFyNRpKUXuhq2JC6FknfgGl4jclB+no/zH0O5D qpNFlEnMbBDFUbwiWxUjCqx5NTXHfkplsor+hmVC6reqjrq9nCQ/qsvN+KnVSYYxT8gy HBJ5L8ryD+1CvcdG+kOHLxOo4wD3eeDP9bKDCFzrFnsyBVovhzW9gdOADyedawNi/3AC k9Td/ozxiCNtjQRe8V2sgGCEyliv/rx5Iq0Nu0+IoRxvC4M3xgffT46TwV2qLg1m7gfS DM1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XN/cuKN9Qg/rT31/tOBoV/dc49lgQq5bWOOo3HU9JX0=; b=Q/E8MpHaGM6nkhkn6hmakkedD/ueCHnUDVbcGXBRQcXoh1egToUTqx2Z68rMOYVovi sxXlSFon1nIFWdvB6hm9s0pF2PYR0NcpJbWgebIvM1naTix9fcLG3XgU/kFCfRBMBzOK q6q2RG7CSawIzzTpEMaSL6sg0Mw39JeOjnDFN47dxp/9ecaLqtpNROXbCk2BqeA9eMB6 v6J5Ie1MWaon5FznltMsXO8G6xlBkx7mZ+kWVtFfmfVeGV7QBug416B/6+s9EDpYnzjk J6UMrrIIo+tBbo3DicKTKYV/wdMb9bB6o54t71sZ6X+Qdvu+f23fxBEJnjM5gLaBFoJm CPEg==
X-Gm-Message-State: AO0yUKVn9Q3Y49oI2ifsltszBivOGUfmP5RNTBq/ay3dusbArInBgVCe 6xM6DAVFhxDplaJALFDo7U8OnlBWRrHKETgYj+KELZ7rKfn5s9oa4Wk=
X-Google-Smtp-Source: AK7set/r9+WcGT7U6u6gM8BB0DFauFBbPCZUK2Ew/DiokgY76R7vjk6yGCZ/17U4hkHidV8C9ebywmUQcQGBbGNl4dE=
X-Received: by 2002:ae9:f219:0:b0:742:1cd5:824c with SMTP id m25-20020ae9f219000000b007421cd5824cmr135172qkg.13.1676985969824; Tue, 21 Feb 2023 05:26:09 -0800 (PST)
MIME-Version: 1.0
References: <167631700481.44401.16650680728729430437@ietfa.amsl.com> <m1pma4sfrl.fsf@narrans.de> <CAPt1N1mXF6qc__ELjArge3RfT1PvkzuzZLwHA_2bWp361+wNwA@mail.gmail.com> <DU0P190MB1978720103FADEF84B36E71DFDA59@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB1978720103FADEF84B36E71DFDA59@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 21 Feb 2023 08:25:34 -0500
Message-ID: <CAPt1N1=4W7ecQ3fM4KN6Ekgvvpn41AUQQkZqcVwVJ-3z9or8wg@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: Florian Obser <florian+ietf@narrans.de>, "snac@ietf.org" <snac@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000066f9805f535b9f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/snac/KpHac68VF3wM30ZhaUrbliBL5Qw>
Subject: Re: [Snac] I-D Action: draft-ietf-snac-simple-00.txt
X-BeenThere: snac@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for discussing problems relating to the automatic connection of stub networks to existing infrastructure networks. " <snac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/snac>, <mailto:snac-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/snac/>
List-Post: <mailto:snac@ietf.org>
List-Help: <mailto:snac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/snac>, <mailto:snac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2023 13:26:15 -0000

Right, MAY would be way too unspecific in that case. MAY basically says "we
aren't saying you shouldn't do this, nor that you mustn't do this." :)

So I think as you say that what we really need here is to be more specific
about exactly what "is available" means. So, perhaps:

If IPv6 prefix delegation and IPv6 service is both available on the
infrastructure link, then the stub  router MUST attempt to acquire a prefix
using IPv6 prefix delegation.

and

Therefore, when the stub router is able to successfully acquire a prefix
using DHCPv6-PD, it MUST use DHCPv6 PD rather than its own self-generated
ULA prefix.

On Tue, Feb 21, 2023 at 3:22 AM Esko Dijk <esko.dijk@iotconsultancy.nl>
wrote:

> What about the case where DHCPv6-PD is available, but the stub router
> doesn’t get the desired prefix length or encounters some error in the
> process?
>
> In that exceptional case it still MAY allocate a prefix out of its ULA
> prefix.
>
>
>
> Depending on the reader, “is available” and “works for me” can be
> different things.
>
>
>
> Esko
>
>
>
> *From:* Snac <snac-bounces@ietf.org> *On Behalf Of * Ted Lemon
> *Sent:* Monday, February 20, 2023 13:08
> *To:* Florian Obser <florian+ietf@narrans.de>
> *Cc:* snac@ietf.org
> *Subject:* Re: [Snac] I-D Action: draft-ietf-snac-simple-00.txt
>
>
>
> Yup, good catch. Thanks!
>
>
>
> On Mon, 20 Feb 2023 at 07:06, Florian Obser <florian+ietf@narrans.de>
> wrote:
>
>
> 5.2.2 states:
> |   If IPv6 prefix delegation is available, which implies that IPv6
> |   service is also available on the infrastructure link, then the stub
> |   router MAY use IPv6 prefix delegation to acquire a prefix to
> |   advertise on the stub network, rather than allocating one out of its
> |   ULA prefix.
>
> and 5.2.3:
> |   Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6
> |   PD rather than its own prefix.
>
> That's contradictory, I suppose 5.2.2 should say:
> |   If IPv6 prefix delegation is available, which implies that IPv6
> |   service is also available on the infrastructure link, then the stub
> |   router MUST use IPv6 prefix delegation to acquire a prefix to
> |   advertise on the stub network, rather than allocating one out of its
> |   ULA prefix.
>
> Or maybe just drop the last paragraph from 5.2.2 entirely.
>
> --
> In my defence, I have been left unsupervised.
>
> --
> Snac mailing list
> Snac@ietf.org
> https://www.ietf.org/mailman/listinfo/snac
>
>