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

[神明達哉 <[e-mail]>]

At Sun, 13 Dec 2015 22:08:13 -0500,
Tim Wicinski <[e-mail]> 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