Re: [homenet] Home Networking (homenet) WG Virtual Meeting: 2018-09-04

I believe that this meeting was originally scheduled for 1500 UTC, which would be 1600 Dublin time, not 1100 Dublin time. A time change the day before the meeting is (a) not enough notice and (b) I suspect not what was intended. :) On Mon, Aug 20, 2018 at 12:21 PM, IESG Secretary wrote: > The

Re: [homenet] standard way of configuring homenets

On Wed, Jul 25, 2018 at 1:47 PM, STARK, BARBARA H wrote: > > From: Ted Lemon > > Hm, possibly there's been some miscommunication here: we aren't talking > about using tools developed for managed networks for amateurishly-managed > networks. We are talking ab

Re: [homenet] standard way of configuring homenets

Hm, possibly there's been some miscommunication here: we aren't talking about using tools developed for managed networks for amateurishly-managed networks. We are talking about the problem of making it possible to do some degree of management of homenets. I don't think anybody is assuming that

Re: [homenet] standard way of configuring homenets

ation via a management protocol requires somebody who > knows what they’re doing, it doesn’t fall within my interpretation of the > charter. > > Barbara > > > > *From:* homenet *On Behalf Of *Ted Lemon > *Sent:* Tuesday, July 24, 2018 5:57 PM > *To:* Michael Richardson

Re: [homenet] standard way of configuring homenets

I don't think using HNCP in that particular way is a great plan, but I'm willing to be convinced. I would hope that this is in charter. On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson wrote: > > I very much like the idea of having a standard way to configure homenets. > There is the YANG/N

Re: [homenet] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07

My personal feeling on this is that the off-site backup zone is a service that could be provided by an ISP, could be provided by someone else, or could just be something that a sufficiently geeky user sets up for themself. If an ISP connection is as flaky as you describe, I would think that they

Re: [homenet] (no subject)

You said that having state in the homenet makes it brittle. That implies that you think a stateless homenet will be less brittle, no? On Tue, Jul 24, 2018 at 4:34 AM, Juliusz Chroboczek wrote: > > Juliusz is saying that he wants a nearly stateless homenet; > > No, I'm not. > > > for him, putti

Re: [homenet] (no subject)

it could be a git repo, > > tim > > On Mon, Jul 23, 2018 at 10:43 PM, Ted Lemon wrote: > >> The DNS server in the cloud doesn't have to answer queries. Indeed, it >> probably shouldn't. It's really just a backing store. The >> public/private

Re: [homenet] (no subject)

The DNS server in the cloud doesn't have to answer queries. Indeed, it probably shouldn't. It's really just a backing store. The public/private primary with selective publication is just a functional block—you can put it where it makes the most sense. Juliusz is saying that he wants a nearl

Re: [homenet] (no subject)

On Jul 23, 2018, at 6:10 PM, Juliusz Chroboczek wrote: > What? You're concerned with the homenet losing state when the master is unplugged. By having the master in the cloud, this problem is eliminated. ___ homenet mailing list homenet@ietf.org http

Re: [homenet] (no subject)

On Mon, Jul 23, 2018 at 4:08 PM, Juliusz Chroboczek wrote: > whereas Daniel's draft only allows me to publish my address > if I'm in my Homenet. > One of the reasons I was hassling Daniel at the mic about updating his draft based on implementation experience is that I think it's hard to read th

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Apparently my comment was clear as mud. I meant this: https://tools.ietf.org/html/draft-ietf-opsawg-mud-25 Having a public/private zone pair where the public zone is an image of the private zone that is constructed following rules, the default rule being "don't copy," seems very straightforward

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

One way to automate this would be using mud. On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell wrote: > > (with no hats...) > > On 19/07/18 10:42, Juliusz Chroboczek wrote: > > >> Also, think of the privacy implications if all of the services on the > >> homenet had to be discovered from a shared

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

On Thu, Jul 19, 2018 at 5:42 AM, Juliusz Chroboczek wrote: > > In order for services to be discoverable on the homenet, they have to > > publish their contact info on the homenet. The protocol that everyone > > uses for this is DNSSD. This is how you find your printer when you want > > to print t

Re: [homenet] In-network connectivity and HNCP: IPv6 ULA

I think the local ULA should be used for all intra-ULA connections. We had a debate about this about four years ago, and apparently the text in the HNCP spec reflects the outcome of that discussion, but I think we understand the problem better now and we should fix this. The current SHNA doc requi

