Subject: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 22 Nov 2005 10:53:19 -0500

The IESG has received a request from the DNS Extensions WG to consider the 
following documents:

- 'Minimally Covering NSEC Records and DNSSEC On-line Signing '
   <draft-ietf-dnsext-dnssec-online-signing-00.txt> as a Proposed Standard
- 'Derivation of DNS Name Predecessor and Successor '
   <draft-ietf-dnsext-dns-name-p-s-01.txt> as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-12-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-01.txt

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Nov 2005 09:36:33 +0000

>    <draft-ietf-dnsext-dnssec-online-signing-00.txt> as a Proposed Standard

According to RFC 2026 one of the criteria for Proposed Standard is
"appears to enjoy enough community interest to be considered valuable".
I do not believe we have seen evidence of this for this I-D. Indeed, we
have only seen statements that this will _not_ be deployed.

I propose that this should be downgraded to Experimental.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Roy Arends <[email-masked]>
Date: Fri, 25 Nov 2005 10:51:09 +0100 (CET)

> I propose that this should be downgraded to Experimental.

I concur

Roy

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 25 Nov 2005 09:50:04 -0500

I concur

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 25 Nov 2005 16:01:58 +0100

> I propose that this should be downgraded to Experimental.

Gentlemen,

We started gauging what the status needed to be in Paris (see
http://tools.ietf.org/wg/dnsext/minutes?item=minutes63.html where at  
least
one stakeholder in the enumeration business  showed interest)

Then these issues have been raised specifically during last call:
    http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ 
msg01100.html
       and again in:
    http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ 
msg01241.html

In other words I think the working group passed this decision point.

Personally I do not care either way, Experimental or Proposed, but I  
do care
not having to revisit old decisions.

Thanks,

--Olaf

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

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Nov 2005 15:12:30 +0000

Olaf M. Kolkman wrote:
> http://tools.ietf.org/wg/dnsext/minutes?item=minutes63.html where at least
>    http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01100.html
>       and again in:
>    http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01241.html
> 
> 
> Personally I do not care either way, Experimental or Proposed, but I do
> care not having to revisit old decisions.

But ... what those documents appear to say is that you intend to go for
Experimental, then for some unknown reason you changed your mind at the
last moment.

So, if any decision was made at all (which is far from clear) it was for
Experimental.

Cheers,

Ben.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 25 Nov 2005 16:40:29 +0100

> Experimental, then for some unknown reason you changed your mind at  

Yep, with explanation and all, in the open for anybody to see, to  
question or to comment.

There was no feedback and it is not that I didn't wait for it before  
pushing the document to the IESG.

The working groups consensus as I read it is that the working group  
thinks that online-signing needs to update 4034/4045 and that it is  
best to do that by moving the doc on the standards track.

--Olaf

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 25 Nov 2005 11:37:24 -0500

Olaf M. Kolkman wrote:

> We started gauging what the status needed to be in Paris [...] 
> 

Isn't a last call a process step to get a feedback from a broader 
audience than the wg itself? If such is the case, count me as an 
outsider of IETF DNSEXT who got a chance to review this only at the last 
call step!

Isn't a last call a last chance to double check for minor glitches or 
misunderstanding in the wg procedures, or whatever last minute check 
might discover?

In this instance, I think the Experimental or Proposed status is still a 
relevant issue. The Experimental (or Informational) status announces to 
the reader that the foremost protocol features for privacy protection of 
authenticated denial of existence lies elsewhere, i.e. more 
efficient/accurate documentation of engineering decisions. I would 
respectfully request the wg chairs to take this view into perspective 
while handling the wg decision process.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 25 Nov 2005 17:37:15 +0100

> outsider of IETF DNSEXT who got a chance to review this only at the  
> last call step!

Yep correct.

But I am trying to argue that we, the working group, of which I  
consider Ben and Roy active and valuable participants did not provide  
this feedback when it was asked for. I am arguing that this was an  
explicit item
during the last call and that we reached consensus decision.

I also argue that there have at least one proponent for this  
technique on record (Paris minutes).

> Isn't a last call a last chance to double check for minor glitches  
> or misunderstanding in the wg procedures, or whatever last minute  
> check might discover?

Yes, but see above, I argue we are revisiting decisions.

>
> In this instance, I think the Experimental or Proposed status is  
> still a relevant issue. The Experimental (or Informational) status  
> announces to the reader that the foremost protocol features for  
> privacy protection of authenticated denial of existence lies  
> elsewhere, i.e. more efficient/accurate documentation of  
> engineering decisions. I would respectfully request the wg chairs  
> to take this view into perspective while handling the wg decision  
> process.

