Subject: Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis

From: 神明達哉 <[email-masked]>
Date: Tue, 12 Jan 2016 15:40:37 -0800

At Sun, 13 Dec 2015 22:08:13 -0500,
Tim Wicinski <[email-masked]> wrote:

> This starts a Call for Adoption for draft-fanf-dnsop-rfc2317bis
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-fanf-dnsop-rfc2317bis/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.   Since
> it's updating a prior document, we should discuss whether it's a
> significant update.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> Since this Call for Adoption is around the holiday season, I will run
> this a bit longer.
>
> This call for adoption ends midnight 31 December 2015 UTC.

It's already in 2016 but I don't think I've seen a conclusion
announcement of the call, so: I support the adoption of this
document.  I'm also willing to review subsequent versions.

Some initial, mostly minor comments on the current version:m

- I wonder why its intended status is standards track.  It generally
  just talks about operational techniques rather than describe some
  new protocol, so a BCP seems to be more appropriate (in fact RFC2317
  is a BCP).  Perhaps it's because this document will "update" RFC2136?
  I'm not necessarily opposed to it, but just curious.

- Section 7.5: s/will be still be/will still be/

   transaction (though this benefit should not be exaggerated: the
   records will be still be cached separately and will time out
   independently).  Do however note that the resolver's traversal via

- Section 8

   Similarly, for its IPv6 network 2001:db8:A::/48, organization A again
   asks for a DNAME record, like this:

  I'm not sure why 'a' in '2001:db8:A::' is upper-cased, but if
  there's not a strong reason for it I'd consider lower-casing it,
  applying the recommendation of RFC5952 (whose primary target is not
  literature like I-Ds or RFCs, but I think it's generally better to
  have consistent view in various textual representations of IPv6
  addresses).

--
JINMEI, Tatuya

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 Jan 2016 10:13:42 +0000

>   I'm not necessarily opposed to it, but just curious.

Yes, it's because of the changes to UPDATE. (See the questions for
reviewers in the appendices)

> - Section 7.5: s/will be still be/will still be/

Thanks :-)

>   have consistent view in various textual representations of IPv6

I have used "2001:db8:A::" for the same reason I used "A.example". Is it
too cute?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Northerly 5 to 7, increasing gale 8, perhaps severe gale 9
later. Moderate or rough, becoming very rough later. Snow or snow showers.
Moderate occasionally very poor.

---

From: 神明達哉 <[email-masked]>
Date: Wed, 13 Jan 2016 09:23:14 -0800

At Wed, 13 Jan 2016 10:13:42 +0000,

> reviewers in the appendices)

Ah, okay, I overlooked the appendix.

   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?

With this understanding I have two followup questions:

- If a document is marked as "Updates <Standards Track RFC>", does it
  automatically mean its status should be Standards Track, too?
- Does rfc2317bis really "update" RFC2136 in the first place?  It
  certainly provides some additional client behavior that uses
  RFC2136, but it doesn't seem to require any change to RFC2136 itself
  (am I overlooking something?).

> I have used "2001:db8:A::" for the same reason I used "A.example". Is it

I don't see the reason you used "A.example" either...but in any case
this is a minor point that is probably just a matter of taste, so if
you have a strong preference of this particular style I wouldn't
object.

--
JINMEI, Tatuya

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 13 Jan 2016 13:55:48 -0500

>   automatically mean its status should be Standards Track, too?

It would go in as "Proposed Standard"

tim

---

From: Tony Finch <[email-masked]>
Date: Thu, 14 Jan 2016 13:10:56 +0000

>   (am I overlooking something?).

The purpose of that part of the RFC is to impose extra requirements on
UPDATE clients which are necessary for interoperability. I don't know
exactly how that intent should translate into RFC metadata labels, which
is why I have a question about it in the appendix. So I would really like
advice and opinions from others.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: Southeast backing northeast, 5 to 7, decreasing 4 or 5
later. Moderate, occasionally rough. Rain or sleet. Good, occasionally poor.

---

From: Andreas Gustafsson <[email-masked]>
Date: Sun, 17 Jan 2016 14:35:54 +0200

> advice and opinions from others.

Here's my opinion: Section 9 of the draft should not refer to the
requirements as "requirements for UPDATE clients", but something like
"requirements for entities that update endpoint records in the reverse
tree".  I would consider these entities to be on a higher layer of the
protocol stack than the UPDATE protocol itself.  They may happen to
use UPDATE as the lower-layer mechanism to effect the changes, but
that does not make this a change to the UPDATE protocol, an update to
RFC2136, or a requirement on UPDATE clients in general.

I would even say that the requirement to follow CNAME and DNAME
redirections should apply equally when the updates are not performed
using the RFC2136 UPDATE protocol at all, but using some other
mechanism.
-- 
Andreas Gustafsson, [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Jan 2016 09:55:26 +0000

Andreas Gustafsson <[email-masked]> wrote:
> Here's my opinion:

Thanks :-)

> Section 9 of the draft should not refer to the requirements as
> "requirements for UPDATE clients", but something like "requirements for
> entities that update endpoint records in the reverse tree".  I would
> consider these entities to be on a higher layer of the protocol stack
> than the UPDATE protocol itself.  They may happen to use UPDATE as the
> lower-layer mechanism to effect the changes, but that does not make this
> a change to the UPDATE protocol, an update to RFC2136, or a requirement
> on UPDATE clients in general.

Hmm, I am reluctant to introduce new layering. Is there a precedent for
the distinction you are making?

> using the RFC2136 UPDATE protocol at all, but using some other