Re: [homenet] In-network connectivity and HNCP: IPv6 ULA

Juliusz, with all due respect, if you have a connection over IPv4 and suddenly your IPv4 network is deconfigured, your connection will hang. I know this because that's what happened. This is not good behavior, and should not be the default behavior of homenets. On Wed, Jul 18, 2018 at 10:29 PM

Re: [homenet] In-network connectivity and HNCP: IPv6 ULA

ote: > Ted, > On 19/07/2018 13:36, Ted Lemon wrote: > > In order for IPv6 to be useful, you need naming to work. We had this > > discussion when I brought this up last year. It should be possible for an > > IPv6-only homenet to work. But if we want homenet to be widely adop

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

The trivial update protocol isn't a standard protocol, and doesn't do what we need it to do. In order for services to be discoverable on the homenet, they have to publish their contact info on the homenet. The protocol that everyone uses for this is DNSSD. This is how you find your printer wh

Re: [homenet] In-network connectivity and HNCP: IPv6 ULA

In order for IPv6 to be useful, you need naming to work. We had this discussion when I brought this up last year. It should be possible for an IPv6-only homenet to work. But if we want homenet to be widely adopted, I do not think this is the correct default behavior: it violates the principle of le

Re: [homenet] I-D Action: draft-ietf-homenet-simple-naming-02.txt

e. On Tue, Jul 3, 2018 at 2:16 PM, Michael Thomas wrote: > On 07/02/2018 05:21 PM, Ted Lemon wrote: > > I didn’t get all the updates I wanted to into this version. A lot of the > issues you mention here were discussed in my presentation in London. Will > you be in Montreal? > &

Re: [homenet] one other security related thing

It's mentioned in section 10. I mentioned this more explicitly in the old homenet naming architecture document. Here: https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01#section-4.6 On Tue, Jul 3, 2018 at 2:21 PM, Michael Thomas wrote: > On 07/02/2018 05:19 PM, T

Re: [homenet] I-D Action: draft-ietf-homenet-simple-naming-02.txt

e from the on-line Internet-Drafts > directories. > > This draft is a work item of the Home Networking WG of the IETF. > > > > Title : Simple Homenet Naming and Service Discovery > Architecture > > Authors : Ted Lemon > >

Re: [homenet] one other security related thing

om and unique prefix for .local.arpa? > > Mike > > On 07/02/2018 01:38 PM, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Home Networking WG of the IETF. > > > >

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

FWIW, on the particular topic of name stability, it might be worth consulting https://tools.ietf.org/html/draft-sctl-service-registration-00, particularly section 5, which talks about first-come, first-served name registration. The document is expired because we've been distracted by implementati

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

On May 31, 2018, at 4:27 PM, Michael Thomas wrote: > With a CNAME, you wouldn't need to deprecate the other... it's just an alias > that you have control of. > From the UI perspective, whatever is presenting names to the user can prefer > the human-given name over > the auto-generated name, righ

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

resting problem that would be worth talking about. On Thu, May 31, 2018, 15:06 Michael Thomas wrote: > On 05/31/2018 02:32 PM, Ted Lemon wrote: > > In practice, you just change the device's name in its web ui. Then > > it's starts advertising the new name, and the old na

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

chael Thomas wrote: > On 05/31/2018 02:32 PM, Ted Lemon wrote: > > In practice, you just change the device's name in its web ui. Then > > it's starts advertising the new name, and the old name stops working. > > If you have enough of a model of this to change the name, yo

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

In practice, you just change the device's name in its web ui. Then it's starts advertising the new name, and the old name stops working. If you have enough of a model of this to change the name, you also know enough to select the printer under it's new name. Of course it would be nice if we could h

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

On May 30, 2018, at 1:32 PM, Brian E Carpenter wrote: > Well, let me invent something. I throw together my network and it names > the printers as printer1 and printer2. Being a stickler, I decide to > rename them as Printer 1 and Printer 2. I mess around and find a config file > somewhere and man

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

On May 25, 2018, at 7:18 PM, Brian E Carpenter wrote: > Understood. However, many of us exposed to certain operating systems deeply > hate it when the system thinks it knows what we want better than we do. What > I'm suggesting is that dealing with unexpected and/or faulty human > intervention

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

On May 25, 2018, at 12:21 PM, Michael Thomas wrote: > Optional to implement or optional to deploy? Optional to deploy. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

