Brian,
Would the following text be then ok? Please note I changed the domain addition
from SHOULD to MAY, if there is going to be attempt to
deprecate/redefine/update search list logics. Or do you think it should remain
SHOULD?
--
4.6. Interactions with DNS search lists
A node may be
Brian,
Do you agree that nodes' behavioral differences between foo and foo.
names is out of the scope of this particular MIF draft?
There could perhaps be another draft, which would say that if name is foo
it should not be appended with search lists but foo. might? And whatever
other differences
(resending only to mailing list recipients)
Brian,
Do you agree that nodes' behavioral differences between foo and foo.
names is out of the scope of this particular MIF draft?
There could perhaps be another draft, which would say that if name is foo
it should not be appended with search lists
On 21 Oct 2011, at 08:21, teemu.savolai...@nokia.com
teemu.savolai...@nokia.com wrote:
Do you agree that nodes' behavioral differences between foo and foo.
names is out of the scope of this particular MIF draft?
In my view neither the draft nor MIF should be encoding any changes to client
I'm not sure where it would belong, exactly, but certainly between
best practices and DNSSEC security concerns, is the basic tenet:
The DNS is a unified namespace.
This leads to a number of potential issues, which can largely be
addressed by viewing the issues from the perspective of a unified
I think we can skirt this rat-hole if we separate the two following
distinct cases:
Case A: foo
Case B: foo. (with terminating dot).
Case B meets the technical requirements of a Fully Qualified Domain
Name, structurally speaking.
Case A does not.
Case A is a bare name, case B is not.
If we
In message CAH1iCiqsN-R87VK3vKityPsY+NXA=0drasyf_vmbsy8gvyw...@mail.gmail.com
, Brian Dickson writes:
I think we can skirt this rat-hole if we separate the two following
distinct cases:
Case A: foo
Case B: foo. (with terminating dot).
Case B meets the technical requirements of a Fully
On Oct 21, 2011, at 3:15 AM, teemu.savolai...@nokia.com wrote:
Brian,
Do you agree that nodes' behavioral differences between foo and foo.
names is out of the scope of this particular MIF draft?
That's not how I would state it. I think handling of foo. is something that
IETF can define,
On Oct 21, 2011, at 3:15 AM, teemu.savolai...@nokia.com wrote:
Brian,
Would the following text be then ok? Please note I changed the domain
addition from SHOULD to MAY, if there is going to be attempt to
deprecate/redefine/update search list logics. Or do you think it should
remain
On Oct 21, 2011, at 3:15 AM,
teemu.savolai...@nokia.commailto:teemu.savolai...@nokia.com
teemu.savolai...@nokia.commailto:teemu.savolai...@nokia.com wrote:
There could perhaps be another draft, which would say that if name is foo
it should not be appended with search lists but foo. might? And
On Oct 21, 2011, at 10:04 AM, Keith Moore wrote:
And honestly I don't see why handling of non-DNS names like foo is in scope
for MIF.
Because such names are typically resolved using DNS search lists, and at lease
one mechanism for setting up search lists is interface-specific.
On Oct 21, 2011, at 11:07 AM, Ted Lemon wrote:
On Oct 21, 2011, at 3:15 AM, teemu.savolai...@nokia.com
teemu.savolai...@nokia.com wrote:
There could perhaps be another draft, which would say that if name is foo
it should not be appended with search lists but foo. might? And whatever
other
On Oct 21, 2011, at 11:13 AM, Keith Moore wrote:
IMO: search lists are useful, but only with bare names - and the behavior of
those should be implementation dependent. Trying to nail it down will break
too much widespread practice.
On a desktop workstation they are useful, because you can
On Oct 21, 2011, at 11:11 AM, Ted Lemon wrote:
On Oct 21, 2011, at 10:04 AM, Keith Moore wrote:
And honestly I don't see why handling of non-DNS names like foo is in
scope for MIF.
Because such names are typically resolved using DNS search lists, and at
lease one mechanism for
On Oct 21, 2011, at 11:19 AM, Ted Lemon wrote:
On Oct 21, 2011, at 11:13 AM, Keith Moore wrote:
IMO: search lists are useful, but only with bare names - and the behavior
of those should be implementation dependent. Trying to nail it down will
break too much widespread practice.
On a
Now that more people are involved in discussions, this bare name / DNS
search list area seems to look like quite a deep swamp without clear IETF
consensus.
Perhaps we should discuss first if this particular topic (=section 4.6) is
needed in this document at all, because, after all, the focus is
Teemu,
I think that the spirit of what you propose is correct, but as Keith points
out it really isn't appropriate to use RFC 2119 language about a pragmatic
approach that clearly lies outside the definition of the DNS namespace.
If an implementor is willing to take the risk of transforming
17 matches
Mail list logo