We do not yet have a protocol feature for privacy protection of  
authenticated denial of existence.

Seriously, we do not know if there is a skeleton in that particular  
NSEC3 closet. I personally hope there is not, but we might find  
unsolvable technical problems in the forthcoming workshops, we might  
even get somebody arguing for experimental status during IETF last  
call :-).

If you think there should be some text that explicitly does not  
exclude other mechanisms to be deployed on the standards track than I  
think that is a fine addition to the document. It is a new concern  
that has not been brought up yet.  Send text.

I probably regret writing multiple mails on the subject during one  
day. I'll try to stay away from the keyboard :-)

Have a nice weekend,

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Nov 2005 23:40:40 +0000

# The working groups consensus as I read it is that the working group  thinks
# that online-signing needs to update 4034/4045 and that it is  best to do
# that by moving the doc on the standards track.

i wasn't in paris, but i concur with this position.

---

From: Roy Arends <[email-masked]>
Date: Sat, 26 Nov 2005 13:30:13 +0100

> best to do that by moving the doc on the standards track.

Since this update is so incredibly minimal, how about adding this 'update'
to the bis-updates document of the same author, and publish online signing
as informational, since it does not require fundamental protocol change,
but just implementation info.

This way, consensus is not violated.

Otherwise it looks to me that online signing is minimally updating 4034
and 4035 for the sole purpose of reaching proposed standard.

Roy

---

From: Roy Arends <[email-masked]>
Date: Sat, 26 Nov 2005 13:37:04 +0100

On Fri, 25 Nov 2005, Olaf M. Kolkman wrote:

> this feedback when it was asked for.

It is asked for now !
I'm acting now !

Roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sat, 26 Nov 2005 19:06:23 +0100

> and 4035 for the sole purpose of reaching proposed standard.

It is clear where we are: You argue to revert the groups conscious  
decision on this. Its up to the IESG to push back if they agree with  
you.

As said, if you want the problem you want to address is that  "Online  
signing should explicitly say that it is not expected to be the  
exclusive solution in this problem space" then that is something you  
can fix with text. Send text. If the paraphrase  of the problem is  
not correct then please explain what the actual problem is.

--Olaf

---

From: Roy Arends <[email-masked]>
Date: Sat, 26 Nov 2005 20:13:15 +0100

> decision on this. Its up to the IESG to push back if they agree with

Olaf, I proposed a solution that does _NOT_ violate the groups 'conscious'
decision on this:

"Since this update is so incredibly minimal, how about adding this
 'update' to the bis-updates document of the same author, and publish
 online signing as informational, since it does not require fundamental
 protocol change, but just implementation info.
 This way, consensus is not violated."

> can fix with text.

Where did this come from ?

> Send text. If the paraphrase  of the problem is

See above.

Roy

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 26 Nov 2005 19:46:54 -0500 (EST)

I don't understand what the real issue is here.  I saw Ben claim that
we haven't seen evidence of community interest.  And I'm hearing
speculation that this document claims to update 4034 and 4035 just to
justify it being on the standards track.  These sound like different
concerns and leave me wondering if there's some other underlying
issue.  Do you want this off the standards track as a way to
discourage people from doing it?  Do you want to see DNSEXT publishing
fewer standards track documents generally?

In the past, DNSEXT has not hesitated to publish tiny protocol changes
as standards track documents, even when we knew they'd be included in
(or even obsoleted by) other documents in the near future: see 3445,
3655, 3658, 3755, 3757, and 3845, all of which are now obsolete.  Is
there some reason why we should now be hesitant to push out minor
changes in the standards track?

-- Sam

---

From: Ben Laurie <[email-masked]>
Date: Sun, 27 Nov 2005 11:11:51 +0000

> changes in the standards track?

Firstly, online signing is not a minor change - it completely violates
one of the fundamental principles of DNSSEC: no online keys. The only
reason we have NSEC (and hence the problems with it) in the first place
is in order to conform with this principle.

Secondly, the reason I objected was because I re-read RFC 2026 and
realised that we did not appear to be conforming to it. The past
behaviour of the WG w.r.t. 2026 strikes me as a red herring.

Thirdly, I don't agree that 6.3 implies that the I-D should be on the
standards track - what it says is that a replacement for an established
standard has to follow the whole process, rather than jumping the queue,
which seems an entirely unrelated circumstance to me.

Fourthly, it is a WG item to fix the problems with NSEC. Until it was
brought up in this thread I would not have even considered that anyone
would stoop so low as to claim that once online signing is on the
standards track then that obligation has been discharged. But it seems
that this is a possibility in at least some people's minds, and since I
do not agree that online signing is a viable fix, I feel I must also
object on those grounds.

