Hi Paul,
Thanks for the update. There's a newer draft circulating between
myself and Joe which captures your point. The additional word-smithing is
appreciated.
On Sun, 30 Nov 2014, Paul Hoffman wrote:
Greetings again. draft-ietf-dnsop-rfc6304bis obsoletes RFC 6304, therefore it
Hi
I have read through this and would support its progress. A reminder for
the record would not be a bad idea I think.
On Thu, 14 Aug 2014, Mark Andrews wrote:
Can we please move on this.
The reverse address are not yet insecurely delegated as
would be required
On Tue, 8 Jul 2014, Olafur Gudmundsson wrote:
On Jul 8, 2014, at 7:40 AM, ? Roy Arends r...@dnss.ec wrote:
Hiya,
I really like this idea. Many ISPs already do this, (including some high
profile public recursives, like Google and OpenDNS), because it simply makes
sense: It reduces latency
On Fri, 14 Feb 2014, Tony Finch wrote:
Joe Abley jab...@hopcount.ca wrote:
Reactions and reviews of the two documents would be most welcome!
The as112-dname draft still does not mention the glibc DNAME logging bug.
Which Linux distro, or a set of Linux distros? Some seaches yield various
Hi Joe, et al.
I have read this and support this work. It's good to see a proposal for
consolidating and making the namespace consistent. Given that MCAST.NET
use has been around a lot longer than IPV6.INT it will be interesting to
see for how long the names in the MCAST.NET zone will
FWIW, this was first broached on the AS112 operators ML. Thread here:
https://lists.dns-oarc.net/pipermail/as112-ops/2011-July/000209.html
Hope this contributes to the discussion.
On Thu, 14 Mar 2013, Joe Abley wrote:
On 2013-02-22, at 15:14, Dickson, Brian bdick...@verisign.com wrote:
Please review draft-andrews-dnsop-rfc6598-rfc6303
I've read this draft and would support it, in lieu of the omniscient-
darft should that not proceed any further. (I expect that if omniscient-
went through then the registry in 6303 would become deprecated or adapted
for another
On Wed, 10 Oct 2012, Joe Abley wrote:
On 2012-10-10, at 08:23, William F. Maton Sotomayor wma...@ottix.net wrote:
Please review draft-andrews-dnsop-rfc6598-rfc6303
I've read this draft and would support it, in lieu of the omniscient-
darft should that not proceed any further.
I
On Fri, 29 Jun 2012, Joe Abley wrote:
- we do need some mechanism to delegate (e.g.) zones under IP6.ARPA correspo
nding to the various v6 analogues of 1918
Do we have data that says we need to?
I don't think we get that data until we look for it, and I think we look for it
by delegating
On Wed, 27 Jun 2012, Joe Abley wrote:
Hi all,
The only suggestion I have heard relating to this draft is that if we supplied
custom software to synthesise answers we could avoid the overly-broad SOA RR
returned with the NXDOMAIN.
(My personal opinion is that this leads us down a path of
Alright, some time on my plate ...
On Wed, 4 Apr 2012, Joe Abley wrote:
On 2012-04-04, at 08:20, William F. Maton Sotomayor wrote:
It seems that after delivering my presentation on subsequent AS112
delegations in Quebec City, I hadn't recalled what the group thought about
adopting
All,
It seems that after delivering my presentation on subsequent AS112
delegations in Quebec City, I hadn't recalled what the group thought about
adopting this work as a dnsop item. So, I'm soliciting feedback on this
request. I have posted version 03 for your consideration.
Thanks,
as one of the as112 co-authors, i'll chime-in here.
you're right, there's an opportunity to leverage an existing mechanism and
registry for this draft. both rfc 6303 and rfc 6304 were developed at
different times so there's a little bit of a disconnect between those as
well. i think my
On Tue, 26 Jul 2011, George Michaelson wrote:
I would support this latter approach William: I think we should seek WG
adoption of three drafts
1) the michaelson as112-ipv6 draft, aiming for at least one 01 spin to a small
set of non-controversial V6 delegations, moving to WGLC and IANA asap.
All,
As a data point, the original draft of -00 really started life as
a straight copy of George's and Geoff's draft. I was looking for a way to
establish a procedure for sending instructions to IANA for new delegations
to AS112 nodes, so they paved the way. That said, I also don't have a
For AOB could we get AS112 draft status please?
Thanks,
On Wed, 24 Mar 2010, Peter Koch wrote:
Dear WG,
find enclodes a copy of the latest version of the DNSOP agenda for the
meeting starting in less than three hours. An online copy is located at
Greetings all,
There's some light discussion on the as112-ops mailing list about
whether or not AS112 should start doing a further two things:
- start replying using IPv6 transport
- amass more delegations for network blocks, like those enumerated in
rfc5735.
Given that the other two
On Mon, 8 Mar 2010, Alfred HÎnes wrote:
At Mon, 8 Mar 2010 09:27:20 -0500 (EST), William F. Maton Sotomayor wrote:
Given that the other two drafts on AS112 are already along the path
to getting considered beyond the WGLC, would it be prudent to
generate a third draft specific to these issues
On Thu, 8 Oct 2009, Joe Abley wrote:
Should this be extended to include RFC4193 unique local ipv6 unicast
addresses (i.e. [cd].f.ip6.arpa.)?
I seem to remember having that discussion a long time ago, maybe in concert
with discussion of marka's local-zones draft.
It was the Prague IETF in
On Thu, 8 Oct 2009, Chris Hills wrote:
On 06/10/09 03:30, internet-dra...@ietf.org wrote:
Many sites connected to the Internet make use of IPv4 addresses which
are not globally unique. Examples are the addresses designated in
RFC1918 for private use within individual sites.
Should this be
Hi folks,
Once again, I'm submitting fresh copies/versions as the saga
continues. Some updates then:
* draft-ietf-dnsop-as112-ops
- Corrected inconsistencies pointed out by Chris Thompson for AS112
webiste;
- corrected IP address for BLACKHOLE2-IANA.ORG (again thanks to Chris
All,
After somewhat of a longer hiatus on Peter's part (the WG last
call on one document seems to have drifted by and then dropped) and my part
(largely to do with increased workload), I have finally put together new
versions of each draft.
The proceeding is based on some correspondence
Greetings all,
Some time back in November of 2007, there was a discussion about
AS112 and an LOA. This seems to have trailed off into agreement that
wording should be drafted and sent somewhere, but I don't know if that
pretty much ended the dicsussion or if it simply trailed off... anyone
On Wed, 10 Sep 2008, Mark Andrews wrote:
In message [EMAIL PROTECTED], David Conrad
writes:
At his point, I will sit quietly for a while and let the WG comment
on whether they think that your proposed
alternative mitigation is adequate. On Friday, the WG chairs will
gauge consensus and I
On Tue, 1 Apr 2008, Sebastian Castro wrote:
So the data seems to be useful (but not complete). Once we got all the
data for DITL 2008 we could try to run the same test and look for
trends.
But it is a good start in having a look at the problem (or if anyone could
consider to be a problem).
On Mon, 3 Dec 2007, Phil Regnauld wrote:
The first step is to decide whether delegating to AS112 is reserved
to standardized (read: RFC) zones, like RFC1918, 169.254, etc..., or
whether anything sufficiently large -- and bogus -- is sufficient.
Step 0 of course is to
On Tue, 4 Dec 2007, Stephane Bortzmeyer wrote:
IMHO, it (this determination) could be outsourced to the root name
servers operators. The distribution of these broken domain names is
exponential with a fast decay. So, even adding only the first two or
three would handle most of the problem.
On Wed, 5 Dec 2007, Mark Andrews wrote:
Since AS112 is part of the Root Server Technical Operations Assn, then
getting the root server operators to provide feedback to AS112 (and I
guess someone arranging for the delegation thereof) of what junk zones
need to be dealt with makes sense. I don't
On Wed, 6 Jun 2007, Doug Barton wrote:
I think this also opens up a question about the motivation for this
draft. Is it primarily to reduce spurious traffic to the roots and/or
AS112 (certainly a noble goal, don't get me wrong), or is it primarily
to aid operators in configuring helpful
29 matches
Mail list logo
