t; which indicates that the client may leave the session open longer than
> indicated by the inactive timer of the server. However section 7.1.1 say that
> the client MUST close the connection when the timer is expired.
A connection with an active mDNS relay
one implements procedures and controls at a high level."
(Quoted from [RFC6841], Section 2)
I’m unclear on what these mean. Can we add more explanatory text?
These states are
defined in [RFC4033] and [RFC4035], although the two definitions
differ a bit.
Can we elaborate with more details about *how* these definitions differ?
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
rfect solutions
and picking the less bad one. Moving forward we expect that most application
protocols that need security will only run over TLS, making this “dual
personality” behavior rare.
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
OT send a Retry Delay DSO request message or DSO
unacknowledged message to a server. If a server receives a DNS
request message (i.e., QR=0) where the Primary TLV is the Retry Delay
TLV, this is a fatal error and the server MUST forcibly abort the
connection immediately.
The updated draft
l-dnssd-mdns-relay>
Service Discovery Broker
<https://tools.ietf.org/html/draft-sctl-discovery-broker>
We welcome others to join us at the Hackathon. Please let us know if you’d like
to come along and join in the testing.
Stuart Cheshire
___
DNS
“localhost”.
Stuart Cheshire
[*] If you think it’s stupid to suggest a host might not treat “127.0.0.1” as
meaning loopback, why is that any more stupid than suggesting that a host might
not treat “localhost” as meaning loopback? Both are just as arbitrary
mething that would be useful for all DNS servers. Think of it as a
different protocol, that happens to leverage existing DNS protocols and message
formats instead of inventing new protocols and message formats.
The draft explains it in more detail.
DNSOP feedback on the draft would be appreciated
he DNS Push document, but I
think it would be better to have that specification in the keepalive document.
Thoughts?
Stuart Cheshire
Begin forwarded message:
> From: internet-dra...@ietf.org
> Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt
> Date: 21 March 2016 at 16:58:41 Pa
-names-problem seems to focus far too
intently on the issue names. (But then, that is what ICANN is in the business
of selling, so maybe it’s not surprising.) The substance of RFC 6761 is about
enabling special behaviours, and using special names to trigger those spe
get one of these new flying cleaning robots, which
can be located (as it was in your example), “in the right-upper corner of a
living room.”
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
them $10/year, say) to use that
home gateway product in their own home. Such products ship today with “.home”
hard-coded into them, and all our pontificating about registration processes is
not going to change that.
Stuart Cheshire
___
DNSOP mailing
and submit a quick two-page draft describing the usage would
be a wonderful contribution to greater IETF understanding of what’s going on.
Observing that certain weird names are hitting the root name servers is a
useful first step. Understanding *why* that’s happening would be even better.
Stuart
community, for someone to step forward and tell us
*why* those names are in use, are leaking out to the root name servers, and
what the intended use is for these names. (I assume that “leaking out to the
root name servers and getting NXDOMAIN” is *not* the intended use.)
Stuart Cheshire
as desired, for reasons 4, 5,
and 6 above.
Stuart Cheshire
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
14 matches
Mail list logo
