Re: [Emu] Adoption call for eap.arpa

Mohit Sethi <mohit@iki.fi> Fri, 22 March 2024 09:31 UTC

Return-Path: <mohit@iki.fi>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC87C14F61B for <emu@ietfa.amsl.com>; Fri, 22 Mar 2024 02:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=iki.fi
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 w39EjHqpoiVr for <emu@ietfa.amsl.com>; Fri, 22 Mar 2024 02:31:09 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 E1478C14CE5F for <emu@ietf.org>; Fri, 22 Mar 2024 02:31:08 -0700 (PDT)
Received: from [192.168.0.201] (unknown [106.215.88.184]) (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) (Authenticated sender: mohit) by meesny.iki.fi (Postfix) with ESMTPSA id 4V1HBb5zSGz100T; Fri, 22 Mar 2024 11:31:02 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1711099865; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zS1B1KhhJ+/xabcybayfKJ5XM3+Gzv13UGIWBKaxX4A=; b=sgkAKmXLBsUTLLA1vvQKZ+/xhQwyg91a70czaLDAyslH1s5i1TDQq7pcusuVqPeggeMbmS 1/PC+whpGs4bSe2vaDa7VpExWMxnj4ZgsLQBoT6lJwohVZo+MFS2jPiIjJ1byfe7mT1f6z UG5qRTFueCtlnE4jqQWg+XCTPCueUHg=
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1711099865; a=rsa-sha256; cv=none; b=P5iPKoHWaCOc1wGXELK3vrQ2X0jAqJsU6HZR9F0vXkIwQylQawH0DknkDzGSxqdvGU+SLS owFellhmm6C+GX1VYV7Wti+S6k3DMBV2VAjgivsXe4PprTIfVVIsOTbHAKkB/i7LploQYA m5ubSf6jjWaQ/7Bt7Wb1ZK3FhhFQ1p8=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=mohit smtp.mailfrom=mohit@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1711099865; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zS1B1KhhJ+/xabcybayfKJ5XM3+Gzv13UGIWBKaxX4A=; b=cujuatqOAstJ30Xc43I6ki81J1Ns4FJ63H7Wmj3dNW6eKSz7Sk+4ROruJnpkauwpoD/GkX l3JAwWXEeInQxUtcAmkPa0GABxLiuPO6z1zhmbI6TIzQlteQMW3R/iLx7/OSXHi6AEU3O6 qZeXwbuomXUInKa/DymfxIlJyogw+yU=
Message-ID: <195deaf8-d514-4f75-bd9d-2648347b318c@iki.fi>
Date: Fri, 22 Mar 2024 15:00:54 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Michael Richardson <mcr+ietf@sandelman.ca>, Alan DeKok <aland@deployingradius.com>, "emu@ietf.org" <emu@ietf.org>
References: <F1FD786F-D0B1-494B-B384-95BBB4B7790B@akayla.com> <6752380a-0155-4ba4-9aee-107162538a4b@iki.fi> <06836614-D52C-4CC4-B26C-1D66BC049C55@deployingradius.com> <235509.1711079890@dyas> <FD4D848F-0E37-48D8-913D-4A7C2063F33C@deployingradius.com> <4a5b64fc-5dfd-471b-b672-eb6a2ea65e59@iki.fi> <241138.1711086842@dyas>
From: Mohit Sethi <mohit@iki.fi>
In-Reply-To: <241138.1711086842@dyas>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/24OF4fSnqBca1aoxMSxSmGLbGDU>
Subject: Re: [Emu] Adoption call for eap.arpa
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 09:31:14 -0000

Hi Michael,

You know homenet details much better. The only point I was trying to 
make is that it is possible to have sub-domains under a special use 
domain. "home.arpa" is one example. "e164.arpa" from RFC 6116 
(https://www.rfc-editor.org/rfc/rfc6116.html) seems to be another example.

Whether sub domains are resolvable and how they are registered/managed 
can be (and will be) different. As you wrote in another email, if we 
have a good justification, IAB will likely bless with appropriate guidance.

Hope you + others in the working group had an enjoyable and productive 
week in Brisbane. Safe travels!

--Mohit

On 3/22/24 11:24, Michael Richardson wrote:
> Mohit Sethi <mohit@iki.fi> wrote:
>      > As far as I can tell, we will not be the first ones using such a
>      > scheme. ".home.arpa." defined in RFC 8375
>      > (https://www.rfc-editor.org/rfc/rfc8375.html) allows sub domains. It says:
>      > "For an administrative domain that uses subdomains of 'home.arpa.', such as a
>      > homenet, the recursive resolvers provided by that domain will be able to
>      > answer queries for subdomains of 'home.arpa.'"
>
> It's not at all the same thing :-)
> home.arpa is a real anchor which home routers can serve names into using DNS.
> (Replacing ".local" [which implies mDNS], and .lan, which some home routers use)
>
>      > We are taking a more conservative approach where subdomains need expert
>      > review and registration before they are allocated and can be used in
>      > deployments.
>
> I would not characterize it this way at all.
> I suspect we can have what we want, we just need to explain it to the IAB
> well enough.  Unfortunately too late in the week for a hallway conversation.
> I found some IESG to talk to at the last break, but no IAB.
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>