On Jan 4, 2010, at 3:08 PM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
draft-jabley-reverse-servers-01.txt as a Proposed Standard
Colleagues, Ron,
In the context
for the record, sink.arpa document was my idea and Joe volunteered to help
it has nothing to do with his day time job but is related to something that
Joe cares about, having explicit documentation of special cases.
In that case, could you work with him to add language to the draft that
At 00:40 05/01/2010, John C Klensin wrote:
Ok, Joe, a few questions since, as indicated in another note,
you are generating these documents in your ICANN capacity:
John,
for the record, sink.arpa document was my idea and Joe volunteered to help
it has nothing to do with his day time job but
--On Tuesday, January 05, 2010 18:22 -0500 Olafur Gudmundsson
o...@ogud.com wrote:
...
(1) If ICANN can re-delegate the servers for these domains
without IAB or IETF action, why is IETF action needed to
create the new names? They are, after all, just names.
Transparency ?
Transparency
At 06:08 04-01-2010, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
draft-jabley-reverse-servers-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few
At 00:50 05/01/2010, John R. Levine wrote:
For the sink.arpa, it would be good to explain why we want this name to
exist.
We *don't* want the name to exist; that's the point of the draft. I
presume that's what you meant?
It would still be nice to put in an explanation of the motivation
for
Yeah. As far as I know, it is quite uncommon for applications to hard code
treatment of .INVALID. But you seem to be saying that they do, and that
causes problems that SINK.ARPA would solve. Tell us what they are.
There is one case where knowledge and special handling of the name may
cause
Hi,
On 2010-01-05, at 03:34, SM wrote:
Is what is proposed in this draft a matter of interest to the DNS Operations
Working Group? If so, the document could have been brought to the attention
of the relevant working group before the Last Call. That doesn't preclude
the draft from being
On 2010-01-04 at 06:08 -0800, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
draft-jabley-reverse-servers-01.txt as a Proposed Standard
First an editorial nit, there's an
Olafur == Olafur Gudmundsson o...@ogud.com writes:
Olafur There is one case where knowledge and special handling of
Olafur the name may cause problems: DNS Liers i.e. specialized
Olafur DNS resolvers that make all non-existing name exist that do
Olafur not generate lie for
Hi Joe,
At 08:00 05-01-2010, Joe Abley wrote:
We think the re-delegation of IN-ADDR.ARPA and IP6.ARPA is of great
interest to dnsop and other operational forums outside the IETF, and
as I mentioned yesterday the redelegation
I apologize for the working group question. I forgot that the draft
On 2010-01-05, at 16:55, SM wrote:
The diversity of operators has some advantages, i.e. not sharing fate. The
Introduction Section of this draft mentions that The choice of operators for
individual nameservers is beyond the scope of this document. I don't know
whether a change of
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
draft-jabley-reverse-servers-01.txt as a Proposed Standard
By my reading, section 5 of this document asks IANA to delegate
IN-ADDR-SERVERS.ARPA and IP6-SERVERS.ARPA to a set of nameservers, but
it doesn't ask them to provide contents for the
The document aims to specify the names of the nameservers to which
IN-ADDR.ARPA and IP6.ARPA can be delegated to, and nothing more.
OK. Does that mean it'll take another RFC to do the actual delegation?
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
I'm not really particularly happy with Joe's two recent DNS drafts.
They give me the impression as a reader that a lot of context is being
hidden from me and that the implications of the draft are being
carefully obscured so that I as a reviewer not involved in the process
won't know what is
On Mon, Jan 04, 2010 at 05:43:27PM -0500, Sam Hartman wrote:
They give me the impression as a reader that a lot of context is being
hidden from me and that the implications of the draft are being
carefully obscured so that I as a reviewer not involved in the process
won't know what is going
Hi Phil,
[Replying from jab...@hopcount.ca rather than joe.ab...@icann.org, since the
former is the address which is subscribed to the ietf@ietf.org list.]
On 2010-01-04, at 16:46, Phil Pennock wrote:
On 2010-01-04 at 06:08 -0800, The IESG wrote:
The IESG has received a request from an
On 2010-01-04, at 14:43, Sam Hartman wrote:
I'm not really particularly happy with Joe's two recent DNS drafts.
If I can help clarify anything, please let me know.
They give me the impression as a reader that a lot of context is being
hidden from me and that the implications of the draft
If you could me more substantive guidance as to where the documents could be improved,
I'd be very happy. As things stand the best I can do is say I'm sorry :-)
Well, OK. Is there a plan to move the DNS for in-addr.arpa
and ip6.arpa to the new set of servers? If so, what is it? Will it
On 2010-01-04, at 17:40, John R. Levine wrote:
If you could me more substantive guidance as to where the documents could be
improved, I'd be very happy. As things stand the best I can do is say I'm
sorry :-)
Well, OK. Is there a plan to move the DNS for in-addr.arpa and ip6.arpa to
On 2010-01-04, at 17:59, Joe Abley wrote:
On 2010-01-04, at 17:40, John R. Levine wrote:
If you could me more substantive guidance as to where the documents could
be improved, I'd be very happy. As things stand the best I can do is say
I'm sorry :-)
Well, OK. Is there a plan to move
Joe == Joe Abley jab...@hopcount.ca writes:
Joe On 2010-01-04, at 14:43, Sam Hartman wrote:
I'm not really particularly happy with Joe's two recent DNS drafts.
Joe If I can help clarify anything, please let me know.
So, I think John is asking the questions well about the in-addr.arpa
On 2010-01-04, at 19:23, Sam Hartman wrote:
So, I think John is asking the questions well about the in-addr.arpa
plan.
OK. I hope the answers are helpful.
For the sink.arpa, it would be good to explain why we want this name to
exist.
We *don't* want the name to exist; that's the point of
--On Monday, January 04, 2010 17:59 -0800 Joe Abley
jab...@hopcount.ca wrote:
...
The draft plan is to re-delegate IN-ADDR.ARPA and IP6.ARPA to
dedicated servers, named according to the text you have read.
The servers are to be operated by the five RIRs plus ICANN,
making six operators in
For the sink.arpa, it would be good to explain why we want this name to
exist.
We *don't* want the name to exist; that's the point of the draft. I presume
that's what you meant?
It would still be nice to put in an explanation of the motivation for
adding SINK.ARPA when its semantics and
On 2010-01-04, at 21:50, John R. Levine wrote:
For the sink.arpa, it would be good to explain why we want this name to
exist.
We *don't* want the name to exist; that's the point of the draft. I presume
that's what you meant?
It would still be nice to put in an explanation of the
On 2010-01-04, at 21:40, John C Klensin wrote:
Ok, Joe, a few questions since, as indicated in another note,
you are generating these documents in your ICANN capacity:
(1) If ICANN can re-delegate the servers for these domains
without IAB or IETF action, why is IETF action needed to create
It would still be nice to put in an explanation of the motivation for adding
SINK.ARPA when its semantics and operations, at least for clients, appear
identical to whatever.INVALID.
I don't know that I have anything much to add to my previous answers to that
question.
Well, at this point
On 2010-01-04, at 22:09, John R. Levine wrote:
It would still be nice to put in an explanation of the motivation for
adding SINK.ARPA when its semantics and operations, at least for clients,
appear identical to whatever.INVALID.
I don't know that I have anything much to add to my
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
draft-jabley-reverse-servers-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
30 matches
Mail list logo
