Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

manning bill <bmanning@isi.edu> Thu, 29 May 2014 21:29 UTC

Return-Path: <bmanning@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22D61A08DC for <ietf@ietfa.amsl.com>; Thu, 29 May 2014 14:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 yxaDaTVw2DQ8 for <ietf@ietfa.amsl.com>; Thu, 29 May 2014 14:29:05 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDC91A0437 for <ietf@ietf.org>; Thu, 29 May 2014 14:29:05 -0700 (PDT)
Received: from [192.168.0.2] (cpe-23-241-118-60.socal.res.rr.com [23.241.118.60]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4TLLvQP015268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 May 2014 14:22:00 -0700 (PDT)
Subject: Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Content-Type: text/plain; charset="windows-1252"
From: manning bill <bmanning@isi.edu>
In-Reply-To: <5387A27C.3030201@gmail.com>
Date: Thu, 29 May 2014 14:21:56 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C401B2E0-64B3-425F-9892-3AF5A5CE8E2B@isi.edu>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140521194638.06eaf508@resistor.net> <1111FB79-012A-414B-B8CD-0BBDAE8BD6A8@hopcount.ca> <6.2.5.6.2.20140522095317.0c5fd648@elandnews.com> <5C02BCCA-79D7-40A5-BFB0-26284A667E78@vpnc.org> <DC9ED318-2352-4AF0-8A43-29D237C32B64@vigilsec.com> <924045CD-DC34-423B-8702-CD99CF687D46@vpnc.org> <31344.1401304682@sandelman.ca> <BF0C8B7B-27D0-40B8-8FBD-5D255951222F@ericsson.com> <538795FB.6060205@gmail.com> <4F62CE0A-114F-4285-B332-9D9EB2B38B42@isi.edu> <5387A27C.3030201@gmail.com>
To: carlos@lacnic.net
X-Mailer: Apple Mail (2.1878.2)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/43LeDemoDtjlVK6jOxN0k-tkhMw
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 May 2014 21:29:07 -0000

/bill
Neca eos omnes.  Deus suos agnoscet.

On 29May2014Thursday, at 14:11, Carlos M. Martinez <carlosm3011@gmail.com> wrote:

> Hi
> 
> On 29/05/2014 17:41, manning bill wrote:
>> apparently there is not “enough consensus”, since several roots don’t have published v6 addresses.
>> there -might- be rough consensus in a narrow slice of the technical community that has an axe to grind.
>> end of the day, the IETF has no say on how people operate their networks/services.
> 
> I meant consensus here, not in the root server operator community.

	root server operator community and their clients  v.   a subset of folks in the IETF - which was my point

> 
> I believe that there is a limit on the argument of operational
> independence. If you agree to provide a service the whole Internet
> depends on, well, it's reasonable that you need to comply with certain
> requirements.

	what they clients demand is the base requirement.

> 
> If an operator can't / won't comply with the requirements set by the
> IETF, they can ask to be relieved of their duty.

	by whom?

>> 
>> if you think it should, i’d like to see a resolution of the DMARC deployment that requires all SMTP
>> servers to require, per IETF mandate to support DMARC.
>> 
>> Engineering is not Operations.   This is not the IOTF.
> 
> DMARC/mailing lists are hardly critical infrastructure. This is not even
> remotely comparable to the root server issue in terms of impact.

	the topic was/is operations.  not “critical” infrastructure.
	and the fallout for a few folks adopting DMARC has vastly outweighed
	the fallout of a gradual, measured migration to IPV6 and the perhaps
	eventual termination of v4 services.   Again, the clients/users of the
	operational systems matter more than the pontification of some engineers.

	if you insist on only using pure v6, then you have the power to do so.
	telling another entity how to run their operations is rife with legal entanglements

>> 
>> /bill
> 
> ~Carlos
>> Neca eos omnes.  Deus suos agnoscet.
>> 
>> On 29May2014Thursday, at 13:18, Carlos M. Martinez <carlosm3011@gmail.com> wrote:
>> 
>>> I think there is enough consensus saying that root server operators MUST
>>> support IPv6. I think it's hard to argue that the Internet needs this to
>>> move to IPv6, as otherwise we'll be saying that it'll be ok for future
>>> networks to not be able to access some root servers, or putting the
>>> burden of supporting all IPv6 on a subset of root servers.
>>> 
>>> If you add that not all root server operators offer anycast copies, or
>>> do it in a limited way, well, we could be putting the IPv6 internet in a
>>> fragile position.
>>> 
>>> IMO, setting this requirement is well within the core competencies of
>>> the IETF.
>>> 
>>> Then comes the question what to do (if anything) with those root server
>>> operators who chose to ignore this MUST.
>>> 
>>> IMO, This is probably outside the IETF's sphere, and it should be
>>> possible to even say so in the proposed document.
>>> 
>>> cheers!
>>> 
>>> ~Carlos
>>> 
>>> On 29/05/2014 05:24, Jari Arkko wrote:
>>>> 
>>>>> I would like every A-M.root-servers.net have an A and AAAA record.
>>>>> 
>>>>> I don't care how the root-server operators decide to partition to workload
>>>>> among hardware.
>>>> 
>>>> Yes, that is my view as well.
>>>> 
>>>>> Over time we will need more v6 responders and fewer v4
>>>>> responders.
>>>>> I don't think that there is, or should be, any requirement that v4 and v6 be
>>>>> answered by the same system, and given anycast, they might even be in
>>>>> different locations.
>>>>> 
>>>>> I think that the current text captures this just fine:
>>>> 
>>>> Agreed.
>>>> 
>>>> Jari
>>>> 
>>> 
>> 
>