[homenet] I-D Action: draft-ietf-homenet-dncp-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Distributed Node Consensus Protocol Authors : Markus Stenberg Steven Bar

Re: [homenet] Greetings

Hello, I am also a student at the École Polytechnique and an intern at Cisco. I am working on a mostly unrelated topic, but I came to a situation where I realised that DNCP could prove very useful. I am writing an internet draft about this use-case for DNCP, outside of the home network, and I i

[homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Outsourcing Home Network Authoritative Naming Service Authors : Daniel Migault

Re: [homenet] [hackathon] homenet in Hackathon

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

Re: [homenet] Concerns about HNCP

> > So it's essentially a vendor extension encoded as either an IP or a domain > name? It is partly opaque if you are referring to that, but even for domain names you could find potentially clever uses like telling your resolver to use the associated DNS-servers for a special domain (only). I gues

Re: [homenet] Concerns about HNCP

>> If a node is assigning prefixes smaller than /64 (or /24 in IPv4), how >> does it prevent fragmentation of the available space? > IIRC that is defined in the prefix assignment draft. Right. Smart draft. >> ### Prefix Domain is not clear [...] > The prefix domain TLV is used to convey some me

[homenet] Debuggability [was: Concerns about HNCP]

>> Is a passive node allowed to use a non-standard port? If so, which TLVs >> are to be honoured from a non-standard port? I suggest: only requests, >> with NODE-ENDPOINT ignored. > The draft - in its current version - does not really mandate that, so at > the moment implementations must be read

[homenet] Preliminary WG Session Agenda

The preliminary WG Session Agenda for IETF 93 in Prague is now online at Ray and Mark. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [hackathon] homenet in Hackathon

Hi Pierre, Yes, we can make it happen. Friday is an optional setup day for those with special equipment to setup or configure. Just be sure to be wide awake and fully caffeinated on Monday morning when we kick things off Saturday morning. We will provide plenty coffee to help with that. As for reg

Re: [homenet] [hackathon] homenet in Hackathon

Hello, I have been quite implied in homenet for the past almost two years and would be happy to ‘champion’ these subjects. We also have 3 guys here who are quite motivated to work on those subjects (they subscribed to the Hackathon already). Two little problems on my side: - I did not register t

Re: [homenet] More about state desynchronisation in DNCP

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

Re: [homenet] Concerns about DNCP

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

Re: [homenet] Concerns about DNCP

>> You've almost convinced me, so I'll just note that the same issue exists >> with the NODE-ADDRESS TLV in HNCP -- there's no reason to flood this >> information beyond the local link. In that case, the amount of state >> spuriously flooded could be moderately large (24 bytes per router per >> at

Re: [homenet] Concerns about DNCP

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 needed in order to update last_contact. > -

Re: [homenet] Concerns about HNCP

Hi Juliusz, thanks a lot for your comments. Replies inline. Cheers, Steven > Packet format and transmission > -- > > ### Port and IP > > Is a passive node allowed to use a non-standard port? If so, which TLVs > are to be honoured from a non-standard port? I sugg

Re: [homenet] Concerns about DNCP

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