I do agree with Olaf that these concerns would have been better brought
up earlier in the process, but it seems my attention was elsewhere. I
apologise.

Cheers,

Ben.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sun, 27 Nov 2005 15:40:15 +0100

Ben,

My position on the first 3 points is that the working group did  
discuss these concerns and made a decision and I do not think we  
should be revising these unless there is a new problem that we ought  
to address.

> do not agree that online signing is a viable fix, I feel I must also

I wouldn't have considered such low stoop as well but somebody  
expressed that fear while I was trying to understand what new problem  
was needed to be addressed. This particular beast is something we can  
easily address by asking the working group if there is consensus that  
NSEC3 is to appear on standards track once the work is done.

It is my strong opinion that the work is to appear on the std-track  
and that if std-track would not be the target we should not even  
consider working on it. If you want we can do a formal call for  
consensus on this point. That would clear the air and we can move on  
(and focus on real work).

--Olaf

---

From: Ben Laurie <[email-masked]>
Date: Sun, 27 Nov 2005 15:07:39 +0000

Olaf M. Kolkman wrote:
> 
> Ben,
> 
> My position on the first 3 points is that the working group did discuss
> these concerns and made a decision and I do not think we should be
> revising these unless there is a new problem that we ought to address.
> 
> I wouldn't have considered such low stoop as well but somebody expressed
> that fear while I was trying to understand what new problem was needed
> to be addressed. This particular beast is something we can easily
> address by asking the working group if there is consensus that NSEC3 is
> to appear on standards track once the work is done.
> 
> It is my strong opinion that the work is to appear on the std-track and
> that if std-track would not be the target we should not even consider
> working on it. If you want we can do a formal call for consensus on this
> point. That would clear the air and we can move on (and focus on real
> work).

Since the other three points are all process issues, I'm more than happy
to allow the IESG to do whatever is appropriate.

It seems to me that clearing the air would be a good plan, but I think
the consensus we are seeking is that online signing is not adequate to
solve the problems with NSEC, rather than that NSEC3 will follow any
particular path (which would presuppose the outcome of the process).

Cheers,

Ben.

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 27 Nov 2005 11:21:48 -0500 (EST)

Thanks for the response.  I'm glad to know that I was hearing
completely different things.

Ben> Firstly, online signing is not a minor change - it completely
Ben> violates one of the fundamental principles of DNSSEC: ...

Roy> Since this update is so incredibly minimal, ...
...
Roy> Otherwise it looks to me that online signing is minimally
Roy> updating 4034 and 4035 for the sole purpose of reaching
Roy> proposed standard.

To be clear, I think this doc should be marked as "updating" 4034 and
4035 because it explicitly allows (or even encourages) doing things
that 4034 and 4035 explicitly forbid.  That doesn't necessarily argue
for standards track, though I suspect that putting it on the standards
track will help avoid future down-reference issues.

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Sun, 27 Nov 2005 11:26:59 -0500 (EST)

On Sat, 26 Nov 2005, Roy Arends wrote:

> ... the bis-updates document of the same author...

As a technicality...

While I am one of the editors of both documents, they do have
different editorial TEAMS: I worked with Johan Ihren on the epsilon
document, and Rob Austein and I are editting bis-updates (he's been
working on the next revision).

One might still argue that both documents share the same author: the
DNSEXT working group.

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Nov 2005 18:08:04 +0000

# Firstly, online signing is not a minor change - it completely violates
# one of the fundamental principles of DNSSEC: no online keys.

what?  where's THAT documented?  you mean BIND9 should not have an online
key it can use to re-sign the changed parts of a zone after each update?
(if we're RFC-incompatible, we'll surely be wanting to remove that feature?)

# The only reason we have NSEC (and hence the problems with it) in the first
# place is in order to conform with this principle.

um, no.  we have NSEC to prevent MiTM from injecting false negatives.  NSEC
has nothing to do with online signing or online keys per se.

# Secondly, ...
# 
# Thirdly, ...
# 
# Fourthly, it is a WG item to fix the problems with NSEC. Until it was
# brought up in this thread I would not have even considered that anyone would
# stoop so low as to claim that once online signing is on the standards track
# then that obligation has been discharged.  But it seems that this is a
# possibility in at least some people's minds, and since I do not agree that
# online signing is a viable fix, I feel I must also object on those grounds.

i think i agree with you that white lies does not discharge the WG's
responsibility to make NSEC fit the needs of the current WG, but it's still a
change to a standards-track document and thus has to be on the same track.
even if it's optional for responders, it has to be mandatory for initiators.

