I may or may not have some architectural/flow diagrams, but I am bit leery of
putting them anywhere (if I were to have them that is) as they were not
officially licensed to be distributed (as the code was) and as this was
Cisco-funded research project back in the day.
I could draw some basic on
On 09.11.2018, at 9.48, Ted Lemon wrote:
> My edge router is an Ubuntu machine. I haven’t been able to get Marcus’ HNCP
> daemon to build there. It’s possible that that has changed since I last tried
> it, but that was what stopped me last time.
It built fine on Debian/Ubuntu last I tried it (
First off, hnetd was team effort - me, Pierre Pfister and Steven Barth.
Secondly, I did not particularly want to promote hnetd but 'existing
implementations are bad, boo hoo' argument gets old and I think e.g.
https://github.com/jech/shncpd is also quite sufficient. I use even
https://github.co
On 08.11.2018, at 19.16, Juliusz Chroboczek wrote:
>>> From a user perspective, there are a few problems:
>> When an interface goes down and then up again, it's renumbered. This
>> includes reboots.
> That shouldn't happen as long as there remains at least one Homenet router
> to maintain the pref
On 7 May 2018, at 22.30, Juliusz Chroboczek wrote:
>> you should refer to 8174.
> Perhaps you could kindly justify your advice? Non-capitalised "must" is
> used just once in this document, and I don't see any opportunity for
> ambiguity.
Perhaps he refers to the RFC8174 update to the boilerplate
On 10 Aug 2017, at 23.33, STARK, BARBARA H wrote:
>
> With one day left in CFA for draft-tldm-simple-homenet-naming, here is my
> summary of what I think I've read.
>
> Exactly 3 people have expressed support for adoption (Daniel [author],
> Michael R, James). Hmm. That's not a lot.
>
> Juliu
On 13 Mar 2017, at 23.58, Ted Lemon wrote:
> Daniel Migault and I have been working on the Simple Homenet Naming
> Architecture. I’ve posted a -00 that I hope we can discuss in Chicago.
S1.1: The assumption in UI is false. The visible services (at least in the
legacy browse mode, e.g. ‘flat l
> On 2 Dec 2016, at 15.50, Juliusz Chroboczek wrote:
> I've just submitted
>
> draft-ietf-homenet-babel-profile-01
>
> It should hit the IETF repository soon, in the meantime, my working copy is on
>
>
> https://github.com/jech/babel-drafts/tree/master/draft-ietf-homenet-babel-profile
>
> T
> On 24 Nov 2016, at 11.36, Juliusz Chroboczek wrote:
>
>>> - who merges data from multiple links? (I'd wish that the hybrid
>>> proxies compute a minimal spanning tree and perform peer-to-peer
>>> magic, but I suspect you're generating a config file dynamically
>>> and restarting dnsmasq whene
> On 24 Nov 2016, at 11.28, Tim Chown wrote:
> In dnssd we have the “stitching” topic on our plate, around operation of
> dns-sd in unmanaged multi-link networks. So this is timely discussion.
>
> We’re beginning work on a BCP for the use of the discovery/advertising proxy
> in enterprise/camp
On 23 Nov 2016, at 21.45, Juliusz Chroboczek wrote:
- ohybridproxy (only really scalable and sensible IPv6 rdns source that
I am aware of, given nodes talk mdns)
>
>>> Noted, thanks for the opinion. I still don't understand how it works (who
>>> gets port 53? how are data from multipl
> On 23 Nov 2016, at 3.34, james woodyatt wrote:
> On Nov 22, 2016, at 14:39, Markus Stenberg wrote:
>>
>> The recent IoT DDoS publicity is a good example; the devices that are the
>> Mirai botnet are devices that had/have open ports facing the internet.
>
On 22 Nov 2016, at 21.47, Juliusz Chroboczek wrote:
>> Now that I have thought about it more, I do not control all devices in
>> my home that well to start with (hello, embedded things that talk IP),
>> and I am not that keen to allow them to punch holes in
>> firewall. Obviously, they can do call
On 22 Nov 2016, at 18.51, Juliusz Chroboczek wrote:
>> I can put that controller into my own home and operate it
> Assuming that you can control the stateful firewall that's running on the
> edge routers. Recall that the edge router is not necessarily on the local
> link, and that there can be mu
On 3 Nov 2016, at 21.26, Brian E Carpenter wrote:
> Yes, I agree it's possible to do better, but what's the incentive for a
> bottom-feeding vendor
> of cheap devices to bother?
I hate to say this, but how about legal solutions? If you sell e.g. guns that
explode if you use them, you are going
For the record, _within limits of current spec/implementation_ MS-Trickle
parameter tuning can make the yo-yo effect arbitrarily rare. However, I think
that the correct way of doing this would be either:
- Also not form neighbor links without indicator that the link is relatively
stable; based
> On 18.7.2016, at 19.55, Ted Lemon wrote:
> Right now HNCP doesn't actually seem to have a TLV for advertising resolvers.
> How does this work now?
DHCP options have also DNS server options (for v4 and v6).
-Markus
___
homenet mailing list
homenet@
On 17.6.2016, at 10.37, Pierre Pfister wrote:
> I think this is a key point indeed.
>
> mDNS works really hard to *not* show any name to the user.
> I would like it to be the same for homenet, but I am not sure we have a
> complete solution for no-name multi-link service discovery for homenet ye
On 9.6.2016, at 19.32, Ray Bellis wrote:
> On 09/06/2016 16:17, Juliusz Chroboczek wrote:
>> I've just fixed shncpd so that it interoperates with hnetd again (by
>> following the IANA registry). But what's to be done longer term? Do we
>> change the IANA registry again, or should somebody publis
On 9.6.2016, at 19.38, Juliusz Chroboczek
wrote:
>>> Do you know if anyone is working on HNCP support for tcpdump and
>>> wireshark? I'm considering giving it out as a student project this
>>> summer, but of course it doesn't make a lot of sense if somebody beats us
>>> to it.
>>>
>>> (I alread
> On 9.6.2016, at 18.38, Juliusz Chroboczek
> wrote:
>
> Dear Markus, dear all,
>
> Do you know if anyone is working on HNCP support for tcpdump and
> wireshark? I'm considering giving it out as a student project this
> summer, but of course it doesn't make a lot of sense if somebody beats us
> On 13.5.2016, at 23.22, Juliusz Chroboczek
> wrote:
> I've just updated shncpd to follow the changes made between the draft
> I had used and RFC 7788. The consequence is that shncpd no longer
> interoperates with the version of hnetd in current OpenWRT head :-/
>
> You can work around that by
On 26.4.2016, at 16.34, Rich Brown wrote:
> Ahhh... This is exactly the kind of advice I was looking for...
>> On Apr 26, 2016, at 9:04 AM, Markus Stenberg wrote:
>>
>>> On 26.4.2016, at 15.09, Rich Brown wrote:
>>>
>>> Thanks for this info. I have
> On 26.4.2016, at 15.09, Rich Brown wrote:
>
> Thanks for this info. I have two primary interests here.
>
> 1) I would like to stop farbling around with configuring subnets in my home.
> :-)
>
> 2) With that knowledge in hand, I'll update the OpenWrt wiki, and include a
> procedure for getti
On 24.4.2016, at 6.03, Ted Lemon wrote:
> Juliusz, the problem is that existing home network devices that do DNS-based
> service discovery do not support DNS update. They could, but they don't,
> because we didn't define an easy way for them to do it. Just 2136 isn't
> enough, because there
On 23.4.2016, at 19.39, Juliusz Chroboczek
wrote:
>> I’m starting by running shncpd on a boundary router and tried a trivial
>> installation.
> Excellent, thanks.
>
>> I don’t see how dns gets updated. Are such updates out of scope of
>> shncpd?
>
> Do you mean, (1) how is a DNS resolver advert
tally poor assumptions.
>
> There was a discussion back in Oct 2015 about running hnetd (I presume) on
> mainstream linux distros (http://bit.ly/1XKc3Oi). Henning Rogge raised the
> question and Markus Stenberg responded that it had been tried on Debian 7.
> The discussion al
On 1.4.2016, at 16.09, Ted Lemon wrote:
> On Fri, Apr 1, 2016 at 3:32 AM, Markus Stenberg
> wrote:
> Section 2.1: It looks interesting. I like having separate naming and
> connectivity provider, if we can pry the reverse delegation off the
> connection providers’ dead hands at
I have partially browsed through the draft. For the record, I am not big fan of
the hybrid solution either as I consider the whole mdns rather ‘loud’ on the
link, and hybrid just makes the solution worse by causing the spam to occur
across multiple links. It is working solution _given current st
On 18.12.2015, at 11.53, Juliusz Chroboczek
wrote:
>> Is there room in the protocol for a router to announce what link type it
>> is on?
> This could be carried by a sub-TLV of Hello (or a sub-TLV of IHU if you
> want to make it per-host).
>
>> I.e., a router on wifi announces wifi and when a ro
> On 14.12.2015, at 8.15, Mikael Abrahamsson wrote:
>
> On Sun, 13 Dec 2015, Juliusz Chroboczek wrote:
>
>> The OpenWRT hnetd configuration redistributes everything, indeed. The
>> recommended shncpd configuration redistributes just hncpd routes:
>>
>> redistribute local deny
>> redistribu
> On 4.12.2015, at 18.51, Stephen Farrell wrote:
> Thanks for addressing my discuss about the options for
> using DTLS. Sorry for being slow with this ballot update.
>
> The comments below are old, I didn't check if you've
> made related changes. Happy to chat about that if you
> want, (or not i
Heya,
thanks for the review :)
> --
> COMMENT:
> --
>
> I support Brian's Discuss.
>
> 1) In Sec 1.1, it states "...in homenet environments where multiple IPv
Thanks for the comments ;)
On 18.11.2015, at 21.42, Alissa Cooper wrote:
> -- How does a node end up in the leaf or guest category? Is it only if a
> fixed category is configured? If so, who decides that that configuration
> should happen? I think this info belongs in the draft.
Steven added som
On 20.11.2015, at 17.50, Barry Leiba wrote:
> I can still be convinced that this is the way to go, but I haven't
> been yet, so let's please talk about it a bit more.
>
> I see your point about the possibility that future DNCP updates could
> change the registry, though that's always a problem, a
> On 20.11.2015, at 17.17, Kathleen Moriarty
> wrote:
>
> Hi Markus,
>
> Thanks for your quick response, inline,
>
> On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
> wrote:
>> On 20.11.2015, at 16.47, Kathleen Moriarty
>> wrote:
>>>>
On 20.11.2015, at 17.13, Stephen Farrell wrote:
> Hmm. I've also setup many small PKIs and don't agree. I do
> think someone could easily make all that quite usable within
> the home. I agree that that hasn't happened to date though.
> (Maybe being a co-author of rfc5280 I probably find all that
On 20.11.2015, at 16.47, Kathleen Moriarty
wrote:
>> It is question of threats <-> risks <-> mitigation analysis. Only thing
>> HNCP security really brings is _in case of insecure L2_ _some_ security for
>> routing/psk state. If we assume every other protocol is secured (e.g. SEND,
>> DHCPv6
> On 19.11.2015, at 16.21, Stephen Farrell wrote:
> (Sorry for the N-th discuss, I quite like this protocol and
> I'm sure we'll get 'em all cleared soon, but... ;-)
>
> I'd like to chat about whether or not the DTLS recommendations
> are correct here. To me, the consensus stuff (from section 8.3
On 18.11.2015, at 16.56, Ted Lemon wrote:
> Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote:
>> HNCP is an amazingly flexible protocol, and one that will hopefully be
>> used well beyond it's original area of application. Many of the possible
>> applications of HNCP don't require DTLS, e
On 20.11.2015, at 12.07, Steven Barth wrote:
>> -- Section 13 --
>> I have two concerns with how the HNCP TLV Types registry is specified:
>>
>> 1. Because the DNCP TLV Types registry specifically allocates 32-511 for
>> profiles, it'd be better to simply limit the range of values in this
>> regi
On 18.11.2015, at 17.02, Steven Barth wrote:
>> -6.4, first paragraph: "Each HNCP node SHOULD announce an IPv6 address
>> and - if it supports IPv4 - MUST announce an IPv4 address,"
>> I don't suppose there's any way we can make IPv6 a MUST?
> I guess we could unify both and make them both SHOULD
> On 2.11.2015, at 14.52, Toerless Eckert wrote:
> Thought maybe other folks beside me would chime in maybe help to ask for this
> for IETF95:
>
> I was trying to play around with Homenet/OpenWrt during the hackathon and
> could not
> nicely build out Homenet connection to the Internet because
On 21.10.2015, at 19.18, Alia Atlas wrote:
> --
> COMMENT:
> --
>
> Thank you very much for addressing my previous Discuss points and
> comments.
> I understan
> On 22.10.2015, at 11.11, Henning Rogge wrote:
> is there already someone who has installed the HNetD software (plus is
> dependencies) on a normal Debian/Fedora Linux distribution? SHNCPD is
> good for a few first tests, but it only contains a subset of the
> useful HomeNet features.
I have. Th
On 29.9.2015, at 23.46, Ben Campbell wrote:
> Thanks for the new appendix B. How should we interpret the "(optional)"
> tag on some of the sections of that appendix? For example, does for the
> Transport Security section, does (optional) mean the section is optional,
> that transport security is o
On 18.9.2015, at 23.58, Juliusz Chroboczek
wrote:
>> * When responding to a multicast request over a multi-access medium,
>> why is the randomization of the transmit time only a SHOULD?
>> I would think that needs to be a MUST.
>
>> Therefore I consider it a SHOULD; certainly, _for s
> On 17.9.2015, at 19.22, Benoit Claise wrote:
> Instead of focusing on the specific questions/answers, the key message is.
> The applicability section doesn’t answer my questions: when to (re-)use this
> protocol?
I still rephrase my previous answer - the one sentence that summarizes (what
int
On 16.9.2015, at 22.46, Kathleen Moriarty
wrote:
> I just have one thing I'd like to discuss that should be easy enough to
> resolve.
>
> Section 8 mentions that DTLS or TLS MAY be used and that it is up to the
> DNCP profile. I'd be interested to see the security considerations that
> would le
On 16.9.2015, at 18.39, Brian Haberman wrote:
A_NC_I calculation does not depend on how you synchronize things
(full state dump <> delta). It is mostly about value <> cost of
having Trickle, as opposed to fixed timers.
What would you propose then?
>>> My proposal is bas
On 16.9.2015, at 23.09, Spencer Dawkins at IETF
wrote:
> Do you think we should insert some sort of disclaimer there about the default
> value to avoid potential misdesign?
>
> I haven't seen people tripping over using TCP keep-alives and assuming they'd
> be more responsive than they are lat
On 17.9.2015, at 12.11, Benoit Claise wrote:
> --
> DISCUSS:
> --
>
> Other ADs focused on the protocol specific points. So let me focus on
> something else.
> T
On 16.9.2015, at 6.43, Spencer Dawkins wrote:
> --
> DISCUSS:
> --
>
> This should be an easy Discuss to ... discuss ...
>
> I'm looking at this text:
>
> If
On 15.9.2015, at 22.10, Brian Haberman wrote:
>>
>> A_NC_I calculation does not depend on how you synchronize things
>> (full state dump <> delta). It is mostly about value <> cost of
>> having Trickle, as opposed to fixed timers.
>>
>> What would you propose then?
> My proposal is based on the
On 15.9.2015, at 20.24, Brian Haberman wrote:
> On 9/15/15 12:52 PM, Steven Barth wrote:
>> Hello Brian,
>> thank you for your feedback.
>>
>>> --
>>> DISCUSS:
>>> -
On 2.9.2015, at 12.26, Henning Rogge wrote:
> the name of the reference to the dnssd-hybrid proxy draft is still
> called "[I-D.ietf-dnssd-hybrid]". This could be fixed in the next
> draft version.
Unfortunately that _is_ their latest version[1] (ping dnssd: make Stuart do
something about it, it
xy Nodes
> Author : Markus Stenberg
> Filename: draft-ietf-homenet-hybrid-proxy-zeroconf-01.txt
> Pages : 16
> Date: 2015-09-02
>
> Abstract:
> This document describes how a proxy functioning between Unicast DNS-
>
On 31.8.2015, at 14.42, Ray Hunter (v6ops) wrote:
> Also DND SD (RFC 6763) states "Address-based Domain Enumeration queries are
> performed using names under the IPv6 reverse-mapping tree" which is under the
> direct control of the individual upstream ISPs.
>
> So, what are people expecting to
On 31.8.2015, at 14.33, Markus Stenberg wrote:
> Sure, you can define link segment name election mechanism and use per-link
> names (they are even mentioned as an option in
> draft-ietf-homenet-stenberg-hybrid-proxy-zeroconf; see also why doing that
> zeroconf might be bad idea),
On 31.8.2015, at 14.17, Henning Rogge wrote:
> On Mon, Aug 31, 2015 at 12:44 PM, Markus Stenberg
> wrote:
>> Let’s assume a shared link with 2 homenet routers (rid1, rid2) and 1 host
>> (foo).
>>
>> Given no election, use of e.g. mDNS to determine hosts/service
s or are specific to the OpenWrt implementation.)
Implementation.
> * Markus Stenberg
>
>> On 31.8.2015, at 13.16, Henning Rogge wrote:
>>> Does homenet even need a “central" DNS server?
>>
>> No. It is per link, not per home.
>
> After converting m
On 31.8.2015, at 13.37, Henning Rogge wrote:
> On Mon, Aug 31, 2015 at 12:34 PM, Markus Stenberg
> wrote:
>> On 31.8.2015, at 13.16, Henning Rogge wrote:
>>> Typical configuration of a cheap router would be to run dnsmasq for
>>> local DHCP and as a DNS cache. If
On 31.8.2015, at 13.16, Henning Rogge wrote:
> On Mon, Aug 31, 2015 at 11:42 AM, Steven Barth wrote:
>>> Now could we achieve this in a multi-link Homenet without any
>>> elections?
>>
>> The primary purpose of the election is to avoid having multiple different
>> zones and names for the same l
On 28.8.2015, at 11.09, Henning Rogge wrote:
> On Fri, Aug 28, 2015 at 9:49 AM, Markus Stenberg
> wrote:
>> On 28.8.2015, at 10.02, Henning Rogge wrote:
>>> So what IS the proposed solution for a decentralized HNCP configured
>>> homenet to share local "con
On 28.8.2015, at 10.02, Henning Rogge wrote:
> So what IS the proposed solution for a decentralized HNCP configured
> homenet to share local "configured" DNS names with the rest of the
> homenet?
For sharing in general, there are two methods (as far as HNCP goes);
- publish a DNS Delegated Zone
On 27.8.2015, at 18.10, Juliusz Chroboczek
wrote:
>>> In short -- the ability within the Homenet to do
>>>
>>>scp backup-20150827.tar mylaptop.home:backup/
>>>
>>> and having it work no matter which link the laptop happens to be connected
>>> to.
>
>> I'd add whether it was connected to Ho
On 27.8.2015, at 15.38, Ray Hunter wrote:
> IMHO This is a very worthwhile discussion that we've glossed over for a long
> time.
>
> I've seen several drafts over the course of the Homenet WG.
>
> e.g.
> https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-03
> discusses
On 27.8.2015, at 9.26, Steven Barth wrote:
>> A few issues may be a concern. The required support of UDP
>> 4000 byte packets in Section 3 DNCP Profile suggests there
>> may be a concern. Section 2.1.4. Amplification Issues of
>> https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threat
> On 26.8.2015, at 16.17, Juliusz Chroboczek
> wrote:
>> I guess we might as well simply recommend MDNS
> Fair enough, assuming there is mDNS proxying in the Homenet. (Or should
> we be speaking on ff05::fb and counting on Pierre to do some magic?)
It is not really an option - it requires serio
On 26.8.2015, at 12.39, Henning Rogge wrote:
> My problem is not with the prefixes assigned to the interfaces of HNCP
> routers itself, my problem is with the prefixes provided to attached
> hosts.
>
> If I understand HNCP right then the "uplink" will announce a prefix
> which should be used by a
On 20.8.2015, at 0.35, Juliusz Chroboczek
wrote:
>> Some sort of review seems advisable. In RFC5226 terms, I'd go for
>> Expert Review at least.
> That would be fine with me.
I am not big fan of expert review, as it can potentially bias what gets
allocated or not.
Tinfoil hat guy in me conside
> On 19.8.2015, at 23.32, Markus Stenberg wrote:
>> On 19.8.2015, at 23.26, Juliusz Chroboczek
>> wrote:
>> If anybody knows how to write a test suite for a routing protocol, I'm
>> interested. I imagine a set of scripts that set up some virtual machines
>&
> On 19.8.2015, at 23.26, Juliusz Chroboczek
> wrote:
> If anybody knows how to write a test suite for a routing protocol, I'm
> interested. I imagine a set of scripts that set up some virtual machines
> and perform some tests, but I have trouble imagining how it could perform
> a test such as t
On 17.8.2015, at 14.19, normen.kowalew...@telekom.de wrote:
> Hi,
>
> +1.
>
> a) Any idea how often this data changes and really needs a re-write in “a
> typical home" ;-) ?
Not very often, at least if you don’t bother to prune ‘old’ stuff much (it
depends a bit, but most conservative setup w
On 17.8.2015, at 9.57, Toerless Eckert wrote:
> On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote:
>> Just like in some other old workplace, cough, ???if it does not work without
>> IPsec, do not expect it to work with it???.
> Should i even try to underst
On 17.8.2015, at 9.22, Toerless Eckert wrote:
> On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote:
>> That may be desirable to limit churn, but must not be depended on. The
>> architecture is explicit on pp 25-26 that renumbering is an expected event:
>> https://tools.ietf.org/html
> On 16.8.2015, at 14.40, Juliusz Chroboczek
> wrote:
> When an HNCP router is restarted, the prefixes it allocated to a link are
> "adopted" by neighbouring routers; if the router then restarts, it will
> agree to the prefixes advertised by its neighbours, which avoids
> renumbering.
>
> Unfor
On 10.8.2015, at 11.23, Erik Kline wrote:
>> Whilst not wanting to de-rail any effort to standardise Babel (since I
>> firmly believe it should be standardised), I'd like to hear the WG's
>> view on having part of our Homenet stack be on Experimental Track
>> instead of PS. E.g., would it affect
Now -09 is available. Changelog (diff is relatively large, but these are the
main parts):
- Reserved 1024+ TLV types for future versions (=versioning
mechanism); private use section moved from 192-255 to 512-767.
- Added applicability statement and clarified some text bas
On 5.8.2015, at 13.08, Mikael Abrahamsson wrote:
>> And then, if people want to talk about additional hypothetical IS-IS
>> capabilities that could be added to a homenet IS-IS, I think they should be
>> required to describe how much memory and other resources would be needed to
>> include that
On 29.7.2015, at 17.35, STARK, BARBARA H wrote:
>
> Perfect! Thanks. I’d missed that. Yes, that’s exactly what I was looking for.
>
>
>
> So when the Design Team compares IS-IS to Babel, they really should be
> comparinghttps://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00
> t
On 29.7.2015, at 15.01, Pierre Pfister wrote:
> Hello Markus,
>
> I could not find-out what french-guy-living-in-Paris you are referring to, so
> I wanted to make sure I at least have the 3rd position. ;)
You probably do. It is clearly a conspiracy.
> I think the complexity about the Endpoint
First of all, thanks a lot again for review comments; I think you are the most
critical reviewer we have had yet, and it helps to improve the document quality
a lot :) We have had a number of reviews by this point, but I believe you have
raised order of magnitude more changes than the second in
> On 23.7.2015, at 10.49, Markus Stenberg wrote:
>
>> On 23.7.2015, at 10.41, Juliusz Chroboczek
>> wrote:
>> Right now, the interaction between the routing protocol and the rest of
>> the stack is very simple and very clean: HNCP redistributes assigned
>&
> On 23.7.2015, at 10.41, Juliusz Chroboczek
> wrote:
> Right now, the interaction between the routing protocol and the rest of
> the stack is very simple and very clean: HNCP redistributes assigned
> prefixes into the RP, and the RP redistributes the default route into the
> RA server. Redistri
> On 23.7.2015, at 9.08, Mikael Abrahamsson wrote:
>
> On Thu, 23 Jul 2015, Markus Stenberg wrote:
>
>> If you want to configure IS-IS metrics using HNCP, I welcome the draft.
>
> I do not really want HNCP to configure it, but hnetd could. I am not sure we
>
> On 23.7.2015, at 6.39, Mikael Abrahamsson wrote:
> On Wed, 22 Jul 2015, Markus Stenberg wrote:
>> Agreed. I think we will remove routing protocol references from HNCP just to
>> be clear, as in practise what we really interact with is the local route set
>> and not the
> On 22.7.2015, at 19.19, David Lamparter wrote:
>
> Fully agree with Brian, Juliusz and the various others - there needs to
> be a mandatory routing protocol, but there's no need at all for HNCP
> need to reference the actual protocol. The HNCP *protocol* works fine
> whatever routing protocol
> On 22.7.2015, at 17.10, Pierre Pfister wrote:
>
> Just throwing an argument that comes into my mind here.
>
> HNCP advertises configuration. Long-lived things.
> It is likely that DNCP is quite inefficient when it comes to changing things
> all the time.
> Metrics can evolve. Particularly w
Thank you for the review.
> On 20.7.2015, at 4.21, Margaret Cullen wrote:
> I support the publication of draft-ietf-homenet-dncp-07. However, I think
> there are a few issues with the document that need to be fixed before it is
> published as an RFC, including:
>
> (1) The document needs a re
On 6.7.2015 13.24, Steven Barth wrote:
What happens when a new router appears on the link, a new election is called, and the new
router becomes the designated DHCPv4 server -- won't address collisions occur? Perhaps
DHCPv4 service should be "sticky", in the sense that a new election isn't
cal
On 4.7.2015 0.28, Juliusz Chroboczek wrote:
Markus, Steven,
Section 4.4 of DNCP says that the NODE-STATE TLVs sent in reply to
a REQ-NODE-STATE MUST NOT contain the optional part. Why is that? If
I've recently republished my own data (e.g. because I gained a neighbour),
it makes sense to me to
internet-dra...@ietf.org
To: Markus Stenberg , Markus Stenberg
A new version of I-D, draft-stenberg-shsp-00.txt
has been successfully submitted by Markus Stenberg and posted to the
IETF repository.
Name: draft-stenberg-shsp
Revision: 00
Title: Simple Home Status Protoco
I inserted preliminary topic to the wiki page (
https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon ). Anyone
can feel free to improve the entry or volunteer to champion (nudge
Pierre :->) by editing the page.
I will provide moral support on Saturday and possibly show up then, but
On 1.7.2015 21.23, Juliusz Chroboczek wrote:
(given neighbor TLVs stay around, and why would they not?).
Milliseconds since origination overflow?
(By the way -- where does it say what a non-originator node should do
when the field overflows?)
In dncp-07. Implementation fixed already :)
Chee
On 2.7.2015 12.55, Juliusz Chroboczek wrote:
You're right, I don't need endpoint except in NETWORK-STATE.
- NetS: need (possibly with delay, to update Trickle state match; we do
Trickle state update last so ordering does not matter)
Well, for HNCP Trickle is per-interface, so it's only really n
On 1.7.2015 14.26, Juliusz Chroboczek wrote:
### NODE-ENDPOINT is stateful
NODE-ENDPOINT identifies the sender of this packet, and applies to all
TLVs in this packet. The current specification implies that the
NODE-ENDPOINT may appear anywhere in the packet, which would force the
receiver to
On 30.6.2015 18.22, Dave Taht wrote:
My request was more dogfooding. a *lot* more dogfooding.
Any practical suggestions on how? Even back in Atlanta in _2012_, there
wasn't that many problems detected when we let rampaging horde play with
the cables (+- few bugs +- Windows XP and ULAs).
I h
On 30.6.2015 15.01, Juliusz Chroboczek wrote:
I've had two surprises trying to interoperate with hnetd.
1. nncp-06 Section 10 says that the Version is 0. hnetd sends and
expects a version field of 1.
Changed the default value to 1 to match the implementations.
2. The same section says the f
On 27.6.2015 2.49, Juliusz Chroboczek wrote:
" If the considered delegated prefix is an IPv6 prefix, and whenever
there is at least one available prefix of length 64, a prefix of
length 64 MUST be selected unless configured otherwise by an
administrator. In case no prefix of length 64
1 - 100 of 225 matches
Mail list logo