On May 25, 2018, at 1:49 PM, Brian E Carpenter wrote: > So, the naming system may end up being fully automatic, well or badly > managed by a human, or managed autonomically. The simple naming architecture is fully automatic, but doesn't do as much as we might want. I think that the advanced a

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

This is out of scope for simple naming anyway, so I don't think we need to answer this now. On Fri, May 25, 2018, 12:24 Michael Thomas wrote: > > > On 5/25/18 10:34 AM, Ted Lemon wrote: > > the ability to publish services on the Internet" seems like a > > reasona

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

Thanks for the review, Michael! On May 25, 2018, at 11:59 AM, Michael Richardson wrote: > Ted Lemon mailto:mel...@fugue.com>> wrote: >> The homenet naming architecture consists of two parts: the simple >> naming architecture, and the advanced naming architecture. The >

[homenet] Introduction to draft-ietf-homenet-simple-naming

The chairs requested that we have a discussion on this draft on the mailing list. I've been a bit slack in bringing it up, as you can tell from the lack of any actual discussion. So, I'm bringing it up. I've copied the abstract, introduction and requirements sections to the message below. It'

Re: [homenet] Alvaro Retana's Discuss on draft-ietf-homenet-babel-profile-06: (with DISCUSS and COMMENT)

On May 9, 2018, at 12:29 PM, Alvaro Retana wrote: > My point here is that it is not clear > to me that the WG explicitly reached consensus to change the declaration from > the Chairs/AD. If you read through section 2 of the document, you will not find a requirement stating that Babel or that thi

Re: [homenet] Simple Naming and DNS Privacy

On Mar 29, 2018, at 5:40 PM, Border, John wrote: > I’ll give it a shot… Great, thanks! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Simple Naming and DNS Privacy

On Mar 28, 2018, at 3:07 PM, Border, John wrote: > Makes sense to me… OK. Doesn't have to be anything fancy—just enumerate the attacks that you think we would be protecting against. Does that sound like something you'd be willing to do? ___ homen

Re: [homenet] Simple Naming and DNS Privacy

I think the right way to approach this question is to try to write a security model. On Fri, Mar 23, 2018, 09:54 Border, John wrote: > > Does the simple naming architecture need to deal with DNS privacy > using port 853? Subject to the success of the security boundaries, the > home network

Re: [homenet] security work items - what do we want to do?

On Jan 24, 2018, at 10:39 AM, Stephen Farrell wrote: > While I don't disagree with you, I do still wonder if we'd > not be better off using another term for cases where maybe > all that are involved are a couple of routers in the home, > and where there's no external party, such as google in the >

Re: [homenet] security work items - what do we want to do?

3 AM, Stephen Farrell > wrote: > > > Hiya, > > On 24/01/18 14:55, Ted Lemon wrote: >> I don't know what unmanaged enrollment really looks like, but sure. >> We've mostly been talking about models for managed enrollment, and >> that seems to be the w

Re: [homenet] security work items - what do we want to do?

I don't know what unmanaged enrollment really looks like, but sure. We've mostly been talking about models for managed enrollment, and that seems to be the way the market has been going (with remarkable suck-itude, if the Google Home enrollment process is typical). I think it might be worth

Re: [homenet] I-D Action: draft-ietf-homenet-dot-14.txt

On Nov 20, 2017, at 2:18 PM, Walter H. wrote: > has this draft already become a RFC? It appears to be blocking on an IANA action. Dunno what the status is. It's definitely approved for publication. ___ homenet mailing list homenet@ietf.org https:/

[homenet] Fwd: New Version Notification for draft-sctl-dnssd-mdns-relay-02.txt

er 13, 2017 at 8:29:42 AM GMT+8 > To: "Stuart Cheshire" , "Ted Lemon" > > > A new version of I-D, draft-sctl-dnssd-mdns-relay-02.txt > has been successfully submitted by Ted Lemon and posted to the > IETF repository. > > Name: draft-sctl-dnss

Re: [homenet] support for HNCP in IPv6 CE routers

On Oct 26, 2017, at 2:39 PM, Gert Doering wrote: > "Normal" People just don't buy a second router for their ISP link if they > already have one, or a 3rd and 4th one if they happen to have two ISP > links. Yup. This is why Google Home, Apple Home, Amazon Echo, Eero, Ubiquiti, etc., have failed

