Just relaying to the list the comments I made at the mic in the WG session on
Monday...
I did not agree with any of the four choices offered by the chairs to the WG
for the resolution of the RFC 7788 / .home issue.
I've spent a good bit time over the past four years helping people try to
imple
On 20/07/2016 18:32, Andrew Sullivan wrote:
> Except, of course, that's precisely what we have with Bonjour: DNS for
> everything except names ending in local. That label functions as a
> protocol switch to tell your combined resolver which names to resolve
> by mDNS and which ones to resolve b
Hi,
On Wed, Jul 20, 2016 at 02:10:05PM +0200, Ray Bellis wrote:
>
> On 20/07/2016 13:33, Ray Bellis wrote:
>
> > My expectation is that in a Homenet multi-subnet environment I will be
> > able to just use http://./ and just have it work regardless
> > of which particular subnet that device is on
> Current host stacks don't have support for saying "if the suffix is
> ".TBD", go here, otherwise go there.
Right, and I missed this point in my strawman. I guess I've been spoiled
by dnsmasq.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
http
On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:
> On 21/07/2016 01:13, Lorenzo Colitti wrote:
> > On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote:
> >
> >> - it's a bit unclear how an address/prefix's "source" next-hop is kept
> >> in association. The simplistic appro
On 19-Jul-16 18:10, Ted Lemon wrote:
> Please read draft-lemon-sutldr-ps, and participate in the discussion
> about this on the dnsop mailing list. Discussions about the RFC6761
> problem are off-topic for the homenet mailing list. We are customers
> of the existing IETF consensus process as
On Wed, Jul 20, 2016 at 03:13:05PM +0200, Lorenzo Colitti wrote:
> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote:
>
> > - it's a bit unclear how an address/prefix's "source" next-hop is kept
> > in association. The simplistic approach of adding a "PA source ipv6
> > address" for eac
This proposal doesn't satisfy the problem statement.
(which nobody wrote. :)
I don't want to tube on writing a formal requirements doc before we finish
doing a naming architecture, but I think now that I've taken a stab at
this, we should think about our reactions to and see if we can scope the
p
On 21/07/2016 01:13, Lorenzo Colitti wrote:
> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter wrote:
>
>> - it's a bit unclear how an address/prefix's "source" next-hop is kept
>> in association. The simplistic approach of adding a "PA source ipv6
>> address" for each of a host's configured
On Thu, Jul 21, 2016 at 12:59:05AM +1200, Brian E Carpenter wrote:
> On 21/07/2016 00:54, David Lamparter wrote:
> > As mentioned on mic during rtgwg, I think the idea of affecting host
> > source address selection through 6724 rule 5.5 is potentially very
> > useful and IMHO should be explored.
>
On 21/07/2016 00:54, David Lamparter wrote:
> As mentioned on mic during rtgwg, I think the idea of affecting host
> source address selection through 6724 rule 5.5 is potentially very
> useful and IMHO should be explored.
And please note that draft-ietf-6man-multi-homed-host-07 (in IETF Last Call)
As mentioned on mic during rtgwg, I think the idea of affecting host
source address selection through 6724 rule 5.5 is potentially very
useful and IMHO should be explored.
Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached
to this mail. I've been able to gleam a little more
On 20/07/2016 13:33, Ray Bellis wrote:
> My expectation is that in a Homenet multi-subnet environment I will be
> able to just use http://./ and just have it work regardless
> of which particular subnet that device is on [*].
There's a further corollary to this: since we can't mandate host
c
On 20/07/2016 12:01, Ralph Droms wrote:
> Without that definition, I don't think I know where and by whom the
> label will actually be used. Will it turn out to be like .local,
> which, as far as I know, is rarely used anywhere and only ever by a
> certain class of expert user.
I have three
The name should be short, easily recognized, and make some kind of sense.
It is important that the name look reasonable because we want the natural
human pattern matching ability that nearly all users can be expected to
have to notice when someone uses a name that is not quite correct, and to
not r
On Jul 20, 2016, at 12:24 PM 7/20/16, Andrew Sullivan wrote:On Wed, Jul 20, 2016 at 06:05:54AM -0400, Brian Haberman wrote:If the above holds, I would suggest (only partly in jest) a TLD thatcontains a certain unicode value that can be visually displayed by an OS...http://apps.timwhitlock.info/uni
On 7/20/16 12:24 PM, Andrew Sullivan wrote:
> On Wed, Jul 20, 2016 at 06:05:54AM -0400, Brian Haberman wrote:
>> If the above holds, I would suggest (only partly in jest) a TLD that
>> contains a certain unicode value that can be visually displayed by an OS...
>>
>> http://apps.timwhitlock.info/uni
On Wed, Jul 20, 2016 at 06:05:54AM -0400, Brian Haberman wrote:
> If the above holds, I would suggest (only partly in jest) a TLD that
> contains a certain unicode value that can be visually displayed by an OS...
>
> http://apps.timwhitlock.info/unicode/inspect/hex/1F3E0
This is the second time t
On Wed, Jul 20, 2016 at 11:50:05AM +0200, Juliusz Chroboczek wrote:
> willing to ask whether the WG would prefer a name that is short and
> memorable, or one that is long and impossible to remember?
I think the questions that Suz and Ralph have already posted are ones
that must be answered first.
On 7/20/16 6:01 AM, Ralph Droms wrote:
>
>> On Jul 20, 2016, at 11:50 AM 7/20/16, Juliusz Chroboczek
>> wrote:
>>
We want something short and memorable. ".co.uk" is short and
memorable. ".univ-paris-diderot.fr" is not.
>>
>>> Why? This is, I suspect, part of the issue: it seems th
> On Jul 20, 2016, at 5:50 AM, Juliusz Chroboczek
> wrote:
>
>>> We want something short and memorable. ".co.uk" is short and memorable.
>>> ".univ-paris-diderot.fr" is not.
>
>> Why? This is, I suspect, part of the issue: it seems that we have
>> some assumptions about the use of these name
> On Jul 20, 2016, at 11:50 AM 7/20/16, Juliusz Chroboczek
> wrote:
>
>>> We want something short and memorable. ".co.uk" is short and memorable.
>>> ".univ-paris-diderot.fr" is not.
>
>> Why? This is, I suspect, part of the issue: it seems that we have
>> some assumptions about the use of t
>> We want something short and memorable. ".co.uk" is short and memorable.
>> ".univ-paris-diderot.fr" is not.
> Why? This is, I suspect, part of the issue: it seems that we have
> some assumptions about the use of these names, and I'm not entirely
> sure what they are. It is not obvious to me
On 20/07/16 11:10, Andrew Sullivan wrote:
On Wed, Jul 20, 2016 at 12:13:12AM +0200, Juliusz Chroboczek wrote:
- why do you need a word from natural language?
We want something short and memorable. ".home" is short and memorable.
".in-addr.arpa" is not.
"Something short and memorable" is again
Not proposing this seriously, just attempting to explore the design space.
Some of the ideas are due to Toke.
Zones and authoritative nameservers are announced over HNCP together with
their set of addresses, which SHOULD include a LUA and MUST include at
least one IPv6 address. There are two bits
On Wed, Jul 20, 2016 at 12:13:12AM +0200, Juliusz Chroboczek wrote:
> > - why do you need a TLD? Why won't a SLD work?
>
> We want something short and memorable. ".co.uk" is short and memorable.
> ".univ-paris-diderot.fr" is not.
Why? This is, I suspect, part of the issue: it seems that we have
On Jul 20, 2016 00:13, "Toke Høiland-Jørgensen" wrote:
> > These are some fairly ambitious requirements, and I believe that they
> > deserve discussion separately from the naming issue. More precisely:
> >
> > (1) Are wo to go to the effort of specifying and deploying a new ND
option?
Why is thi
> ps - i've read the draft and think it's ready for adoption.
I most humbly disagree. Let's please leave some time for people to think
it over and possibly come with counter-proposals.
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.i
28 matches
Mail list logo
