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 www.ex
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 on
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 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 f
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 lar
On Oct 21, 2011, at 11:07 AM, Ted Lemon wrote:
> On Oct 21, 2011, at 3:15 AM,
> 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 differences in their handling would be, an
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 3:15 AM,
mailto:teemu.savolai...@nokia.com>>
mailto: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 differences in their handling wo
On Oct 21, 2011, at 3:15 AM, 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 SHOULD?
> --
> 4.6. Int
On Oct 21, 2011, at 3:15 AM, 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, but handling of
In message
, 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 Qualified Domain
> Name, structurally speaking.
> Case A
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
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
On 21 Oct 2011, at 08:21,
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
name resolution behaviour that depend on the "ba
(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 li
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 diff
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 confi
17 matches
Mail list logo