Re: [homenet] Fwd: I-D Action: draft-lemon-homenet-babel-security-latest-00.txt

On Oct 25, 2017, at 3:06 PM, Juliusz Chroboczek wrote: > 1. You're using a TLV, which means that the TLV parser runs before auth. > Is this good practice? What about using the packet trailer ? If you aren't using a shotgun parser, it shouldn't matter. > 2. A number of security mechanisms are b

[homenet] Fwd: I-D Action: draft-lemon-homenet-babel-security-latest-00.txt

; >Title : Babel Security Model >Author : Ted Lemon > Filename: draft-lemon-homenet-babel-security-latest-00.txt > Pages : 6 > Date: 2017-10-23 > > Abstract: > This document describes how

Re: [homenet] draft-ietf-homenet-babel-profile: please review Security Considerations

I think that relying on the trustworthiness of a link is not a great plan. It might be better to say something like "this protocol relies on the trustworthiness of the local link. better security can be achieved using babel security [ref]. keying and configuration for babel security is out of

Re: [homenet] I-D Action: draft-ietf-homenet-dot-14.txt

On Sep 1, 2017, at 2:46 PM, Walter H. wrote: > but there still doesn't exist any for company networks, they most commonly use > the domain name 'local', which I already noticed, that this conflicts to RFC > 6762 ... That problem is not within the scope of the homenet working group to address.

Re: [homenet] Benoit Claise's No Objection on draft-ietf-homenet-dot-13: (with COMMENT)

On Aug 31, 2017, at 11:39 AM, Benoit Claise wrote: > I'm probably over simplifying this, which probably makes it more complex. > A little bit too late for this quick telechat today, so let me discuss with > Terry and come back to you. OK. Other uses are ad-hoc uses of the name: e.g., Sky TV in

Re: [homenet] Benoit Claise's No Objection on draft-ietf-homenet-dot-13: (with COMMENT)

I can update the text as follows: As a result, the use of '.home.', both as specified in RFC7788, and for other uses is deprecated. This should not be taken to mean that an explicit allocation by ICANN is superseded; this deprecation refers to uses of '.home.' as

Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12

On Aug 31, 2017, at 3:49 AM, Mark Andrews wrote: > as it is a over specification. Just let IANA manage it. This makes sense--thanks! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

addresses some aspect of the DNS or the process of resolving domain names that would be affected by this special use allocation. Detailed explanations of these items can be found in , Section 5. On Wed, Aug 30, 2017 at 10:34 PM, Dale R. Worley wrote: > Ted Lemon writes: >

Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12

On Aug 29, 2017, at 10:03 PM, Ted Lemon wrote: > Yes. As far as I know the text gives IANA the information they need to do; > I do not know how they operate their black hole servers, so I am trusting > that these instructions are sufficient. They have been reviewed by peop

Re: [homenet] Warren Kumari's Discuss on draft-ietf-homenet-dot-13: (with DISCUSS and COMMENT)

On Aug 30, 2017, at 3:10 PM, Warren Kumari wrote: > 1: Section 4. Domain Name Reservation Considerations, Subsection 4 > If I'm a recursive server and I am configured "with a delegation to an > authoritative server for that particular homenet’s instance of the domain > ’home.arpa.’." then I have

Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

Argh, I spaced out on doing these changes because the security review was so extensive. Sorry about that. I'm making changes to my version of the document, but I will refrain from further confusing the datatracker—assuming that this document is approved tomorrow, I can submit an update with

Re: [homenet] Secdir last call review of draft-ietf-homenet-dot-12

Thanks for the review, Daniel. I've included changes based on your observations inline. On Aug 18, 2017, at 12:43 PM, Daniel Migault wrote: > Abstract > > This document specifies the behavior that is expected from the Domain > Name System with regard to DNS queries for names ending with

Re: [homenet] Genart last call review of draft-ietf-homenet-dot-12

El Aug 24, 2017, a les 7:20 AM, Dale Worley va escriure: > 4. Domain Name Reservation Considerations > > 3. Name resolution APIs MUST send queries for such > names to a recursive DNS server that is configured to be > authoritative for the 'home.arpa.' zone appropriate to the >

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-dot-12: (with DISCUSS and COMMENT)

Oh, Daniel's comment on point 3 is correct, and I've already updated the text based on the gen-art review. :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-dot-12: (with DISCUSS and COMMENT)