---

From: Roy Arends <[email-masked]>
Date: Sun, 27 Nov 2005 19:13:43 +0100 (CET)

On Sun, 27 Nov 2005, Samuel Weiler wrote:

> Thanks for the response.

Oh, you're welcome Sam.

> I'm glad to know that I was hearing completely different things.

Are you hearing things ? :)

> Roy> updating 4034 and 4035 for the sole purpose of reaching

Don't get confused now Sam, Ben and I do not disagree, but merely talking 
about different things. With the 'minimal update' I meant the small change 
in text in 4034 and 4035 that currently, for some reason, keeps 
online-signing from being informational or even experimental.

With 'not a minor change' Ben was not referring to the update in text in 
4034/4035, but about the violation of one of the fundamental principles 
of DNSSEC: no keys online.

> track will help avoid future down-reference issues.

That is why I argue to have this update put in the bis-updates.
That way, online signing can be informational.

If you can't agree with this, then it is obvious: online signing is 
minimally updating 4034 and 4035 for the sole purpose of reaching proposed 
standard.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Nov 2005 20:19:53 +0000

# ... With the 'minimal update' I meant the small change in text in 4034 and
# 4035 that currently, for some reason, keeps online-signing from being
# informational or even experimental.

when 4034/4035 went to iesg, it was known that this section would be wrong,
but what wasn't known was the exact way in which it was wrong or could be
made right.  therefore it was planned that this rule would be relaxed.  the
document which relaxes it has to be on the same track as 4034/4035.

# With 'not a minor change' Ben was not referring to the update in text in
# 4034/4035, but about the violation of one of the fundamental principles of
# DNSSEC: no keys online.

i completely disagree that this is a fundamental principle, or any other kind
of principle, of DNSSEC (or DNSSEC-bis).  some zones have keys online, at the
discretion of the zone operator.  perhaps you mean "DNSSEC shall not *require*
keys to be online" in which case i'd agree.  but as seen on this thread and
elsewhere/previously, the language has to be very exact.

# > To be clear, I think this doc should be marked as "updating" 4034 and 4035
# > because it explicitly allows (or even encourages) doing things that 4034
# > and 4035 explicitly forbid.  That doesn't necessarily argue for standards
# > track, though I suspect that putting it on the standards track will help
# > avoid future down-reference issues.

i disagree.  it does necessarily argue for "same track as 4034/4035".

# That is why I argue to have this update put in the bis-updates.
# That way, online signing can be informational.
# 
# If you can't agree with this, then it is obvious: online signing is
# minimally updating 4034 and 4035 for the sole purpose of reaching proposed
# standard.

i cannot agree with ANY of this.  it won't work, AND it's not the plan we
agreed to when we forwarded 4034/4035 to the IESG knowing that this section
was wrong and would need to be changed.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 27 Nov 2005 21:20:11 +0000

> elsewhere/previously, the language has to be very exact.

Good point, and I totally agree.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Nov 2005 08:38:58 +1100

> is in order to conform with this principle.

	No.  Online signing was always a choice.  Simple secure dynamic
	update requires keys to be online.  One just needs to weigh the
	risks vs the advantages.

	This is a choice.  You can continue to use standard NSEC and have
	offline signing.
 
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Sun, 27 Nov 2005 23:47:45 +0100 (CET)

> when 4034/4035 went to iesg, it was known that this section would be wrong,

It was known ? By whom ? Pointers ?

> made right.  therefore it was planned that this rule would be relaxed.

It was planned ? By whom ? Pointers ?

> the document which relaxes it has to be on the same track as 4034/4035.

Sure. This can be the bis-updates document, no ?

> was wrong and would need to be changed.

Which we ? Who did agree with what plan ? Pointers ?

I should get out more. I'm obviously missing most of the fun :)

Roy

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Nov 2005 06:10:27 +0000

# It was known ? By whom ? Pointers ?

by all of the folks who were then working on the white lies problem.

# It was planned ? By whom ? Pointers ?

by the editing team and WG chairs.  it might even be in the minutes.

# > the document which relaxes it has to be on the same track as 4034/4035.
# 
# Sure. This can be the bis-updates document, no ?

if we wanted to pointlessly mislead the readers of the historical record into
believing that the text of document A wasn't really standards track but the
text of document B was even though it's the same text, we could do that.  but
we won't stoop that low, will we?

# I should get out more. I'm obviously missing most of the fun :)

yes.

---

From: Roy Arends <[email-masked]>
Date: Mon, 28 Nov 2005 08:46:03 +0100 (CET)

> by all of the folks who were then working on the white lies problem.