What deployed examples do you have in mind? Who here knows how Active
Directory interacts with DNS aliases?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: Northwest 6 to gale 8 decreasing 4 or 5, becoming variable 3 later.
Very rough at first in southeast, otherwise moderate or rough. Showers.
Moderate or good.

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 18 Jan 2016 13:36:53 +0200

> the distinction you are making?

Any web standard could be said to specify "requirements on HTTP clients",
yet most of them don't use that term or update the HTTP specification.

Any mail standard could be said to "specify requirements on SMTP clients",
yet most of them don't use that term or update the SMTP specification.

The requirements in Section 9 should apply to entities like DHCP
servers and IP management systems, whose functionality includes the
management of reverse mappings, and that may contain, call upon, or
(if we must use that term) "be" an UPDATE client to perform the
changes.  But an entity that only serves as an UPDATE client, like
the "nsupdate" program in the BIND distribution, should not be subject
to the requirements because it does not deal specifically with reverse
mappings, but with arbitrary DNS names and records.  Calling them
"requirements on UPDATE clients" when they only apply to entities
that are more than just UPDATE clients seems wrong to me.

> What deployed examples do you have in mind?

The RA-API REST interface used by dyn.com would be one if they only
supported PTR records.  I also recall implementing a different
proprietary update protocol to work around some limitations of RFC2136
as part of the NameSurfer IP management system back in the 90s.

In principle, the draft's requirement to follow CNAMEs and DNAMEs
could even be applied to tools that update zones through mechanized
editing of master files.

> Who here knows how Active Directory interacts with DNS aliases?

Not me...

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Jan 2016 12:34:34 +0000

> yet most of them don't use that term or update the SMTP specification.

I meant precedents specific to DNS UPDATE.

> that are more than just UPDATE clients seems wrong to me.

Right, Mark Andrews made the same point in response to Petr Spacek's
earlier draft. I tried to write the requirements so that they take
this into account but I know the text can be improved.

Can you point to specific wording that needs changing?

I want to avoid having to write a taxonomy of different kinds of UPDATE
clients; I think it is more straightforward to talk about the kind of
modification some software is trying to make to the DNS and therefore how
it should construct an UPDATE message.

There's also the question in the appendix about DNS UPDATE and aliases in
the forward DNS. It's similar to the reverse DNS problem, except that
you're more likely to get varying answers to the question of whether to
update records at the given owner name or at its canonical name. I found
it too difficult to describe it clearly the first time round so I punted
and kept to Petr's tighter scope.

> as part of the NameSurfer IP management system back in the 90s.

More details might be helpful :-)

> could even be applied to tools that update zones through mechanized

Right.

In a lot of cases the APIs require you to specify the zone you are
modifying (this is true for UPDATE and the Gandi API, for instance) which,
as you say, implies that a client must have already canonicalized the name
before calling the API, if that is what it needed to do.

I will try to cover this kind of situation. Thanks for the discussion, it
has helped to get things clearer in my head. We shall see if I manage to
get them clearer in words :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin, Hebrides, Bailey: East or southeast 4 or 5, occasionally 6 at first.
Rough or very rough in Bailey, otherwise moderate or rough. Rain or showers.
Good, occasionally poor.

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 18 Jan 2016 17:56:24 +0200

> I meant precedents specific to DNS UPDATE.

RFC 4703 specifies DNS UPDATE behavior for one class of clients
without updating RFC 2136, and without framing it as a "requirement
on UPDATE clients".

> Can you point to specific wording that needs changing?

Mainly, the "Updates: 2136", and each instance of "UPDATE client".
For example, in the Introduction, you could change

   While these methods interoperate well with DNS resolvers, they
   require some care from dynamic DNS UPDATE clients that are trying to
   change IN-ADDR.ARPA mappings.  The client needs to follow the CNAME
   and/or DNAME redirections so that its UPDATE request changes the
   canonical PTR record without disrupting the redirections.

to something like

   While these methods interoperate well with DNS resolvers, they
   require some care from entities that update IN-ADDR.ARPA mappings,
   such as DHCP servers and IP management systems.  These need to
   follow the CNAME and/or DNAME redirections so that the update
   changes the canonical PTR record without disrupting the redirections.

If you would like more text, let me know.

> it should construct an UPDATE message.

I think the need for a taxonomy of UPDATE clients is best avoided by
not using the term "UPDATE client" at all, as RFC 4703 does.

> and kept to Petr's tighter scope.

I think that is the right choice - this draft is about reverse
mappings, so any discussion of managing forward mappings is out of
scope.  If it were in scope, I would make a similar argument as in the
reverse case, that the question of whether to update the CNAME or the
records it points to should not be resolved at the level of RFC 2136,
but in the higher-layer entity that manages the forward mapping (or,
as the case may be, manages the CNAME involved in the forward
mapping).

> More details might be helpful :-)

What details would you need?  My main point was just that DNS update
protocols other than RFC 2136 do exist, and now that you mentioned
Gandi, it reminds me that there's also the Amazon Route 53 API.
I'm sure there are many more.

> get them clearer in words :-)

Great, thanks!

---

From: 神明達哉 <[email-masked]>
Date: Mon, 18 Jan 2016 10:01:52 -0800

At Mon, 18 Jan 2016 17:56:24 +0200,

>    changes the canonical PTR record without disrupting the redirections.

FWIW, this makes much more sense to me than "Updates: 2136".  I also
agree with this rationale:

At Mon, 18 Jan 2016 13:36:53 +0200,

--
JINMEI, Tatuya