I think these secdir comments are actually out of scope for this work (I'll comment in detail inline). In order to mitigate the problems described, we would have to do work that is already being done in other working group documents (e.g. draft-tldm-simple-homenet-naming-01). If you are inte

Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

OK, these both sound like worthwhile updates to the doc. I will add them to my working copy and send proposed diffs later today (I'm in the middle of processing the gen-art review). > El Aug 28, 2017, a les 11:18 PM, Adam Roach va escriure: > > On 8/28/17 5:29 PM, Ted Lemon wr

Re: [homenet] Adam Roach's No Objection on draft-ietf-homenet-dot-12: (with COMMENT)

El Aug 28, 2017, a les 6:07 PM, Adam Roach va escriure: > Section 4 contains a list that it describes as defining "the behavior of [DNS] > systems". Item number 7 seems to be something else: I don't know what code or > configuration would result from this statement. Maybe move this item to > sect

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 18 ag 2017, a les 5:40, Juliusz Chroboczek va escriure: > If the fast connection's DNS server replies after a delay or not at all, > and the slow connection's DNS server replies in a timely manner, using > a smart resolver across all the available DNS servers will improve latenc Yes, but if yo

Re: [homenet] homenet "no host changes" assumption and DNS

I think that what you are proposing here is great, except that I don't think we actually _need_ to go out of charter on this. I think that what Toke has been advocating can be worked into the framework you are describing, so that you and I! get what we want, and Toke gets what he wants. > El

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 17 ag 2017, a les 16:10, Gert Doering va escriure: > 1990s never had uplinks that fast *and* unreliable at the same time > as many of today's consumer ISPs offer. That was my point: you tunnel to the 1990's to get the leased line (a term that I think most people would just squint at nowadays

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

It's never for that purpose. It's to combine to normal connections so as to increase reliability. The scenario you just described would require a wormhole with one end in the 1990s. On Aug 16, 2017 5:25 PM, "Juliusz Chroboczek" wrote: > > I think this is a real edge case. You have two connection

Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA

I tend to agree with Andrew's re-interpretation, but I would add a caveat, which is that at least what I am trying to do is provide a DNS architecture the presence of which will enable devices to have the information and capabilities they need to operate successfully on a multi-homed residential

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 16 ag 2017, a les 9:40, Ted Lemon va escriure: > Ah, if this is your concern, I think that's answered by the whitelisting > stuff I was talking about earlier. But in this case you really do need to > have separate caches per PvD, and the MPvD-aware clients on the net need to

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 16 ag 2017, a les 9:33, Toke Høiland-Jørgensen va escriure: > Ah, I wasn't trying to imply that ISPs deliberately design sub-par > services just to annoy their customers; sorry if it came across that > way. My "broken by design" comment was referring specifically to > DNS-based censorship [1].

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen va escriure: > Ted Lemon mailto:mel...@fugue.com>> writes: > >> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen va >> escriure: >>>> In both of these cases, you are better off doing what we discussed >

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen va escriure: >> In both of these cases, you are better off doing what we discussed >> earlier and setting up your own DNS cache, possibly with a whitelist >> for domains you want to send to the ISP forwarder. > > Sure, and that's what I usually d

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 15 ag 2017, a les 15:38, Toke Høiland-Jørgensen va escriure: >> I think we are wandering off into nonsense territory here. Have you >> observed this sort of problem in the field? If so, can you describe >> what happened? If not, why would we optimize for it? > > If you consider flaky ISP

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 15 ag 2017, a les 7:37, Toke Høiland-Jørgensen va escriure: > Erm, except when the suboptimal path does *not* have substantially worse > performance for the duration of the session? CDNs are used for other > things than Netflix... Simple answer: don't wait five seconds. > What are you basing

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 14 ag 2017, a les 16:21, Juliusz Chroboczek va escriure: > Now, the interaction between source-specific routing, BGP anycast, and > multipath at the higher layers, that's an interesting topic to argue about. I actually disagree, but it's beside the point, because this is a discussion about th

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 13 ag 2017, a les 14:25, Toke Høiland-Jørgensen va escriure: >> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen > > va escriure: >>> In any case, the failure mode of getting a it wrong is a sub-optimal >>> path being chosen; but if ISP A's DNS server takes five seconds t

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen va escriure: > In any case, the failure mode of getting a it wrong is a sub-optimal > path being chosen; but if ISP A's DNS server takes five seconds to > respond, we'd get a better result from just using the timely answer from > ISP B's and going

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 13 ag 2017, a les 9:32, Toke Høiland-Jørgensen va escriure: > Sure. I'm just not sure I agree that MPvD shouldn't also be on the "nice > to have" list, rather than the "absolutely required" list. Why do you think CDNs exist? What would happen if every home network suddenly stopped using the

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

cool, but is out of scope for this document. Does that make sense? On Sun, Aug 13, 2017 at 6:52 AM, Toke Høiland-Jørgensen wrote: > Ted Lemon writes: > > > What I find completely perplexing about this conversation is that you, > > Markus and Toke, all of whom I know to be

Re: [homenet] use of MPvD in homenet

El 12 ag 2017, a les 20:09, Michael Richardson va escriure: > This seems a bit like FUD: the Internet depends upon all sorts of "brittle" > things > like "not deliberately or accidentially" setting up the routing wrong. I get that, and it's possible that MPvD is the wrong answer here. However

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

El 12 ag 2017, a les 13:45, Michael Richardson va escriure: > I agree. It seems like it ought to be a routing protocol at the edge, that > the destinations involved should be advertised with longer prefixes, and with > some kind of metric that implies the cost. The edge routers that hear this >

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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.

Re: [homenet] homenet has adopted draft-tldm-simple-homenet-naming

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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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 writ

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

"Toke Høiland-Jørgensen" wrote: > 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 convi

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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 at least > allow less cap

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

On Aug 10, 2017, at 5:48 PM, Markus Stenberg wrote: > - 3.3 > - it implies that homenet exposes DNS outside home (by default?) and uses > instead custom dns server logic to handle .home.arpa from ‘outside’; why not > just firewall it and be done with it (or listen only on e.g. ULA prefix) No, i

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

On Aug 10, 2017, at 5:07 PM, Toke Høiland-Jørgensen wrote: > with the possible exception of the > requirement for supporting multiple provisioning domains How would you solve the problem of dual-homing without the multiple provisioning domain support described in the document? _

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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 agree with Ray and Michael that J

Re: [homenet] I-D Action: draft-ietf-homenet-dot-12.txt

This revision fixes the problem that Mark Andrews pointed out yesterday with respect to queries for DS records for 'home.arpa.' Before any further action occurs, we should probably wait for Mark, who I assume is enjoying a well deserved night's sleep right now, to see if he's happy with the new

Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?)

ight, and you can point out what I got wrong.) On Tue, Aug 8, 2017 at 11:17 PM, Mark Andrews wrote: > > In message <79597e4d-dec0-4622-a410-003b45eb5...@fugue.com>, Ted Lemon > writes: > > I updated homenet-dot with the change that Mark requested regarding > > signe

Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?)