I was one of them. It wasn't known by me.

> by the editing team and WG chairs.  it might even be in the minutes.

I was one of them. It wasn't known by me. Couldn't find it in the minutes. 
WG chairs ? Olafur, Olaf ? If you would be so nice and point me to a 
general record of this plan?

> we won't stoop that low, will we?

This is not right Paul. I'm not trying to mislead the readers of the 
historical record into believing anything. What I'm trying to do is to 
protect the reader of the standards track from a false sense of security.

Online signing is, in general, a really bad idea.

What I find horrendesly disturbing is when a few TLD's were interested in 
for instance Opt-In, we fought against FUD, held workshops, invested in 
code, held discussions, wrote drafts etc, etc. It did not help. It was 
burried faster then you can spell IETF. Your reasoning is naive if you 
think that some 'won't stoop that low'.

And yet, when one TLD shows interest in this terribly bad idea of online 
signing, it is tombstoned in Proposed Standard.

Roy

---

From: Geoffrey Sisson <[email-masked]>
Date: Mon, 28 Nov 2005 08:50:56 GMT

> I propose that this should be downgraded to Experimental.

I'm reluctant to say this work does not "enjoy enough community
interest to be considered valuable".

Online signing represents a distinct set of trade-offs relative to
NSEC3 (and friends): online signing keys may be more exposed, and
online signing DNSSEC name servers may be more vulnerable to DoS;
however, less zone information is leaked (no more than without DNSSEC)
and the threat of offline attacks is eliminated.

While online signing may or may not suitable for deployment by large
TLDs, I suspect there will be interest in using this technique for
zones further down in the DNS tree -- e.g. organisations with a greater
need for privacy or secrecy of zone data -- particularly if good
implementations (say, ASICS-based, HSM-based online signing DNSSEC
name server appliances) become available.

So in this case I would caution against gauging "community interest" by
the interest of dnsext WG participants to use this technique
themselves.  While root server operators, TLDs and RIRs are well
represented in the WG, the potential users of online signing probably
are not.

Geoff

---

From: Roy Arends <[email-masked]>
Date: Mon, 28 Nov 2005 11:33:24 +0100 (CET)

> Online signing is, in general, a really bad idea.

Okay, after a lot of private conversations with different folks in the wg, 
I'm less convinced online signing is, in general, a really bad idea.

Since I reached the limit of 1 post per day, I'll let the subject rest.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Mon, 28 Nov 2005 10:58:35 +0000

> (if we're RFC-incompatible, we'll surely be wanting to remove that feature?)

OK, what I mean is that it should be possible to do DNSSEC without
online keys, rather than that online keys are completely banned.

RFC 4033, 3.1 "Note that the private keys used to sign zone data must be
kept secure and should be stored offline when practical."

> has nothing to do with online signing or online keys per se.

NSEC works the way it does so you can prove negatives without having to
sign dynamically.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Nov 2005 09:15:37 -0500

>name server appliances) become available.

Well said.  Participants need to balance their views of the problem 
space with other views of the problem space.

>represented in the WG, the potential users of online signing probably

This is what bothers me about the process we follow and the 
importance we put on it.  Until the IETF can guarantee that all 
involved parties make comments, the IETF has to treat all of it's 
"decisions" as partial results.  I.e., although consensus is 
"achieved", it is never carved in stone.  All hope is not lost, 
partial results are better than none, but remember to put them in 
their place.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Nov 2005 15:30:30 +0000

# >..., I suspect there will be interest in using this technique for
# >zones further down in the DNS tree -- ...

i'm worried that my most important comment on this thread was buried too
deep in the message where i said it, so let me try again.

in order to preserve or provide the white-lies capability to zone owners
who find it desireable and sufficient, we MUST put the technology on the
standards track.  it has to be mandatory-to-implement for any requestor
who wants to be "DNSSEC compliant".  responders don't have to use it, but
if a responder wants to use it, then all or virtually all requestors must
grok it.  there's no way to do that if 4034/4035 is a proposed standard
and white lies is informational or experimental or a best current practice.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Nov 2005 10:52:08 -0500

...
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-online-signing-00.txt

In this document, in section 2, there is this line:

            ).com 3600 IN NSEC +.com ( RRSIG NSEC )

The line should read

            \).com 3600 IN NSEC \+.com ( RRSIG NSEC )

Using the escape characters as defined in RFC 1035.

A minor point - but the documentation of DNS records ought to 
continue to follow this syntax.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 29 Nov 2005 11:19:31 -0500 (EST)

> continue to follow this syntax.

Thanks, Ed.  I'll make sure we get this in AUTH48 if not before.

-- Sam