Ietf mailing list probe message

[[e-mail]]

This is a probe message.  You can ignore this message.

The Ietf mailing list has received a number of bounces from you,
indicating that there may be a problem delivering messages to
[e-mail]. A bounce sample is attached below.
Please examine this message to make sure there are no problems with
your email address.  You may want to check with your mail
administrator for more help.

If you are reading this, you don't need to do anything to remain an
enabled member of the mailing list.  If this message had bounced, you
would not be reading it, and your membership would have been disabled.
Normally when you are disabled, you receive occasional messages asking
you to re-enable your subscription.

You can also visit your membership page at

    https://www1.ietf.org/mailman/options/ietf/ietf-archive%40megatron.ietf.org


On your membership page, you can change various delivery options such
as your email address and whether you get digests or not.  As a
reminder, your membership password is

    vunuux

If you have any questions or problems, you can contact the list owner
at

    [e-mail]

--- Begin Message ---

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pipe to |/usr/IETF/scripts/archive-mail ietf
    generated by [e-mail]

The following text was generated during the delivery attempt:

------ pipe to |/usr/IETF/scripts/archive-mail ietf
       generated by [e-mail] ------

/bin/cat: /home/mail-archive/ietf-temp.message: No such file or directory

------ This is a copy of the message, including all the headers. ------

Return-path: <[e-mail]>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GrDuH-0002DV-9Z; Mon, 04 Dec 2006 08:30:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GnfDj-0000G1-OK
	for [e-mail]; Fri, 24 Nov 2006 12:52:15 -0500
Received: from open.nlnetlabs.nl ([213.154.224.1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnfDi-00021a-6l
	for [e-mail]; Fri, 24 Nov 2006 12:52:15 -0500
Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53])
	by open.nlnetlabs.nl (8.13.8/8.13.4) with ESMTP id kAOHkVqO065122;
	Fri, 24 Nov 2006 18:46:31 +0100 (CET)
	(envelope-from [e-mail])
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: <[e-mail]>
From: "Olaf M. Kolkman" <[e-mail]>
Date: Fri, 24 Nov 2006 18:46:31 +0100
To: Phillip Hallam-Baker <[e-mail]>,
	IETF DNSEXT WG <[e-mail]>
X-Pgp-Agent: GPGMail 1.1.2 (Tiger)
X-Mailer: Apple Mail (2.752.2)
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS 
	autolearn=ham version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on open.nlnetlabs.nl
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
X-Mailman-Approved-At: Mon, 04 Dec 2006 08:30:25 -0500
Cc: John C Klensin <[e-mail]>, Dave Crocker <[e-mail]>,
	Patrik Faltstrom <[e-mail]>
Subject: Non-terminal-wildcards Re: SRV records considered dubious
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: IETF DNSEXT WG <[e-mail]>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0484632784=="
Errors-To: [e-mail]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0484632784==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Apple-Mail-33--747885452"
Content-Transfer-Encoding: 7bit

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-33--747885452
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed





Hello Phil,

I moved this discussion to namedroppers and BCC-ed the IETF list,  
please continue this part of the thread on namedroppers.

For namedroppers, the context is:
A discussion on draft-iab-dnsext-choices (the document) and the  
pointer mechanism as described in [1].


>> I also do not agree that the document should not proceed
>> without addressing the pointer mechanism. The document is not
>> of the type that specifies new solutions, it documents
>> tradeoffs. If your pointer mechanism would be more than
>> 'mail-ware' (i.e. had sufficient review and consensus) then
>> it could have been part of the equation. I think that its to
>> late for that.
>

On 23Nov 2006, at 5:18 PM, Hallam-Baker, Phillip wrote:
> How is it going to have review if the editors refuse to consider it?

It is not only the editors of dns-choices that need to review the  
pointer mechanism,  I think a wider review of the pointer mechanism  
is needed in order to assess the idea is actually a good alternative  
choice. The only thin I claim is that, as far as that happened, it  
did not come to a conclusion yet.

> Sounds to me like you are saying that you are not going to consider my
> proposal until after I persuade DKIM to adopt it.
>
> Fine.
>

No, that is not what I am trying to say. I think that if you want to  
'design' a more general extension mechanism you should actually try  
to pull this spec out of DKIM.

[1] doesn't look that DKIM specific and it doesn't specify the  
configuration directive you proposed on namedroppers in July [2] nor  
the discussion that followed. I think that it is time for a rev or  
maybe even a new draft in order to get closer to a conclusion.


So,  let us try to do justice to the whole "a suggestion for super- 
wildcards" discussion (thread starting at [4]).

Rereading that thread:
I think that most folk seem to agree that the "**" (terminal) super- 
wildcard could be implemented using a preprocessor [3], personally I  
think that such mechanism does not need a protocol action. I also  
think that there are still folk that would like to see a solution for  
the not-so-terminal wildcard (_foo.*.example.com) although we have  
not seen any concrete solutions and there is doubt that deployment of  
such (protocol) extension would ever happen.

On new RRs: We can continue to have long debates on how difficult it  
is to introduce a new RR and weather or not the problems that we see  
with a major systems vendor are real or not. I do not think that will  
lead anywhere. Having said that: This working group is wrapping up  
RFC2929bis which should ease the IANA process and at some point in  
the future, so my crystal ball predicts, all systems will support  
unknown RRs and their portable zone file representation.

Let us assume that whatever we design to deal with the problem at  
hand is so good that it will cause system updates on which support  
for RFC3597 piggybacks.

Back to the problem at hand as described in  section 3 of your  
document [1] and some parts of the email discussion. Paraphrased: An  
application (the DKIM policy client) wants to know all policy  
statements for application X (currently mail) that relates to domain  
Y. Since domain Y is an element in the DNS namespace the only  
sensible choice is to use the DNS to reach that information. Also, we  
need to design a generic mechanism so that we do not have to register  
new identifiers whenever X changes i.e. we do not want to go back to  
IANA. (do I paraphrase that correctly ?).

I have seen you argue against applying DDDS for this problem but I am  
not sure why DDDS and the 'terminal' super-wildcard generation  
mechanism does not provide the appropriate means to redirect to a  
'policy server' that is (potentially) outside the DNS? My gut feeling  
is that we have the building blocks available now. You indicated you  
dismissed the idea, could you elaborate a bit, or refer to the  
appropriate message in the thread in case I have overlooked the  
argument?

I'm also not sure if and how you can avoid namespace clashes for  
applications when you do not register the identifiers for "X". In  
that sense I think that the effort by Dave [5] is sensible.


> Just don't dare tell me that choices in any way prevents DKIM from
> considering my proposal. And don't dare suggest that choices does
> anything more than consider the four options it describes.

I have not told you anything, at this moment I am trying to listen.

Enjoy the turducken left-overs :-)

--Olaf


[1] http://www.ietf.org/internet-drafts/draft-hallambaker- 
dkimpolicy-00.txt
[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00976.html
[3] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg01042.html
[4] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00989.html
[5] http://www.ietf.org/internet-drafts/draft-crocker-dns-attrleaf-02

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/




--Apple-Mail-33--747885452
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.

iD8DBQFFZy/3tN/ca3YJIocRAheoAKCZuf0svn4TLe1CYUBTshOC+msvAgCfQOgq
5ePZ89364BcngCGhbUxIzXA=
=NkmZ
-----END PGP SIGNATURE-----

--Apple-Mail-33--747885452--


--===============0484632784==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf

--===============0484632784==--

--- End Message ---