IETF Logo Mail Archive

Re: [DNSOP] request for adoption

Paul Wouters <paul@nohats.ca> Wed, 28 November 2018 13:40 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6564F130FE8 for <dnsop@ietfa.amsl.com>; Wed, 28 Nov 2018 05:40:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 pE6qFosPfjZc for <dnsop@ietfa.amsl.com>; Wed, 28 Nov 2018 05:40:23 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68867130FA2 for <dnsop@ietf.org>; Wed, 28 Nov 2018 05:40:23 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 434hc12SqtzMHk; Wed, 28 Nov 2018 14:40:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543412417; bh=jdQ6O9UxKIwYz8OndBysIgwCFN3LQAGpcwXal+fyEA4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tABgaZV61hk7zy4c/s2AsNwS2AJqXcWmLyVzB7BX0LeE3zxsn57/dCoCpNP+7uD/L aXElpOtCpYQ+Dk46MaPVw9ms+q69l7yS3Nh4/LzfE4joreKrIpVfA/UUq0Pc8bOOg+ 2nHIggxZ4fKaYdwmzP6BY0qTfta++/Oct/z2nqz4=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id rIXMrcmuTonT; Wed, 28 Nov 2018 14:40:15 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 28 Nov 2018 14:40:15 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2C6F34A280C; Wed, 28 Nov 2018 08:40:14 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2C6F34A280C
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2040941C3B26; Wed, 28 Nov 2018 08:40:14 -0500 (EST)
Date: Wed, 28 Nov 2018 08:40:14 -0500
From: Paul Wouters <paul@nohats.ca>
To: Petr Špaček <petr.spacek@nic.cz>
cc: dnsop@ietf.org
In-Reply-To: <f9c8907f-cd2f-44f3-593a-b8e21ace8dc3@nic.cz>
Message-ID: <alpine.LRH.2.21.1811280837010.28047@bofh.nohats.ca>
References: <87a7mefuz6.fsf@nic.cz> <alpine.LRH.2.21.1811130101010.9026@bofh.nohats.ca> <f9c8907f-cd2f-44f3-593a-b8e21ace8dc3@nic.cz>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/V999hq7KnQZ2fpJvdODzj65_-wk>
Subject: Re: [DNSOP] request for adoption
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2018 13:40:38 -0000

On Tue, 27 Nov 2018, Petr Špaček wrote:

>> MB     7     a mailbox domain name (EXPERIMENTAL)     [RFC1035] MG    
>> 8     a mail group member (EXPERIMENTAL)     [RFC1035] MR     9     a
>> mail rename domain name (EXPERIMENTAL)     [RFC1035]
>
>
> Is there any *technical* use for this field? Do we need it in the YANG
> model?

The technical reason would be "It's dead Jim! Don't bother implementing this"

But if people pick up the yang model and it has all these obsolete
entries, those people in turn will start some basic implementation /
support of these. So I understand yang is not the group that should
make this decision, hence my thought of quickly adding a column to the
registry to obsolete/deprecate so that yang can skip these.

> Maybe we can just omit it while transforming the registry into model and
> be done with it ...

But then people think the yang model is incomplete?

Paul

v2.23.0 | Report a Bug | By Email