Joe Abley writes:
I'm saying that the body that administers the root zone is not the
IETF. Not being a policy person I don't have any specific fears, but
I'll observe that the set of people who make policy that affects
administration of the root zone has a fairly small intersection with
the se
On 2009-12-27, at 13:07, Arnt Gulbrandsen wrote:
> I don't get it. Are you saying that you think it's possible that someone will
> come along and overturn RFC 2606, and that that someone wouldn't overturn any
> .arpa-related rules?
I'm saying that the body that administers the root zone is not
Joe Abley writes:
On 2009-12-25, at 06:02, Arnt Gulbrandsen wrote:
What is the actual difference between the proposed sink.arpa and the
existing .invalid?
(a) Our idea when we chose that name was to try and make the policy
environment within which the (non-) assignment rule was to be
insti
On 2009-12-25, at 06:02, Arnt Gulbrandsen wrote:
> What is the actual difference between the proposed sink.arpa and the existing
> .invalid?
(a) Our idea when we chose that name was to try and make the policy environment
within which the (non-) assignment rule was to be instituted clear. The
John C Klensin writes:
I guess the issue for me is that I want to see either
(i) Exactly one name allocated, with no hand waving
about registries and other, similar names.
+1, but I want to add a question: What is the actual difference between
the proposed sink.arpa and the ex
On Mon, 21 Dec 2009, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'The Eternal Non-Existence of SINK.ARPA (and other stories) '
> as a BCP
I would like to see a requirement (or at least a recommendation)
that DNS o
--On Tuesday, December 22, 2009 08:55 -0800 Ted Hardie
wrote:
>...
> Hi John,
>
> My take on this is that this idea is worth exploring, and this
> document can take us down the right road for that by adding
> the caching clarification and removing the examples. Removing
> the apparent force o
At 11:05 22-12-2009, Joe Abley wrote:
Why?
Some future IAB would have a list of names and the appropriate reference.
The purposes of the document under review is described fairly
succinctly in section 1:
1. to create a new IANA registry called "ARPA Reserved Names" (see
Section 4
On 2009-12-22, at 18:32, SM wrote:
> At 06:23 22-12-2009, Joe Abley wrote:
>
>> On 2009-12-22, at 11:33, SM wrote:
>>
>> The goal was to provide a set of additional requirements that the IAB would
>> take into consideration when carrying out the duties as described in 3172.
>> For example, so
On Tue, 22 Dec 2009, SM wrote:
> At 05:50 22-12-2009, Tony Finch wrote:
> >
> > What issue? As far as I can tell there's no conflict between Joe's draft
> > and RFC 5321, except that the choice of words in the example needs
> > improvement.
>
> The wording in the draft is at odds with what is in RF
At 05:50 22-12-2009, Tony Finch wrote:
What issue? As far as I can tell there's no conflict between Joe's draft
and RFC 5321, except that the choice of words in the example needs
improvement.
The wording in the draft is at odds with what is in RFC 5321. This
can be discussed in the relevant w
On Mon, 21 Dec 2009, John C Klensin wrote:
>
> If implicit MXs continue to be permitted, this proposal, as I understand
> it, would not work.
I believe it will work. RFC 5321 explains it twice:
If an empty list of MXs is returned, the address is treated as if it
was associated with an impli
On Mon, Dec 21, 2009 at 11:14 PM, John C Klensin wrote:
>
> Olafur,
>
> It seems to me that Ted's message asks for more clarity about
> what is being specified, actual review by email-related groups
> of email-related records and their implications, and so on.
> Certainly I agree with those reques
On 2009-12-22, at 11:33, SM wrote:
> This draft requires IAB review and approval.
You'll note that we asked for it in section 6.
> The following paragraph may require some scrutiny:
>
> "INVALID is poorly characterised from a DNS perspective in
> [RFC2606]; that is, the specificatio
On Mon, 21 Dec 2009, SM wrote:
>
> If I understood the story, it is to get compliant MTAs not to attempt mail
> delivery to domains which do not wish to accept mail. This does not really
> solve the implicit MX question but that's another story.
The idea of using sink.arpa as an MX target (like t
Hi Olafur,
At 21:22 21-12-2009, Olafur Gudmundsson wrote:
Correction the message should have been:
http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html
The changes that Ted Hardie asked for does not address my concern as
my comment was about the example in Section 3:
"Installing
On 2009-12-22, at 04:57, John C Klensin wrote:
> Let me say this a little more strongly. This proposal
> effectively modifies RFC 5321 for one particular domain name at
> the same time that it effectively (see notes by others)
> advocates against coding the relevant domain name into anything
> o
--On Tuesday, December 22, 2009 00:22 -0500 Olafur Gudmundsson
wrote:
> Correction the message should have been:
> http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html
>
>Olafur
>
>
> At 00:18 22/12/2009, Olafur Gudmundsson wrote:
>> John, SM
>> do the changes that Ted Hardie as
Correction the message should have been:
http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html
Olafur
At 00:18 22/12/2009, Olafur Gudmundsson wrote:
John, SM
do the changes that Ted Hardie asked for address your concern(s)?
see:
http://www.ietf.org/mail-archive/web/ietf/current/msg
John, SM
do the changes that Ted Hardie asked for address your concern(s)?
see:
http://www.ietf.org/mail-archive/web/ietf/current/msg59759.html
All we want sink-arpa to do is to create a domain name with known
characteristics and create a mechanism to define other such domain
names that may have
--On Monday, December 21, 2009 14:18 -0800 SM
wrote:
> At 10:40 21-12-2009, The IESG wrote:
>> The IESG has received a request from an individual submitter
>> to consider the following document:
>>
>> - 'The Eternal Non-Existence of SINK.ARPA (and other stories)
>> ' as a BCP
>>
>> The IESG
On Mon, Dec 21, 2009 at 10:40:07AM -0800, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'The Eternal Non-Existence of SINK.ARPA (and other stories) '
> as a BCP
>
> The IESG plans to make a decision in the next few
At 10:40 21-12-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Eternal Non-Existence of SINK.ARPA (and other stories) '
as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments
At 15:38 21/12/2009, Ted Hardie wrote:
On Mon, Dec 21, 2009 at 12:16 PM, Olafur Gudmundsson wrote:
> At 14:16 21/12/2009, Ted Hardie wrote:
>>
>> I have not objection to the creation of sink.arpa, but
>> I will repeat comments I made on the NANOG list
>> that there are ways of accomplishing the
On Mon, Dec 21, 2009 at 12:16 PM, Olafur Gudmundsson wrote:
> At 14:16 21/12/2009, Ted Hardie wrote:
>>
>> I have not objection to the creation of sink.arpa, but
>> I will repeat comments I made on the NANOG list
>> that there are ways of accomplishing the same thing
>> which do not require the cr
At 14:16 21/12/2009, Ted Hardie wrote:
I have not objection to the creation of sink.arpa, but
I will repeat comments I made on the NANOG list
that there are ways of accomplishing the same thing
which do not require the creation of this registry. One
example method would be to create MX records w
I have not objection to the creation of sink.arpa, but
I will repeat comments I made on the NANOG list
that there are ways of accomplishing the same thing
which do not require the creation of this registry. One
example method would be to create MX records which
point to 257.in-addr.arpa; this addr
27 matches
Mail list logo
