At Mon, 22 Jan 2018 11:18:08 -0500,
Suzanne Woolf <[email protected]> wrote:
> Please focus feedback on: Is this draft ready to go to the IESG for
> approval as an RFC? If not, can you suggest specific changes it
> needs?
I myself don't have a particular opinion on whether to send it to the
IESG, but I don't think it's ready for it based on my understanding of
the WG discussion so far. In particular, I don't think I saw a wg
consensus about one major objection to the idea: "I'd like to keep my
right of configuring my DNS servers (authoritative or recursive) to
return whatever I want to 'localhost' queries". Again, I personally
don't claim this right, but I see the concern. If my observation is
correct and the WG has actually not reached a clear consensus on this,
I believe it should first achieve it. If I miss a reached consensus,
I wouldn't oppose to it, but I believe the draft should discuss
how/why it justifies dismissing such concerns.
Some specific comments on the 02 version follow.
- (editorial) Section 1:
This increases the likelihood
that non-conformant stub resolvers will not go undetected.
This is a kind of double negation ('not...undetected') and it was
difficult to me to understand it on a first read. I'd suggest
revising it to, e.g:
This increases the likelihood
that non-conformant stub resolvers will go detected.
- Section 2
The domain "localhost.", and any names falling within ".localhost.",
are known as "localhost names".
I'm afraid this definition can be a bit ambiguous. It could read as
if "a.localhost.example.' is a 'localhost name'. I'd suggest:
The domain "localhost.", and any names ending with "localhost.",
are known as "localhost names".
- Section 3
1. Users are free to use localhost names as they would any other
domain names.
It's not clear to me what this sentence means.
- Section 3
7. DNS Registries/Registrars MUST NOT grant requests to register
localhost names in the normal way to any person or entity.
It's a bit awkward to me to use an RFC2119 keyword for what
registries/registrars should (or should not) do.
- Section 5.1
In this
case, the requirement that the application resolve localhost names on
its own may be safe to ignore, but only if all the requirements under
point 2 of Section 3 are known to be followed by the resolver that is
known to be present in the target environment.
I don't understand this sentence, especially the phrase "if all the
requirements under point 2 of Section 3 are known to be followed by
the resolver". Point 2 of Section 3 talks about application
behavior (and I interpret "application" is a user of resolver, not
resolver itself), so what does it mean by "known to be followed by
the resolver"?
- Section 5.2
Hosts like "localhost.example.com" and
"subdomain.localhost.example.com" contain a "localhost" label, but
are not themselves localhost names, as they do not fall within
"localhost.".
I suggest: 'as they do not end with "localhost.".' (see my comment on
Section 2 above).
- Section 6.1
Some application software differentiates between the hostname
"localhost" and the IP address "127.0.0.1".
You might also want to refer to ::1 here.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
