Ted Lemon writes:
> On Aug 10, 2017, at 6:07 PM, Toke Høiland-Jørgensen wrote:
>> Now, assuming that I am wrong and this is actually a serious issue that
>> we need to solve (of which I am not opposed to being convinced), I think
>> it would be feasible to come up with a solution where we could
> Juliusz expressed opposition to adoption, but Ray and Michael said the
> reasoning for objection was flawed (that Juliusz was setting the bar too
> high and the procedural objections were not valid in the context of IETF
> procedures).
I probably expressed myself badly -- my objections were tech
On 11/08/2017 12:59, Juliusz Chroboczek wrote:
> In simple terms, I said "Why don't we try implementing bits of this
> document before we adopt". I never said "We need seven interoperable
> independent implementations before adoption".
Juliusz,
IMNSHO, that's still too high a bar.
kind regar
> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
> all queries to router A, using a source address in the same prefix
> as the original request was received from.
> 1b. Router A exports over HNCP that it supports MPvD. Router B uses
> router A's address (which
> - round-robin = bad (think why happy eyeballs came up for example of why)
> DNS resolvers use round-robining. That's how the protocol works.
Does that mean that dnsmasq breaks the protocol?
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a
On 11/08/2017 13:40, Juliusz Chroboczek wrote:
>> DNS resolvers use round-robining. That's how the protocol works.
>
> Does that mean that dnsmasq breaks the protocol?
AFAICR, that's one of those niggly parts of the DNS protocol that is not
strictly specified.
Ray
___
How does the client know in which moved a response is intended to exist.
Also, what problem are you trying to solve here? What you described sounds
like it's just an attempt at implementing mpvd on a homenet without
requiring that all routers behave the same.
On Aug 11, 2017 6:15 AM, "Toke Høilan
Juliusz Chroboczek writes:
>> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
>> all queries to router A, using a source address in the same prefix
>> as the original request was received from.
>
>> 1b. Router A exports over HNCP that it supports MPvD. Router B use
What dnsmasq seems to be doing is trying all servers at once. That would
work too, if the pattern described in the document is followed.
On Aug 11, 2017 8:41 AM, "Juliusz Chroboczek" wrote:
> > - round-robin = bad (think why happy eyeballs came up for example of
> why)
>
> > DNS resolvers us
Ted Lemon writes:
> How does the client know in which PvD a response is intended to exist.
Well, in some cases normal source address selection rules are going to
do the trick (i.e., the client picks the source address closest to the
destination). In others it won't, and the client will get degra
Why do you want it to be optional? What problem are you trying to solve?
Do you not know how to do it? Do you think it's resource intensive? Do you
think it reduces reliability more than not doing it?
On Aug 11, 2017 8:55 AM, "Toke Høiland-Jørgensen" wrote:
> Ted Lemon writes:
>
> > How does
Ted Lemon writes:
> Why do you want it to be optional? What problem are you trying to solve?
> Do you not know how to do it? Do you think it's resource intensive? Do you
> think it reduces reliability more than not doing it?
Because I'm not convinced the added implementation complexity is wort
>>> DNS resolvers use round-robining. That's how the protocol works.
>> Does that mean that dnsmasq breaks the protocol?
>>
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366
> What dnsmasq seems to be doi
> From: Ted Lemon
> Barbara, I seem to recall that you were enthusiastic about the work when it
> was discussed in the meeting. You're allowed to be one of the people who's
> in favor of it, despite being chair. Indeed, as > chair, you can just adopt
> it by fiat if you want. I actually ag
On Aug 11, 2017, at 9:09 AM, Toke Høiland-Jørgensen wrote:
> Because I'm not convinced the added implementation complexity is worth
> it; so yeah, the last one I guess...
This is a refrain I've heard from you, Juliusz and Markus, which I actually
find a bit disturbing: the desire not to really s
The IESG has received a request from the Home Networking WG (homenet) to
consider the following document: - 'Special Use Domain 'home.arpa.''
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive commen
Hi,
On the principle of the WG agreeing to work on the problems as itemised in the
current headings in the table of contents, I support adoption, i.e., it’s
something homenet should work on, but it’s quite possible that the draft when
it moves to WGLC may look somewhat different.
Someone menti
On Fri, Aug 11, 2017 at 10:22 AM, Tim Chown wrote:
> Hi,
>
> On the principle of the WG agreeing to work on the problems as itemised in
> the current headings in the table of contents, I support adoption, i.e.,
> it’s something homenet should work on, but it’s quite possible that the
> draft when
On Aug 11, 2017, at 9:27 AM, Juliusz Chroboczek wrote:
> Can we please agree that this document has no business mandating
> round-robining?
The point of the text on round-robining is to avoid a situation where one
provider's answers wind up being preferred over another provider's because of a
> This is a refrain I've heard from you, Juliusz and Markus, which I actually
> find a bit disturbing: the desire not to really solve the problem because it's
> not trivially easy.
If I were in a bad mood, I'd say that the three of us prefer simple, robust
solutions that solve actual problems to c
On Aug 11, 2017, at 12:07 PM, Juliusz Chroboczek wrote:
>> This is a refrain I've heard from you, Juliusz and Markus, which I actually
>> find a bit disturbing: the desire not to really solve the problem because
>> it's
>> not trivially easy.
>
> If I were in a bad mood, I'd say that the three o
I have moved the doc to the adopted state. Ted/Daniel, you should be able to
upload a WG revision as your next rev.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On Aug 11, 2017, at 12:42 PM, STARK, BARBARA H wrote:
> I have moved the doc to the adopted state. Ted/Daniel, you should be able to
> upload a WG revision as your next rev.
Great, thanks!
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org
Ted Lemon wrote:
> Source-specific routing, however, is an incomplete solution. Having
> chosen the correct route based on the source address, we still have the
> problem that one provider connection may be better than another for
> connecting to a particular destination, and th
On Aug 11, 2017, at 12:53 PM, Michael Richardson wrote:
> The example that, in contrast to all other content, is when content is
> zero-rated via 3G but not via WIFI. (generalized to any two uplinks)
> I don't know the source address selection or source routing can deal with
> that problem period.
> On 11 Aug 2017, at 17:53, Michael Richardson wrote:
>
> Ted Lemon wrote:
>> Source-specific routing, however, is an incomplete solution. Having
>> chosen the correct route based on the source address, we still have the
>> problem that one provider connection may be better than another for
>>
26 matches
Mail list logo