Re: I-D Action: draft-west-let-localhost-be-localhost-00.txt

[Mike West <[e-mail]>]

Sorry I missed this, Patrick. Responding inline:

On Fri, Sep 30, 2016 at 4:06 PM, Patrick McManus <[e-mail]>
wrote:

> Hey Mike,
>
> A few thoughts, sadly mostly about process rather than merits. sorry about
> that.
>
> 1] You've got HttpBis at the top of that document - but I don't think this
> is something httpbis would adopt (the word http does not appear anywhere
> else in the doc other than url references) as its scope is really about DNS
> libraries servers and registrars, not about the http protocol.
>

Yup. It was just part of the boilerplate I copied over from the cookie
drafts I'm working on. I agree that DNSOP seems like a better home, and I
don't intend to bring this draft to httpbis.


> 2] Given that this is about DNS libraries servers and registrars, don't
> you think this should be part of the DNSOP wg discussion?
>

Yup.

3] This seems to boil down to NEWRFC changes a bunch of RFC6761 SHOULD's to
> MUST's. Obviously publishing NEWRFC doesn't make anyone non-compliant with
> 6761, so how does this help in making you confident enough in
> localhost==127.0.0.1 to use that in secure contexts? i.e. what's the
> indication the name is resolved according to NEWRFC rules?
>

If only specifying something caused compliance! :)

I plan for Secure Contexts to say something like "A user agent MAY treat
localhost names as secure iff it conforms to the localhost name resolution
rules in let-localhost-be-localhost."


> 4] you say '"localhost names will always resolve to the respective IP
> loopback address". That suggestion, unfortunately, doesn't match reality.'
> but you don't provide any background. That reality will be intentionally
> prohibited by this document so I would like to understand the instances
> where this happens a little better, what they are accomplishing, etc...
> you've obviously got some examples. Thanks.
>

I'll add examples to the doc, thanks for the suggestion.

-mike