Alissa Cooper | 31 Aug 22:04 2015
Picon

Alissa Cooper's Yes on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Registering this name seems warranted in light of the potential security
impact. We need to make our processes work for the Internet, not vice
versa.

I agree with Alvaro and Stephen's comments. In particular, to my eye
[tor-rendezvous] should be a normative reference given item #3 in Section
2. However, it seems more important to publish this document than to
re-issue the last call to call out a new downref.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(Continue reading)

Advance notice - H-root address change on December 1, 2015


This is advance notice that there is a scheduled change to the IP addresses
for one of the authorities listed for the DNS root zone and the .ARPA TLD.
The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army
Research Laboratory.

The new IPv4 address for this authority is 198.97.190.53.

The new IPv6 address for the authority is 2001:500:1::53.

This change is anticipated to be implemented in the root zone on 1 December
2015, however the new addresses are operational now. They will replace the
previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also
previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL).

We encourage operators of DNS infrastructure to update any references to the
old IP addresses and replace them with the new addresses. In particular,
many DNS resolvers have a DNS root "hints" file. This should be updated with
the new IP addresses.

New hints files will be available at the following URLs once the change has
been formally executed on December 1:

  http://www.internic.net/domain/named.root 
  http://www.internic.net/domain/named.cache

The old IPv4 address will continue to work for six months after the
transition (until 1 June 2016), at which point it will be retired from
service.  The address will remain under the control of the Army Research
Laboratory, never to be used again for DNS service.  The old IPv6 address
(Continue reading)

internet-drafts | 31 Aug 17:17 2015
Picon

I-D Action: draft-ietf-dnsop-dns-terminology-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : DNS Terminology
        Authors         : Paul Hoffman
                          Andrew Sullivan
                          Kazunori Fujiwara
	Filename        : draft-ietf-dnsop-dns-terminology-04.txt
	Pages           : 27
	Date            : 2015-08-31

Abstract:
   The DNS is defined in literally dozens of different RFCs.  The
   terminology used by implementers and developers of DNS protocols, and
   by operators of DNS systems, has sometimes changed in the decades
   since the DNS was first defined.  This document gives current
   definitions for many of the terms used in the DNS in a single
   document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-terminology/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-terminology-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-terminology-04

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

Brian Haberman | 28 Aug 15:46 2015
Picon

Brian Haberman's No Objection on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

Brian Haberman has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Stephen's points that the long debate has utility and that
there were some proposed text changes that appear to be missing.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Petr Spacek | 27 Aug 12:39 2015
Picon

Requesting adoption of draft-spacek-dnsop-update-clarif

Dear DNSOP Chairs,

I'm requesting a call for adoption of draft-spacek-dnsop-update-clarif.

