Re: [DNSOP] Changes to Charter

Tim Wicinski <tjw.ietf@gmail.com> Sun, 30 March 2014 09:19 UTC

Return-Path: <tjw.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A741A0838 for <dnsop@ietfa.amsl.com>; Sun, 30 Mar 2014 02:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 nElmCdDVOdaI for <dnsop@ietfa.amsl.com>; Sun, 30 Mar 2014 02:19:04 -0700 (PDT)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 625391A0837 for <dnsop@ietf.org>; Sun, 30 Mar 2014 02:19:04 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id i8so7843490qcq.31 for <dnsop@ietf.org>; Sun, 30 Mar 2014 02:19:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=KGHZJCp1r2izsDcYT+oYsmpq+aBKyJuEHkKHIaPA1d8=; b=CS5NBfMSc+lzAeG3JNnE8+GkYpyRO2Sa3Fn9/p2akTda0LDlPEI8hBGzMTNxACWJP8 8T/4CPqoABEdBBWJ680IV86HV+ls8YdyaCSlczMnfCaaaeCZJogQDTY+i2K4kQIiOuYX oIjUkIgTfHafXbBLw6KdJRxxeH5oaH0rGeyvtOzQyBpvF9as9avumjinp4ZUpw9xVq6H inpeF5TiOoWh+uA1pmznVO9SgW6W6iX9dct0myRfoo8iSRKtnA54D1JeTKCECDwT4uaB gqidNY2ZVVQ9/0nvrJrCDlx0ZBLkc7Da5XH6w4GfUs1NKh1mzkR36Jr1SRrPzYPaEwdi Qoyw==
X-Received: by 10.229.96.199 with SMTP id i7mr79802qcn.20.1396171141516; Sun, 30 Mar 2014 02:19:01 -0700 (PDT)
Received: from feather.local (184-19-89-148.drr03.clbg.wv.frontiernet.net. [184.19.89.148]) by mx.google.com with ESMTPSA id u7sm21311650qap.5.2014.03.30.02.19.00 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Mar 2014 02:19:00 -0700 (PDT)
Message-ID: <5337E183.9090804@gmail.com>
Date: Sun, 30 Mar 2014 05:18:59 -0400
From: Tim Wicinski <tjw.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0a2
MIME-Version: 1.0
To: Dan York <york@isoc.org>, "dnsop@ietf.org" <dnsop@ietf.org>
References: <CF56FDD9.6FC62%york@isoc.org>
In-Reply-To: <CF56FDD9.6FC62%york@isoc.org>
Content-Type: multipart/alternative; boundary="------------000807060604010802090507"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/p_LTRdpQ9m7I69s5JExq-VGWiWI
Cc: joel jaeggli <joelja@bogus.com>
Subject: Re: [DNSOP] Changes to Charter
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 30 Mar 2014 09:19:07 -0000

Dan,

See below

On 3/24/14, 9:54 PM, Dan York wrote:
> Tim,
>
>
> I support these changes as they seem to be logical modifications to the
> charter, particularly given the closing of the DNSEXT wg.  I personally
> don't know that DNSSEC needs to be added to point #5, as I do see it as a
> natural extension of DNS.  However, I could see that for clarity for other
> people it might be useful.  Perhaps just adding DNSSEC into the list of
> options would work such as:
>
>> 5. Address possible minor changes or extensions to the DNS Protocol,
>> initially with a focus on the operational impacts of these changes. Act
>> as clearinghouse or providing advice to ADs and other WGs on EDNS0
>> options, new RRTYPEs, record synthesis, DNSSEC, or other mechanics of
>> extending
>> DNS to support other applications.

I can buy adding it, if it helps drive the point home.   This will still 
go through some editing steps.
> Again, I don't know that this is 100% required, but it may be a simple
> change to help things be 100% clear to all.
>
> I agree with Warren that the wording of the last sentence of point #6
> isn't clear, and thank you for your explanation, Tim.  What about this?
> ------
> 6.  Publish documents that address DNS-related issues, by identifying
> and documenting the problem space around the issue. The group will then
> identify whether these issues should be addressed within DNSOP or
> within another appropriate working group.
> ------
>
> Or perhaps starting it differently:
> ------
> 6. Serve as a clearinghouse for DNS-related issues where people can bring
> drafts that document the problem space around DNS issues.  The group will
> then decide whether those issues belong in DNSOP or will work with the
> authors
> and appropriate ADs to determine the appropriate group for the work.
> ------
I like this second phrasing of yours, and have replaced my text with 
yours,.
> It sounds like you are trying to do something sort of like what the RAI
> area did with the DISPATCH working group where people could bring work
> ideas that related to real-time communications and that working group
> would "dispatch" the issues to the appropriate existing working group - or
> create a new working group to take on that new work.    In the case of
> DISPATCH, that group exists solely to serve as this clearinghouse and is
> not chartered to perform specific work itself (
> http://datatracker.ietf.org/wg/dispatch/charter/ ).

This was *exactly* our idea when adding this item.  I do not know if 
there is a specific need, but I do know we are approached regularly 
about drafts that involve DNS that wants anything from review to 
blessing.  I believe we've been given some latitude to provide that 
function, and I believe DNSOP can perform this function, as long as 
things are handled in a timely manner, with clear disposition.

> In this case, it sounds like you are looking for this to be a *part* of
> what DNSOP is to be about.  (And I can see that being a useful function as
> it is not clear where else someone would bring new DNS-related questions
> *except* to DNSOP.)
>
> Dan

Thanks for these comments. I'll spin a new version adding all the things 
I've heard so far and send it out later today.

tim