Hi,
Adding a few comments on this discussion, just one chair’s opinion:
The underlying question in this exchange seems to be what advice should this
document offer, and to whom?
This is a Working Group document, which means the decision about what’s in and
what’s out doesn’t rest with any individual; it belongs to the WG.
The bulk of the document is a description of certain issues that can arise in
name server operation, and tests that can be performed to identify servers that
behave incorrectly or suboptimally with respect to those issues. I’m seeing
several suggestions that those portions of the document might benefit from some
editorial work, but not seeing opposition to publishing them.
At the same time, there’s a question of what sound, credible advice this group
can include in the document. A couple of thoughts on that:
1. I don’t think that citing advice to operators in RFC 1033 as
normative is helpful. Retaining any advice found there should be clearly
justified in terms of current understanding of both protocol and practice.
Besides the changes in how we use language in standards (RFC 2119) since RFC
1033 was written, it’s really hard to argue for the assumption that *anything*
about the way we operate the TCP/IP internet hasn’t changed as it’s grown, or
that *any* advice to operators of the 1980s is automatically relevant to
operators today.
2. In this particular case, the suggested “Remediation” includes advice
that isn’t actionable for many TLD operators, because they’re operationally and
contractually constrained from the recommended action. It may also be passing
up an opportunity to provide advice to others who do have leverage over name
server operators that TLD operators don’t— including registrars and registrants.
The chairs have asked those who have objections to the current “Remediation”
section to “send text” and look forward to review by the WG. We need more
comment/feedback on what advice, if any, should be given in this document.
thanks,
Suzanne
(for the chairs)
> On Oct 18, 2016, at 3:00 PM, Matthew Pounsett <m...@conundrum.com> wrote:
>
>
>
> On 16 October 2016 at 21:15, Mark Andrews <ma...@isc.org
> <mailto:ma...@isc.org>> wrote:
>
> In message
> <CAAiTEH_Tn8YXXe9wYMgobeg0Fd3OdY9M4Rey6QQxh0Yg=g0...@mail.gmail.com
> <mailto:g0...@mail.gmail.com>>
> , Matthew Pounsett writes:
> > >
> > > But not all registries as so constrained. This is BEST current
> > > practice not LOWEST COMMON DEMONINATOR practice.
> > >
> > > GTLD are required to remove records for abuse so removal of record
> > > is expected for some conditions so it is not beyond belief that
> > > they can change to include these reasons. ICANN still has a committee
> > > to maintain the stability of the DNS. Nameserver behavior very
> > > much affects that stability.
> > >
> >
> > The draft can say it would be helpful to take action. The draft can't
> > require action. Requiring action isn't describing a best current
> > practice. That just won't fly on today's Internet.
>
> I've had TLD's saying they want the hard line to be there as it
> backs up their stance.
>
> > If you want to lobby ICANN to modify the gTLD agreements, then we can
> > revisit this discussion. But until those are changed the IETF has no
> > business insisting on contractually prohibited actions.
>
> The IETF can say what is BEST practice. If gTLD's feel they cannot
> meet BEST practice they will not do that. No one can make someone
> follow BEST practice.
>
> Every time I hear "But the gTLD's can't do" I see a conflict of
> interest showing.
>
> The IETF can recommend things that gTLD's can't do today. There
> is nothing wrong with doing that. It puts the IETF's position not
> gTLD operator position.
>
> The problem with the draft is that it doesn't recommend -- it requires.
> 1) It incorrectly references a non-normative RFC as if it were normative.
> 2) It includes imperative statements while claiming to be a description of
> best practice.
>
> Neither of these things are supported by your argument.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