We did not have time allocated for discussing this in Prague but the draft is
so short and easy (to quote Mark's words: "blatantly obvious") that I do not
feel that postponing this till Yokohama is necessary.

Thank you.
Petr Spacek

A new version of I-D, draft-spacek-dnsop-update-clarif-01.txt
has been successfully submitted by Petr Spacek and posted to the
IETF repository.

Name:		draft-spacek-dnsop-update-clarif
Revision:	01
Title:		Clarifications to the Dynamic Updates in the Domain Name System (DNS
UPDATE) specification
Document date:	2015-08-27
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-01.txt
Status:         https://datatracker.ietf.org/doc/draft-spacek-dnsop-update-clarif/
Htmlized:       https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-spacek-dnsop-update-clarif-01

Abstract:
(Continue reading)

Ólafur Guðmundsson | 25 Aug 23:55 2015

Fwd: New Version Notification for draft-ogud-dnsop-ds-remove-00.txt


This is a proposed update the CDS/CDNSKEY processing to address the omission in RFC7344. 

Comment please, 

Olafur

Ps: I'm using a new markup tool to write the ID thus any errors in format are my fault. 

---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Tue, Aug 25, 2015 at 5:48 PM
Subject: New Version Notification for draft-ogud-dnsop-ds-remove-00.txt
To: Olafur Gudmundsson <olafur+ietf <at> cloudflare.com>



A new version of I-D, draft-ogud-dnsop-ds-remove-00.txt
has been successfully submitted by Olafur Gudmundsson and posted to the
IETF repository.

Name:           draft-ogud-dnsop-ds-remove
Revision:       00
Title:          Removing DS records from parent via CDS/CDNSKEY
Document date:  2015-08-25
Group:          Individual Submission
Pages:          5
URL:            https://www.ietf.org/internet-drafts/draft-ogud-dnsop-ds-remove-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ogud-dnsop-ds-remove/
Htmlized:       https://tools.ietf.org/html/draft-ogud-dnsop-ds-remove-00


Abstract:
   RFC7344 specifies how trust can be maintained in-band between parent
   and child.  There are two features missing in that specification:
   initial trust setup and removal of trust anchor.  This document
   addresses the second omission.

   There are many reasons why a domain may want to go unsigned.  Some of
   them are related to DNS operator changes, others are related to
   DNSSEC signing system changes.  The inability to turn off DNSSEC via
   in-band signalling is seen as a liability in some circles.  This
   document addresses the issue in a sane way.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-drafts | 24 Aug 17:41 2015
Picon

I-D Action: draft-ietf-dnsop-negative-trust-anchors-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Definition and Use of DNSSEC Negative Trust Anchors
        Authors         : Paul Ebersman
                          Warren Kumari
                          Chris Griffiths
                          Jason Livingood
                          Ralf Weber
	Filename        : draft-ietf-dnsop-negative-trust-anchors-13.txt
	Pages           : 19
	Date            : 2015-08-24

Abstract:
   DNS Security Extensions (DNSSEC) is now entering widespread
   deployment.  However, domain signing tools and processes are not yet
   as mature and reliable as those for non-DNSSEC-related domain
   administration tools and processes.  This document defines Negative
   Trust Anchors which can be used to mitigate DNSSEC validation
   failures by disabling DNSSEC validation at specified domains.

   [RFC Editor: Please remove this before publication.  This document is
   being stored in github at https://github.com/wkumari/draft-livingood-
   dnsop-negative-trust-anchors . Authors accept pull requests, and keep
   the latest (edit buffer) versions there, so commenters can follow
   along at home.]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-negative-trust-anchors-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 24 Aug 17:03 2015
Picon

I-D Action: draft-ietf-dnsop-negative-trust-anchors-12.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Definition and Use of DNSSEC Negative Trust Anchors
        Authors         : Paul Ebersman
                          Warren Kumari
                          Chris Griffiths
                          Jason Livingood
                          Ralf Weber
	Filename        : draft-ietf-dnsop-negative-trust-anchors-12.txt
	Pages           : 19
	Date            : 2015-08-24

Abstract:
   DNS Security Extensions (DNSSEC) is now entering widespread
   deployment.  However, domain signing tools and processes are not yet
   as mature and reliable as those for non-DNSSEC-related domain
   administration tools and processes.  This document defines Negative
   Trust Anchors which can be used to mitigate DNSSEC validation
   failures by disabling DNSSEC validation at specified domains.

   [RFC Editor: Please remove this before publication.  This document is
   being stored in github at https://github.com/wkumari/draft-livingood-
   dnsop-negative-trust-anchors . Authors accept pull requests, and keep
   the latest (edit buffer) versions there, so commenters can follow
   along at home.]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-negative-trust-anchors-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 24 Aug 15:47 2015
Picon

I-D Action: draft-ietf-dnsop-edns-client-subnet-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Client Subnet in DNS Queries
        Authors         : Carlo Contavalli
                          Wilmer van der Gaast
                          David C Lawrence
                          Warren Kumari
	Filename        : draft-ietf-dnsop-edns-client-subnet-03.txt
	Pages           : 28
	Date            : 2015-08-24

Abstract:
   This draft defines an EDNS0 extension to carry information about the
   network that originated a DNS query, and the network for which the
   subsequent response can be cached.

IESG Note

   [RFC Editor: Please remove this note prior to publication ]

   This informational document describes an existing, implemented and
   deployed system.  A subset of the operators using this is at
   http://www.afasterinternet.com/participants.htm . The authors believe
   that it is better to document this system (even if not everyone
   agrees with the concept) than leave it undocumented and proprietary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-client-subnet-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Stephen Farrell | 21 Aug 21:44 2015
Picon
Picon

Stephen Farrell's Yes on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(6 pages, so I read it now:-)

We definitely need to approve this. It's been too
long in the process already and that's been our
(the IETF's) fault. (I won't object to us trying to
improve 6761 after we've done this one, so some
of the long debate will have lasting utility.)

I thought I saw some edits from the last call
that were agreed to be applied and that would
improve the document. In particular, one that
was to the effect that .onion names would in
future need to conform to DNS name syntactic
constraints (lengths basically) so that if a
node did send a DNS query containing a .onion
name, that'd be less likely to cause weird 
issues.

Section 2 is a little sloppy in how it talks
about ".onion addresses (point 1), ".onion
names" (which is the right term I think) and
"queries for .onion" (I think you mean any
query for any .onion name and not only for
the TLD #4 and #5). A bit more consistency
would be no harm, though it's clear enough as
is.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Barry Leiba | 21 Aug 20:37 2015
Picon

Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I believe the IETF shouldn't be involved with registering special-use
TLDs for things that have been squatted on, and thus helping to
circumvent ICANN's normal process.  I know there are a bunch of other
such TLDs that people/organizations would have us snag for them, and I
very much want to avoid that nasty iceberg, of which this is the tip.

That said, I well understand the deployed code involved and the
importance of keeping things working in this case, and I don't want to
stand in the way.  So I'm standing aside with an "Abstain" ballot.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Gmane