Subject: [DNSOP] New Version Notification for draft-fanf-dnsop-rfc2317bis-01.txt

From: Tony Finch <[email-masked]>
Date: Tue, 10 Nov 2015 14:22:35 +0000

I have published a new version of my Classless IN-ADDR.ARPA draft. This
incorporates some miscellaneous suggestions from before the IETF meeting,
and Petr's suggestions from last week.

All comments and suggestions welcome!

Petr, I've cut down your security considerations fairly viciously; please
shout if you think I have cut too much! I dropped the paragraph about
UPDATE security since that is covered in RFC 2136. I also dropped the last
paragraph since the earlier part seems to just repeat what the previous
paragraph said, and the later part seems to suggest some special server
side processing; if server-side processing is a real suggestion it needs a
real spec.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Wight, Portland, Plymouth: Southwest 5 or 6, occasionally 7 at first. Moderate
or rough, occasionally very rough in west Plymouth. Rain or drizzle at times.
Moderate or good, occasionally poor.

---------- Forwarded message ----------
Date: Tue, 10 Nov 2015 06:09:17 -0800
From: [email-masked]
To: Tony Finch <[email-masked]>
Subject: New Version Notification for draft-fanf-dnsop-rfc2317bis-01.txt

A new version of I-D, draft-fanf-dnsop-rfc2317bis-01.txt
has been successfully submitted by Tony Finch and posted to the
IETF repository.

Name:		draft-fanf-dnsop-rfc2317bis
Revision:	01
Title:		Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE
Document date:	2015-11-10
Group:		Individual Submission
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-fanf-dnsop-rfc2317bis-01.txt
Status:         https://datatracker.ietf.org/doc/draft-fanf-dnsop-rfc2317bis/
Htmlized:       https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fanf-dnsop-rfc2317bis-01

Abstract:
   This memo describes how to do IN-ADDR.ARPA delegation on any non-
   octet boundary, and how to consolidate reverse DNS for multiple
   address blocks into one zone.

   It also clarifies the behaviour of dynamic reverse DNS UPDATE
   clients.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Petr Spacek <[email-masked]>
Date: Tue, 10 Nov 2015 17:24:35 +0100

> side processing; if server-side processing is a real suggestion it needs a

Good. The mention about server-side checks was just an example showing that
unauthenticated updates might be good enough in certain situations but this
example is pointless because you have removed references to plain RFC 2136
updates. I'm fine with that.

To answer some of questions from the draft:
> Appendix B. Questions for reviewers
> 
> Is the $GENERATE section a good idea? Should it be ditched? Or
> maybe promoted to its own document?

I would prefer a separate document because this is really a separate issue.

> RFC 2317 is BCP 20. Should this document be moved to the standards
> track, since it updates RFC 2136? Or should the UPDATE amendment be
> a separate document?

Yes, I believe that standards track is appropriate. It can stay in one
document so readers have the context and understand why we are making the change.

> Is the indirection problem specific to classless reverse DNS (which
> is the approach I took) or does it apply to the forward DNS as well?
> Suggestions for wording welcome.

Personally I would mention that this problem is generic to make application
developers aware of it. In the previous exchange I was proposing text similar
to this:

   Please note that this problem is generic. For names outside of
   IN-ADDR.ARPA or IP6.ARPA sub-trees it is up to implementation
   to decide if it is necessary to update alias itself or if it is
   necessary to update endpoint records and thus the method described
   in the section 9.2 needs to be applied.

Is there something wrong with it? It should be just informational.

> Is the detailed UPDATE behaviour sensible?
Definitely yes :-)

-- 
Petr Spacek

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Nov 2015 16:32:23 +0000

Petr Spacek <[email-masked]> wrote:

Thanks again for your feedback.

> Is there something wrong with it? It should be just informational.

My fault, sorry, I missed that paragraph when I was incoporating your
suggestions. I'll add this (or something similar) in the next revision.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Forties: Southwesterly 6 to gale 8, decreasing 4 or 5 later.
Moderate or rough. Rain at times. Moderate or good, occasionally poor.