Re: [DNSOP] The DNSOP document list; request for reviewers

"Hosnieh Rafiee" <ietf@rozanak.com> Wed, 10 September 2014 22:49 UTC

Return-Path: <ietf@rozanak.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 866101A8916; Wed, 10 Sep 2014 15:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 H46dziTjJKm0; Wed, 10 Sep 2014 15:49:49 -0700 (PDT)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 A173E1A8913; Wed, 10 Sep 2014 15:49:48 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 944D05660980; Wed, 10 Sep 2014 22:49:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH9ky4f_kmBJ; Thu, 11 Sep 2014 00:49:15 +0200 (CEST)
Received: from kopoli (p5DCC7C8E.dip0.t-ipconnect.de [93.204.124.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 6F9755660904; Thu, 11 Sep 2014 00:49:15 +0200 (CEST)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Paul Hoffman' <paul.hoffman@vpnc.org>, 'dnsop' <dnsop@ietf.org>
References: <B608A9A7-0E86-4C47-A54B-1B69AE6564DC@vpnc.org> <008101cfcd36$9d879430$d896bc90$@rozanak.com> <D939383B-F5DA-4EC3-BA38-1AF19556E547@vpnc.org>
In-Reply-To: <D939383B-F5DA-4EC3-BA38-1AF19556E547@vpnc.org>
Date: Thu, 11 Sep 2014 00:49:13 +0200
Message-ID: <008501cfcd49$724e6240$56eb26c0$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLQs88kcCB0ZCR1/73XEdfddCT/ggIlLCvZAjSnMkOZ1lRx0A==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/mM7Cd71kSjDOr8gc6nO1JHg6KAk
Cc: Int-area@ietf.org
Subject: Re: [DNSOP] The DNSOP document list; request for reviewers
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: Wed, 10 Sep 2014 22:49:50 -0000

> > Maybe now it is a good timing to raise this question that whether or
> > not DNSOP WG wants to accept to work on this draft or whether wants to
> > leave it to intarea. If it supposed to discuss in DNSOP then it needs
> > to be in the list of working items in the links of documents. Please
share
> your opinions.
> 
> Not in DNSOP. It is not about DNS operations; it is supposedly about
privacy of
> DNS queries. (I say "supposedly" because, even after 11 drafts, it is
still
> completely unclear what needs to exist before this proposal can work.)

The problem is that I have several times explained in the mailinglist the
purpose. Also in last versions, some reviewers also explained how this draft
can be useful to secure the last miles of the internet. When  folks did not
read the draft, they could not know what this draft is used for or what it
supposed to address. So, judging it before reading it doesn't seem to be
correct. If you followed the mailinglist from the earliest version you would
find out that the main focus of this draft was only secure authentication
and automation for this process as much as possible. IN other word,
addressing the last miles of the internet where TSIG or DNSSEC are unable to
easily address. All the requirements explained in the draft and how to
easily handle them incase some of the requirements are not available was
also explained in the draft. Let me give you an example, One example is
about IPv6 and in case the node doesn't support SeND. The privacy section
was added when I was convinced about DNS privacy. But not since I am no
longer convinced because I say that if the other traffic supposed to be not
encrypted then DNS privacy does not help. This is the case that I only
changed it to optional possibility that this draft can support without any
extra efforts and with the same way that it supports secure authentication
and automate this process.
About the versioning of this draft, that is because the reviewers of that
had different taste. Some asked to add comparison of this or that, some
others said to bring this section to top and change the place of this
section to down. So, if you check the Diffs you would see what are the
differences versions that is more on organizations rather than the whole
idea behind it .  

To summarize; the main contribution and focus of this draft from beginning
was/is only secure authentication and automation of this process where TSIG
or DNSSEC might not easily handle. This is during DDNS especially for PTR
record or other scenarios explained in the draft. It is only an assistant
mechanism to remove the gap as much as possible in first point of trust.
The section that most people have problem (or problem statement) is because
it appears to me that there are different opinions on the organization of
the drafts. Some like the old organization of this draft, some say if I add
this it would be clear or if I add that it would be clearer. In any case I
welcome all inputs and tried to apply them. I also sometimes updated the
draft in a short period of time that caused many versions due to the fact I
found some editorial mistake left during review process of the one who were
helping me improve the language.


I'm
> not at all convinced it belongs in INTAREA either.
> 

So now again, the same question. if it doesn't belong to DNSOP while it
appears it can be (as far as I can remember Suzanne (sorry if I spelled it
incorrectly) in my last IETF meeting, during my presentation in intarea,
said that why this draft is in Intarea and this is the work should be done
in DNS area...)) and you say it is not related to neither DNSOP nor Intarea,
then where is its place? Where the drafts should go when DNSEXT is no longer
available and this draft belonged to there?

Thanks,
Best,
Hosnieh