I updated homenet-dot with the change that Mark requested regarding signed, unsigned and insecure delegations. I believe the text is correct now, but would appreciate a sanity check. Otherwise, I think it's up to the chairs to make the next move.

Re: [homenet] Ted's security talk at IETF99: DNCP Security

iring process in private service discovery. On Tue, Aug 1, 2017 at 8:42 PM, Michael Richardson wrote: > > Ted Lemon wrote: > > So what you're saying is ephemeral is the keying used for the initial > > exchange? > > yes, it's probably more about

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

er both from a security perspective and a usability perspective, but it's not a *good* answer, and I don't think it's possible anyway. On Tue, Aug 1, 2017 at 5:06 PM, Michael Richardson wrote: > > Ted Lemon wrote: > barbara> The CABF is about "publicly trusted

Re: [homenet] Ted's security talk at IETF99: DNCP Security

So what you're saying is ephemeral is the keying used for the initial exchange? On Tue, Aug 1, 2017 at 4:48 PM, Michael Richardson wrote: > > Ted Lemon wrote: > > You agree that it's a different problem right? > > mcr> The common part is that one might

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

On Aug 1, 2017, at 2:53 PM, Walter H. wrote: > is there a problem, to have the organization that has the delegation of > ".home.arpa." also provide such SSL certificates > signed by an intermediate that got signed by any CA? This is not how PKI works. For a browser to trust a signing authorit

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

On Aug 1, 2017, at 2:37 PM, Juliusz Chroboczek wrote: > Think of it as a knob with a wasps' nest behind it. I know how to build it, so no, I don't think of it that way. I can think much worse wasp's nests. One example would be a network with no trust model that encourages end-users to engag

<    1   2   3   4   5   6   7   8   >