from:"Tim Chown"

Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

2023-01-17 Thread Tim Chown

Thank you for the update Daniel, I am overall happy with the changes. I
suspect ULAs will be picked up by other reviews.

Tim

On 13 Jan 2023, at 19:17, Daniel Migault wrote:

Hi Tim,

Thanks for the feed backs. Please see how the document has been updated. The
ULA comment may remain open.
https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/cbf182af1bf749f09348a178268d62b745c3d6d6

You can also find some more description / comments inline.

Thanks for the follow-up!
Yours,
Daniel

On Thu, Jan 12, 2023 at 10:28 AM Tim Chown
mailto:tim.ch...@jisc.ac.uk>> wrote:
Hi,

In-line...

On 9 Jan 2023, at 18:15, Daniel Migault
mailto:mglt.i...@gmail.com>> wrote:

Hi Tim,

Thanks for the review we updated the file as follows:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/038395265e821aeeb59ccd3b1ba50c4dbf831a3b

Please see my responses in line for more details.

Yours,
Daniel

On Thu, Jan 5, 2023 at 10:12 AM Tim Chown via Datatracker
mailto:nore...@ietf.org>> wrote:
Reviewer: Tim Chown
Review result: Almost Ready

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.

This document describes an architecture by which names and IP addresses of
hosts or services may be made available in the public DNS through the use of a
homenet naming authority (HNA) and associated (hidden) primary DNS function
resident in the home network and a DNS outsourcing infrastructure (DOI)
function which through a distribution manager also acts as a secondary. Methods
for synchronisation and control of the information between the HNA and DOI are
presented.

I would say this document is getting close to being Ready, but still has issues.

A significant problem is that the document is not particularly well written.
The quality of the text is poor, with at least six typos or mistakes in just
the initial two paragraph abstract, which does not put the reader in a good
frame of mind to read the main body of the document. There are mistakes
throughout the document. I would suggest that a full check, from start to
finish, is required before the draft can progress.

It may be the fact that the draft is now over 10 years old means it has been
“cobbled” over a long period and perhaps it therefore doesn’t flow as well as
it would were it written from scratch today.

General comments:

The introduction section introduces a lot of new terms and language, and notes
on how various elements and components are related, and communicate. A clear
diagram would be really helpful here. There is one in 5.1, but a high-level
one in section 1 would improve the document.

You are probably right, but when we tried we almost ended up in repeating the
figure of section 5.1 and finally removed it. If this is not essential, I would
prefer to leave it as it is.

The trouble is you are very familiar with the work. It’s a bit of a brick wall
to those reading it for the first time, especially with so many new terms being
used for things that could be referred to with more familiar terms. I would
strongly recommend a figure early on, but obviously it’s up to the IESG as to
what they want to see.

I have added a simplified figure of the architecture that I think is readable.
Otherwise, I am ok with the general principle of what is proposed, i,.e. a
‘hidden’ primary and a secondary in the DOI part, feeding the publicly
accessible servers. But this could also be done with a standard DNS approach -
should thus be noted and a section added pointing out the pros and cons of each
approach?

I suppose the standard approach you are referring to is the use of DNS UPDATE.
If that is the case, we tried to have such a section to state differences
between the two methods and removed it. The main difference is that DNS UPDATE
does not update the zone itself but of course one could update each RRset of
the zone.

Well, I don;’t think the primary has to live in the home network, for example.
I don’t think this draft describes a bad idea, but presenting the trade-offs
may be useful. Or perhaps that’s a separate draft.
In our case the HNA builds the zone so if the HNA is not in the home network
that becomes a very specific case. I agree there could be a way the HNA may be
split in to sub functions. In my mind we provide a basic use case, which can
be further declined in more specific ways, and I agree that these specificites
should be the purpose of other drafts. At least that is what I intend to do for
the specific case we have.
I thought your initial comment was about comparing briefly DNSUPATE and this
proposal. W

Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

2023-01-12 Thread Tim Chown

Hi,

In-line...

On 9 Jan 2023, at 18:15, Daniel Migault wrote:

Hi Tim,

Thanks for the review we updated the file as follows:
https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/038395265e821aeeb59ccd3b1ba50c4dbf831a3b

Please see my responses in line for more details.

Yours,
Daniel

On Thu, Jan 5, 2023 at 10:12 AM Tim Chown via Datatracker
mailto:nore...@ietf.org>> wrote:
Reviewer: Tim Chown
Review result: Almost Ready

Hi,

I would say this document is getting close to being Ready, but still has issues.

General comments:

You are probably right, but when we tried we almost ended up in repeating the
figure of section 5.1 and finally removed it. If this is not essential, I would
prefer to leave it as it is.

Otherwise, I am ok with the general principle of what is proposed, i,.e. a
‘hidden’ primary and a secondary in the DOI part, feeding the publicly
accessible servers. But this could also be done with a standard DNS approach -
should thus be noted and a section added pointing out the pros and cons of each
approach?

I would like to see, perhaps as an Appendix, a clear list of steps that would
happen, to go from the starting point (presumably arrangement for the domain(s)
and startup of the HNA function) to a steady operational state, maybe even as a
state diagram. This could include a clearer view of how the user updates the
information they wish to make available. There’s hints of parts of this in the
document, but not a whole view.

The purpose of the draft is to set a primary / secondary to outsource the zone.
How the domain name is acquired, how the zone(s) are populated and how the HNA
is implemented / deployed in the home network can be very complex and can be
done in so many ways. We provided some hints but I fear the scope could be way
too large. I suspect that the companion document DHCP options provide more than
what you ask for but in the narrow scope of an ISP providing names and DOI. I
agree it would be good if we have a more standard way, but currently I prefer
that we remain focused on one functionality we want to implement.

Perhaps an example, the simplest example, could be presented?

Is the HNA typically a function in the home router? Do we expect CPE vendors
to implement this? Whic

Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

2023-01-06 Thread Tim Chown

Hi,

On 6 Jan 2023, at 13:36, Eric Vyncke (evyncke)  wrote:

Well-deserved break for the R community, I also took about 10 days off ;-)

More seriously, there was a major rewrite between -18 (the first IESG telechat) 
and -25 (yesterday telechat):
https://author-tools.ietf.org/iddiff?url1=draft-ietf-homenet-front-end-naming-delegation-18=draft-ietf-homenet-front-end-naming-delegation-25=--html

But you are correct, even my French-reading eye spot two grammar errors: "needs 
to be made available" (rather than "need") and "how an this" (rather weird).

I can see at least:

This home -> their home
Needs to -> need to
IP address -> IP addresses
Are present in the -> are made available in the ?
On the behalf -> on behalf
Home owner -> home network owner
How an this -> how the

And then the bold claim about IPv6 making access simpler :)

But I think as an abstract it should better summarise the document.  This is 
probably a symptom of it being a document that’s been 10 years in the editing 
pot.  It’s ended up as an interesting idea, as the community feedback has been 
included, but there are gaps in details, and much that would lead many to 
prefer Experimental status at this stage.

As you may have read in the Homenet WG list [1], there are some ways forward 
about the intended status. Let's wait for authors/WG/IETF community feedback.

I’ve not read that recently.

Tim

Regards

-éric

[1] https://mailarchive.ietf.org/arch/msg/homenet/dnGJ6yFaTDNU1yUPB0q7n-47EKo/

From: Tim Chown mailto:tim.ch...@jisc.ac.uk>>
Date: Friday, 6 January 2023 at 14:03
To: Eric Vyncke mailto:evyn...@cisco.com>>
Cc: "int-...@ietf.org<mailto:int-...@ietf.org>" 
mailto:int-...@ietf.org>>, 
"draft-ietf-homenet-front-end-naming-delegation@ietf.org<mailto:draft-ietf-homenet-front-end-naming-delegation@ietf.org>"
 
mailto:draft-ietf-homenet-front-end-naming-delegation@ietf.org>>,
 "homenet@ietf.org<mailto:homenet@ietf.org>" 
mailto:homenet@ietf.org>>, 
"last-c...@ietf.org<mailto:last-c...@ietf.org>" 
mailto:last-c...@ietf.org>>
Subject: Re: Intdir telechat review of 
draft-ietf-homenet-front-end-naming-delegation-25

Hi Eric,

Sorry, the R world closes for 2 weeks over the holiday period :)

I just read the IESG comments now, and your comment that "The flow and the text 
(grammar, English) had also a rewrite”, but the diffs from 24 (my review) to 25 
(new) are very
minor and the abstract for example still has six typos or errors in just two 
paragraphs.  I don’t think any of the errors confuse semantics, but it’s in a 
very poor state compared to other draft that I’ve reviewed at a close to Ready 
state.

The suggestion to move it to Experimental is good, imo.

Tim


On 6 Jan 2023, at 11:56, Eric Vyncke (evyncke) 
mailto:evyn...@cisco.com>> wrote:

Thank you very much Tim for your review for int-dir.

Even if a little too late for the IESG telechat, I am sure that the authors 
will take your review in consideration. I personally like your suggestion to 
add an appendix section on the deployment/operation timeline.

Regards


-éric


On 05/01/2023, 16:12, "Tim Chown via Datatracker" 
mailto:nore...@ietf.org> <mailto:nore...@ietf.org>> wrote:


Reviewer: Tim Chown
Review result: Almost Ready


Hi,


I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.


This document describes an architecture by which names and IP addresses of
hosts or services may be made available in the public DNS through the use of a
homenet naming authority (HNA) and associated (hidden) primary DNS function
resident in the home network and a DNS outsourcing infrastructure (DOI)
function which through a distribution manager also acts as a secondary. Methods
for synchronisation and control of the information between the HNA and DOI are
presented.


I would say this document is getting close to being Ready, but still has issues.


A significant problem is that the document is not particularly well written.
The quality of the text is poor, with at least six typos or mistakes in just
the initial two paragraph abstract, which does not put the reader in a good
frame of mind to read the main body of the document. There are mistakes
throughout the document. I would suggest that a full check, from start to
finish, is required before the draft can progress.


It may be the fact that the draft is now over 10 years old means it has been
“cobbled” over a long period and perhaps it therefore doesn’t f

Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

2023-01-06 Thread Tim Chown

Hi Eric,

Sorry, the R world closes for 2 weeks over the holiday period :)

I just read the IESG comments now, and your comment that "The flow and the text 
(grammar, English) had also a rewrite”, but the diffs from 24 (my review) to 25 
(new) are very
minor and the abstract for example still has six typos or errors in just two 
paragraphs.  I don’t think any of the errors confuse semantics, but it’s in a 
very poor state compared to other draft that I’ve reviewed at a close to Ready 
state.

The suggestion to move it to Experimental is good, imo.

Tim

On 6 Jan 2023, at 11:56, Eric Vyncke (evyncke)  wrote:

Thank you very much Tim for your review for int-dir.

Even if a little too late for the IESG telechat, I am sure that the authors 
will take your review in consideration. I personally like your suggestion to 
add an appendix section on the deployment/operation timeline.

Regards


-éric


On 05/01/2023, 16:12, "Tim Chown via Datatracker" mailto:nore...@ietf.org>> wrote:


Reviewer: Tim Chown
Review result: Almost Ready


Hi,


I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.


This document describes an architecture by which names and IP addresses of
hosts or services may be made available in the public DNS through the use of a
homenet naming authority (HNA) and associated (hidden) primary DNS function
resident in the home network and a DNS outsourcing infrastructure (DOI)
function which through a distribution manager also acts as a secondary. Methods
for synchronisation and control of the information between the HNA and DOI are
presented.


I would say this document is getting close to being Ready, but still has issues.


A significant problem is that the document is not particularly well written.
The quality of the text is poor, with at least six typos or mistakes in just
the initial two paragraph abstract, which does not put the reader in a good
frame of mind to read the main body of the document. There are mistakes
throughout the document. I would suggest that a full check, from start to
finish, is required before the draft can progress.


It may be the fact that the draft is now over 10 years old means it has been
“cobbled” over a long period and perhaps it therefore doesn’t flow as well as
it would were it written from scratch today.


General comments:


The introduction section introduces a lot of new terms and language, and notes
on how various elements and components are related, and communicate. A clear
diagram would be really helpful here. There is one in 5.1, but a high-level
one in section 1 would improve the document.


Otherwise, I am ok with the general principle of what is proposed, i,.e. a
‘hidden’ primary and a secondary in the DOI part, feeding the publicly
accessible servers. But this could also be done with a standard DNS approach -
should thus be noted and a section added pointing out the pros and cons of each
approach?


I would like to see, perhaps as an Appendix, a clear list of steps that would
happen, to go from the starting point (presumably arrangement for the domain(s)
and startup of the HNA function) to a steady operational state, maybe even as a
state diagram. This could include a clearer view of how the user updates the
information they wish to make available. There’s hints of parts of this in the
document, but not a whole view.


Is the HNA typically a function in the home router? Do we expect CPE vendors
to implement this? Which begs the question are there at least two independent
implementations of what is described in this text? Is what’s written here
theory, or has it been proven? The ideas for this approach have clearly been
around for some 10 years at least.


The HNA signs the zone for DNSSEC, but is this a MUST? DNSSEC is mentioned
many times, but this is unclear. In 5.1 and in 6.1 the sentence about this
doesn’t say MUST, but later in section 11 it does. If it is a MUST, say so
earlier. Of course, DNSSEC is not exactly pervasive as it is.


Specific comments:


Abstract:


“The names and IP address of the home network are present in the Public Homenet
Zone by the Homenet Naming Authority (HNA)“ - “are present” needs correcting.


“Home networks are increasingly numbered using IPv6 addresses, which makes this
access much simpler.” - well, it means global addresses are available, but the
issues of for example naming, numbering, firewalling and appropriate access
control remain.


Section 3:


ULA use here should be very strongly discouraged. For a “Public Homenet Zone”
should we not use strong language for GUA? Documents talking about ULAs tend
to ta

[homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

2023-01-05 Thread Tim Chown via Datatracker

Reviewer: Tim Chown
Review result: Almost Ready

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document describes an architecture by which names and IP addresses of
hosts or services may be made available in the public DNS through the use of a
homenet naming authority (HNA) and associated (hidden) primary DNS function
resident in the home network and a DNS outsourcing infrastructure (DOI)
function which through a distribution manager also acts as a secondary. Methods
for synchronisation and control of the information between the HNA and DOI are
presented.

I would say this document is getting close to being Ready, but still has issues.

A significant problem is that the document is not particularly well written. 
The quality of the text is poor, with at least six typos or mistakes in just
the initial two paragraph abstract, which does not put the reader in a good
frame of mind to read the main body of the document.  There are mistakes
throughout the document.  I would suggest that a full check, from start to
finish, is required before the draft can progress.

It may be the fact that the draft is now over 10 years old means it has been
“cobbled” over a long period and perhaps it therefore doesn’t flow as well as
it would were it written from scratch today.

General comments:

The introduction section introduces a lot of new terms and language, and notes
on how various elements and components are related, and communicate.  A clear
diagram would be really helpful here.  There is one in 5.1, but a high-level
one in section 1 would improve the document.

Otherwise, I am ok with the general principle of what is proposed, i,.e. a
‘hidden’ primary and a secondary in the DOI part, feeding the publicly
accessible servers.  But this could also be done with a standard DNS approach -
should thus be noted and a section added pointing out the pros and cons of each
approach?

I would like to see, perhaps as an Appendix, a clear list of steps that would
happen, to go from the starting point (presumably arrangement for the domain(s)
and startup of the HNA function) to a steady operational state, maybe even as a
state diagram. This could include a clearer view of how the user updates the
information they wish to make available.  There’s hints of parts of this in the
document, but not a whole view.

Is the HNA typically a function in the home router?  Do we expect CPE vendors
to implement this?  Which begs the question are there at least two independent
implementations of what is described in this text?  Is what’s written here
theory, or has it been proven?  The ideas for this approach have clearly been
around for some 10 years at least.

The HNA signs the zone for DNSSEC, but is this a MUST?  DNSSEC is mentioned
many times, but this is unclear.  In 5.1 and in 6.1 the sentence about this
doesn’t say MUST, but later in section 11 it does.  If it is a MUST, say so
earlier. Of course, DNSSEC is not exactly pervasive as it is.

Specific comments:

Abstract:

“The names and IP address of the home network are present in the Public Homenet
Zone by the Homenet Naming Authority (HNA)“ - “are present” needs correcting.

“Home networks are increasingly numbered using IPv6 addresses, which makes this
access much simpler.” - well, it means global addresses are available, but the
issues of for example naming, numbering, firewalling and appropriate access
control remain.

Section 3:

ULA use here should be very strongly discouraged. For a “Public Homenet Zone”
should we not use strong language for GUA?  Documents talking about ULAs tend
to take a long time to get published :)

Section 4:

In 4.1.1 the method in bullet point 3 seems very ugly.

Section 5:

In the diagram, does the DOI in fact cover the public authoritative servers,
given you say “The DOI will serve every DNS request of the Public Homenet Zone
coming from outside the home network.“ As it is the diagram shows the DOI only
populating the public authoritative servers?

In 5.2 does “protected” mean provision of confidentiality?

Section 6:

In 6.1, “perhaps and” ?

In 6.5, the use of a DNS zone transfer to provide commands seems ugly.

Section 12:

Talks about power cycling of the HNA.  This implies it’s resident on specific
hardware, but what is expected or recommended?  COPE an d HNA are sometimes
used interchangeably in the document.

Section 14:

The document “exposes a mechanism” ?

In 14.4, maybe mention here if any special considerations for a replacement CPE
(and thus HNA if that model its used) are needed?

Tim

Re: [homenet] standard way of configuring homenets

2018-07-24 Thread Tim Chown

On 25 Jul 2018, at 04:13, Ted Lemon mailto:mel...@fugue.com>> 
wrote:

Well, the charter certainly says that we're supposed to think about homenet's 
impact on manageability.   Granted, that's a thin reed to hang on, and it would 
probably be better to make the charter more explicit.   But to be clear here, 
all home networks have user interfaces, and this is all we are talking about.   
We've somewhat skirted the issue, but if we want to be able to have an 
enrollment process, that's going to have a user interface.   If we want to be 
able to do things like change the SSIDs, that's going to require a user 
interface.

In my mind, the idea of homenet is not to be an unmanaged network, but to be a 
network that doesn't require management to operate.   If you don't do any 
managing, it should still work.   That doesn't mean that doing some managing is 
a bad thing.   And if we don't specify something in this regard, I'm afraid 
we're going to wind up with lots of homegrown management UIs that force people 
to buy all their homenet routers from a single vendor.

There’s brief discussion of this in RFC 7368, where I recall some text was 
added in response to an Ops Area AD’s input, see 
https://tools.ietf.org/html/rfc7368#section-3.8.2

Tim


On Tue, Jul 24, 2018 at 10:59 PM, STARK, BARBARA H 
mailto:bs7...@att.com>> wrote:
 Since homenet is supposed to be about an unmanaged network, 
and configuration 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 mailto:homenet-boun...@ietf.org>> On 
Behalf Of Ted Lemon
Sent: Tuesday, July 24, 2018 5:57 PM
To: Michael Richardson mailto:mcr%2bi...@sandelman.ca>>
Cc: homenet mailto:homenet@ietf.org>>
Subject: 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 
mailto:mcr+i...@sandelman.ca>> wrote:

I very much like the idea of having a standard way to configure homenets.
There is the YANG/NETCONF method, and I think that we should go in that
direction.

A thought I had though could a HOMENET configuration be recorded by
capturing just HNCP traffic?  Could a network configuration be restored
by essentially playing back that stuff?  I'm pretty sure that this won't
work, but the question is... should it?

Does this work fit into the charter?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  
http://www.sandelman.ca/
|   ruby on rails[



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Opsdir last call review of draft-ietf-homenet-babel-profile-06

2018-02-26 Thread Tim Chown

Reviewer: Tim Chown
Review result: Has Nits

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.

This draft specifies the subset of the Babel protocol and its extensions that
is required by an implementation of the Homenet protocol suite, as well as the
interactions between Babel and HNCP.

This draft reads well, is clearly written, and includes good, concise
rationales for the stated requirements.

The draft is Ready for publication, with minor Nits.

I only have two minor comments:

Abstract:


You say "This document defines the subset of the Babel routing protocol and its
extensions that a Homenet router must implement"

but the REQs are a mix of MUST and SHOULDs, not "musts", so perhaps use the
sentence in paragraph two of Section 1, i.e.:

"This document specifies the exact subset of the Babel protocol and its
extensions that is required by an implementation of the Homenet protocol suite."

Section 2.1


REQ1: IPv4 also has "link local" addresses, under 169.254.0.0/16, as per RFC
3927, so perhaps here make it clearer why IPv6 link locals make implementations
simpler and more reliable (or why IPv4 link locals do not).  I know what you
mean, but given the document defines IPv4 and IPv6 requirements, a little extra
clarity here might be useful.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2017-08-11 Thread Tim Chown

> 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
>> connecting to a particular destination, and there may be no way to
>> figure that out using the default source address selection algorithm,
>> or even by using a more detailed source address selection algorithm
>> configured by DHCP.   Indeed, this is likely, not unlikely.
> 
> My problem with the MPVD solution is that it seems incomplete too.
> 
> 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.
> 
> It seems to me that we are re-inventing SHIM6, trying in vain to pretend we
> never heard of that.  And I still don't understand why it was killed.

Extension headers.

> But, again, I want to adopt the document so that we can argue about this
> as part of our charter work.

Indeed! 

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

2017-08-11 Thread Tim Chown

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 mentioned that RFC7368 is not cited; it would be useful for this draft 
to clarify where it is compliant, where it is not, and why.

Tim 

> On 9 Aug 2017, at 22:35, STARK, BARBARA H  wrote:
> 
> Thanks Daniel. And you’re not too late. The call ends this coming Friday. So 
> if anyone else wants to chime in, please do. I’ll try to create a summary 
> Thursday describing what I think I’ve heard so far. That should give everyone 
> a brief chance to tell me how badly I’ve misinterpreted their statements 
> before the call ends.
> Barbara
>  
> From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Daniel Migault
> Sent: Wednesday, August 09, 2017 2:37 PM
> To: Michael Richardson 
> Cc: homenet@ietf.org
> Subject: Re: [homenet] The HOMENET WG has placed 
> draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"
>  
> Hi, 
> 
> I apology for the late response (I was off for two weeks). I will update the 
> draft by the end of the month integrating numerous feed backs we received.
> 
> As a co-author I am supporting the adoption of this document architecture. I 
> believe that given the current situation regarding homenet and naming, the 
> simple but useful scope of the draft will help the WG to move forward 
> regarding naming and home network. I agree the document is not yet in a final 
> version and feed back from the WG will be very helpful. That said I think, 
> since last IETF, we have a pretty good view on where we are going.
> 
> Yours, 
> Daniel
>  
> 
>  
> 
>  
> On Mon, Jul 31, 2017 at 10:07 AM, Michael Richardson  
> wrote:
> Ted Lemon  wrote:
> > to put the CFA on hold pending that update. There have been some good
> > comments already, though; in particular, I think Juliusz' point that it
> > would
> > be nice to actually try some of this in practice is good, and is what
> > I'm
> 
> We require interoperable implementations for Internet Standard, not to adopt
> a document.  Implementation reports would be good for WGLC, not here!
> We need to lower the bar here, not raise it.  WGs can abandon documents too.
> 
> > That said, what I said in the working group is that we've been spinning
> > our wheels on this for several years, and I wanted to know if the scope
> > of this is reasonable and is what the working group wants to take
> > on. If it's not,
> > then I don't actually know how to proceed.
> 
> I think that it's the right approach, and given the sort out of the MVDP,
> I support adoption.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>  
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

2017-06-30 Thread Tim Chown

> On 30 Jun 2017, at 10:14, Toke Høiland-Jørgensen  wrote:
> 
> Toke Høiland-Jørgensen  writes:
> 
>> Ted Lemon  writes:
>> 
>>> I think it would be worth presenting your work, yes. In addition to this, 
>>> I've
>>> been working with Stuart Cheshire on an enhancement to the hybrid proxy 
>>> that I
>>> expect to present in Prague. It would be interesting to tie your work in 
>>> with
>>> that. I'm going to write up some initial documents that talk about this in 
>>> the
>>> next couple of days. The work we are doing will happen in dnssd, not 
>>> homenet,
>>> but it's directly related to the work I've been doing on the homenet naming
>>> architecture, and will be reflected in the next version of that document.
>>> 
>>> I don't know if your work is more something that should be presented in 
>>> homenet,
>>> or should be presented in dnssd, or some combination. We should talk about 
>>> this
>>> once the documents are out.
>> 
>> ACK. Let me know when that is :)
> 
> Ping?

The deadline for draft updates or new drafts is 3rd July.

tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

2016-11-24 Thread Tim Chown

On 23 Nov 2016, at 19: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 multiple links merged?), but I intend to
do my homework.

I give dnsmasq port 53, and then have it forward queries for .home
(chuckle) and my IPv4/IPv6 reverses in .arpa-land to 127.0.0.1:54 where
ohp listens on my routers.

Ok, makes sense (except for the choice of 54).  Two more questions:

 - 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 whenever the set of hybrid proxies changes.)

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/campus networks, where there is administrative configuration, and 
scalability is a concern. The stitching topic would likely form part of a 
corresponding BCP for unmanaged operation, as per a multi-link homenet.

 - who speaks mDNS?  The Hybrid proxies?  Or do they communicate with
   a dedicated mDNS speaker?

The proxies ask about (discover) services on the link(s) they serve on behalf 
of the (remote) querier. For general info on how dns-sd works, see 
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05, Section 5 in particular.

For info the “hybrid proxy” has been renamed the “discovery proxy”, which will 
be reflected in the -06 draft, and Stuart will be publishing a separate 
“advertising proxy”, which will allow (remote) proxy advertisements of services 
in addition to proxy discovery of them.  For more info on that, see 
https://www.ietf.org/proceedings/97/slides/slides-97-dnssd-hybrid-proxy-00.pdf

The other thing to be aware of is that there is “long lived query” support for 
the proxies being defined via the DNS Push Notifications and DNS Session 
Signalling drafts (https://tools.ietf.org/html/draft-ietf-dnssd-push-09 and 
https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-01). These allow 
clients to get timely notifications of changes.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

2016-11-23 Thread Tim Chown

On 23 Nov 2016, at 15:23, Ca By > 
wrote:



That said, given HOMENET's charter to be the ideal network we always wanted 
without the technical debt, i suggest HOMENET take a strong stance and reject 
"crunchy core, soft middle" security approach.  Meaning, assuming that some 
other device is going to do security for you and you can leave a default 
password telnet open that idea needs to die.

We need to make sure that HOMENET does not have a diagram that says "security 
done here" with an arrow pointed at the gateway.  HOMENET needs to specifically 
mandate all nodes have sane security, and part of that is ripping off the 
band-aid / security blanket of "stateful firewall"... the popular notion that 
stateful firewall does anything meaningful is very damaging to ecosystem... 
mostly because it makes security the responsibility of some other node 
which is not ok.

Part of the “problem” is that the Homenet security architecture is not yet 
documented. It was somewhat punted during the discussions towards RFC 7368, 
with Section 3.6 mentioning RFC 6092 and RFC 4864, without being prescriptive - 
https://tools.ietf.org/html/rfc7368#section-3.6.

I have my doubts that any attempt to flesh that out further now would reach 
consensus, but given we’ve now moved on quite a way, e.g. knowing we have HNCP, 
Babel, etc, and having witnessed Mirai, it might be worth a try. Something for 
the chairs…?

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] About Ted's naming architecture presentation and document

2016-11-22 Thread Tim Chown

On 21 Nov 2016, at 19:34, james woodyatt 
> wrote:

On Nov 16, 2016, at 17:31, Michael Richardson 
> wrote:

But, do you agree that publishing your home lighting controller to the DNS is
how you manage to control your lights from your phone when you are out of
wifi distance, as you roam to 3G. (I switch to 3G when I get to the front of
my rather modest driveway, as the AP is in the back of the basement)?

If anybody is currently shipping, or has announced plans to ship, any kind of 
home automation device that does this, please speak up on the mailing list. I’d 
like to calibrate my perhaps mistaken apprehension that nobody would seriously 
consider doing this. Everyone I know in this field plans to do this by 
providing a single public rendezvous point with high availability servers that 
communicate in turn to home automation controllers acting as private clients.

There are certainly many devices I access directly in my home, e.g. webcams, 
media servers, but these are not real home automation devices, and not 
providing “mission critical” functions. They mostly work via web ports and, 
where IPv4-only, require an amount of port mapping shenanigans. I do have some 
IPv6 services running in my home that I access remotely.

The challenge with home automation is that there’s a particular need for that 
service to be both secure and reliable (high uptime). Obviously Mirai has 
highlighted the problem of insecure IoT in the home, especially through access 
via default passwords being left in place.

That said, there are examples of home automation companies that have stopped 
trading, leaving the devices in the home useless. Similarly with some “Internet 
toys” that require the mothership to still be in orbit for them to work. 
Non-proprietary devices/protocols are perhaps as important as the architecture 
itself.

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] .home leakage

2016-11-15 Thread Tim Chown

Hi,

For info, here’s the Version report on .home (and other) leakage:
http://techreports.verisignlabs.com/docs/tr-1130008-1.pdf

Though having heard Stuart’s comments, I’m in agreement with those.

Tim



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] write up of time without clocks

2016-11-04 Thread Tim Chown

Hi,

On 4 Nov 2016, at 08:34, JORDI PALET MARTINEZ
> wrote:

Exactly. Same as we have regulations like UL, FCC, EC, etc., the same
certifications must care about a minimum set of security, upgradeability, etc.,
features.

So the extra cost for the vendors is almost cero if we are talking about the
same certifications entities, just new test added to the actual sets.

If you don’t comply the certification, your products will not be accepted in
customs from a very high number of countries, so you will be somehow forced to
follow them.

The question here, is homenet the right venue for creating those minimum
requirements?

Perhaps contribute to draft-moore-iot-security-bcp-00?

See https://tools.ietf.org/html/draft-moore-iot-security-bcp-00

This was submitted at the Seoul deadline. Authors copied.

Tim

Regards,
Jordi

-Mensaje original-
De: homenet > en
nombre de "STARK, BARBARA H" >
Responder a: >
Fecha: jueves, 3 de noviembre de 2016, 21:19
Para: Markus Stenberg >,
Brian E Carpenter
>
CC: Philip Homburg
>,
"homenet@ietf.org"
>, Juliusz Chroboczek
>
Asunto: Re: [homenet] write up of time without clocks

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?

My reading of the tea leaves: either the industry creates its own
certification plan, or the regulators will do it for us.
Here is a data point:

https://www.euractiv.com/section/innovation-industry/news/commission-plans-cybersecurity-rules-for-internet-connected-machines/
In the US, both the FCC and FTC are showing keen interest.
I'd rather the industry get there first.
And, BTW, it's also been suggested that devices list their "end of life"
date when they're sold. After which no updates may be provided. And
remotely-triggered "kill switch" may be used if a bad vulnerability is
discovered after that date.
Another recommendation is default passwords be unique per device, and not
easily determined from MAC address, firmware revision, etc., and be changeable.
That is, it's not just about upgradability. It is also passwords,
encryption, and messaging/promises/guarantees that are made.
Just like cars now have seatbelts, front and side airbags, crumple zones,
and lemon laws.
There are a number of industry whitepapers coming out on this topic, and
conferences/meetings being held. It's all the rage right now.

Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware that
any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Naming: a strawman counter-proposal

2016-07-25 Thread Tim Chown

On 20 Jul 2016, at 14:27, Ted Lemon > 
wrote:

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 problem we are 
trying to solve in a bit more detail than just "naming and service discovery on 
home nets."

I think we came to this conclusion in dnssd too, from you seeding the 
discussion in the context of service discovery in a “flat namespace homenet" 
there.

Tim


On Wed, Jul 20, 2016 at 11:27 AM, Juliusz Chroboczek 
> wrote:
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 associated with each
authoritative nameserver:

  - default: set to 1 if the zone is suitable for name registration without
explicit user configuration;
  - public: set to 1 if the zone is visible from the public internet.

When a router joins the homenet, it MAY announce itself as the new
authoritative nameserver for a zone.  It SHOULD do so if there is no
default public or private zone.

If there are two default private zones or two default public zones, we
call an election, Highlander-style.  If there are two authoritative
nameservers for the same zone, we call an election.

There are no secondaries.  If there are secondaries, their configuration
is outside the scope of this mail.

Stateful DHCP servers SHOULD register their clients with the authoritative
nameserver for the default private zone using your favourite unicast
mechanism.  Clients MAY register themselves with any zone currently
announced (they learn the server addresses through HNCP snooping or a from
new ND option, I don't care).

mDNS proxying into the default private zone is allowed.  Or recommended,
I'm not sure, only implementation experience will tell.

Why exactly am I speaking nonsense?

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My comment about Ted's naming draft

2016-07-19 Thread Tim Chown

Hi,

On 18 Jul 2016, at 23:51, Ted Lemon > 
wrote:

I think it's should in the sense that there may be done reason not to do it on 
some case and we don't want to preclude that because there is no protocol 
reason to do so, but we expect that it will be allocated unless there is some 
good reason. We talked about this at length a couple of years ago and captured 
the intent in the architecture doc, but maybe not in enough detail?

The problem with making statements in RFC7368 was doing so while keeping 
consensus; the more detail you add, the harder it is to keep consensus. There 
was consensus on “should”, and some rationale was given.

Of course since then we’ve found that omitting detail (like more specifics on 
the routing protocol, in particular) did come back to bite us later in that we 
really only deferred the decision.

Also, RFC7368 does not use RFC2119 language.

Tim

On Jul 18, 2016 23:28, "Juliusz Chroboczek" 
> wrote:
> Why wouldn't you allocate one?

I would.  ULAs are a goodness.  Probably.  I'm planning to add ULA
generation to shncpd at some future date, and perhaps even enable it by
default.

The question is about the level of MUSTiness.  I only see two reasonable
possibilities:

  1. ULA is SHOULD, and we cannot rely on their existence;
  2. ULA is MUST, which puts an additional requirement on implementations,
 but allows us to rely on their existence except during reconvergence.

No compromise between these two positions is possible.  It is not reasonable
to say that ULA is SHOULD while simultaneously relying on their existence,
which is what we're apparently trying to do.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788 and ".home"

2016-07-18 Thread Tim Chown

Hi Ted,

On 18 Jul 2016, at 15:03, Ted Lemon > 
wrote:

Zero.   See the discussion in draft-tldr-sutld-02 on this topic (search for 
.home).

I don’t see “home” explicitly cited in 
https://tools.ietf.org/html/draft-tldr-sutld-ps-02, but it’s an interesting 
read nonetheless.

Tim


On Mon, Jul 18, 2016 at 3:33 PM, Mikael Abrahamsson 
> wrote:

The option 4 mentioned updating RFC7788. It's not clear to me what this update 
would be.

.HOME has not been handed out by ICANN yet, what's the odds that RFC6761 
process reserving .HOME for special use would succeed?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] use of .home

2016-07-18 Thread Tim Chown

Hi,

I was going to say two things at the mic before we ran out of time.

First, that I agree with Ralph on his comments about requirements.

Second, as Stuart pointed out, use is already being made of .home, e.g. it’s 
used by BT in the UK. There are articles online that suggest 500M hits/day to 
the roots for .home, and that .home is the heaviest used unallocated TLD. Which 
I assume is in no small part why ICANN chose to not allocate the TLD, instead 
marking it (and .corp) as a “high risk” TLD, due to existing use. For an 
example, see 
http://domainincite.com/13773-home-gets-half-a-billion-hits-a-day-could-this-put-new-gtlds-at-risk.
  Of course *how* .home is being used is another question, but it’s effectively 
not allocatable elsewhere.

Tim



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

2016-05-11 Thread Tim Chown

Hi Ray,

On 11 May 2016, at 15:01, Ray Hunter (v6ops) 
<v6...@globis.net<mailto:v6...@globis.net>> wrote:

Tim Chown wrote:
On 25 Apr 2016, at 03:39, Ted Lemon <mel...@fugue.com<mailto:mel...@fugue.com>> 
wrote:

On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
<j...@pps.univ-paris-diderot.fr<mailto:j...@pps.univ-paris-diderot.fr>> 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.

I'd be grateful if you could expand on that.  Why can't we define a way
for clients to do DDNS?

We can and should.   The problem is that we won't see that code ship in new 
devices anytime soon, so we still have to make mDNS work.

And this is why the dnssd WG is focused on making mDNS work on multi-subnet 
networks.
That to me seems to be putting pragmatism before requirements.

To an extent it is. The Bonjour protocols are much more widely implemented and 
deployed than DNS Update.

I'm not entirely convinced by the dnssd work, and have said so on the relevant 
WG.

Do you mean the need for it based on Bonjour, or the solution given we’re 
building on that?

Note that one requirement was that other SD protocols could be integrated into 
the hybrid proxy model. That’s still possible, but no one has expressed any 
interest as yet.

But Ted has raised the question of DNS Update there, and we agreed in BA that 
we’d accept a draft on issues around coexistence of mDNS and DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the line, is it 
sensible to pull this into Homenet now?

I think this is why Ted is doing what he is doing.  Homenet is a different 
environment - smaller and unmanaged, generally.

Is that the intended question to be answered by that draft?

The question is what happens in environments where both might mix.  Well, 
that’s one question.  Ted offered to draft a -00 on that topic, in one of his 
spare moments ;)

> Just 2136 isn't enfough, because there's no authentication scheme,

I don't understand this argument.  How is non-secured DDNS any less secure
than mDNS?  What am I missing?

This is an implementation issue, not a security issue--sorry for not making 
that clear.   In order to preserve the same security characteristics that mDNS 
has, we have to ensure that the update actually originated on the local link, 
which requires a different sort of listener than is present in a typical DNS 
server.   And existing DNS servers typically don't have any way to support 
unauthenticated updates on a first-come, first-served basis, so if you allow 
unauthenticated updates, you don't have any way to avoid collisions.   
Otherwise you are correct.   The answer is to write a document that describes 
how to do that, and if you read the homenet naming arch document, you can see 
that I actually sketched out a solution there, which I expect to go in a 
different document, likely in a different working group.

There are many worms in that can :)
I understand that this is potentially a huge can of worms, but if no one opens 
it, it'll never get solved.

So my preference would be to write down what we want in Homenet (in the naming 
architecture document, in a technology-agnostic way), analyse the gaps against 
competing current technologies, and then see what people propose to close those 
gaps.

That sounds like a good start.

If multi-subnet mDNS comes out a clear winner, then I'll shut up.

But I'm not even convinced that the gaps are understood/ documented at this 
time.

No, and I agree there. But that doesn’t preclude delivering the hybrid proxy 
model, which is certainly applicable in campus environments (and was in 
response in part to an educause petition), and for which Markus has presented a 
draft for how that model could work in homenets.

Tim

Oh, sure, we Poles are not quite as pessimistic as the Finns.  I'm
actually of a divided mind here -- I rather like distributed solutions
(hence prefer mDNS to DDNS) but dislike proxying.  Part of me just wishes
we'd mandate site-local multicast and do mDNS over that

The problem with site-local multicast for mDNS is that multicast isn't a great 
solution even on the local wire when that wire is wireless.And, you have to 
do modify the client anyway.

Indeed; this was discussed early on in the dnssd WG, and not considered for 
those reasons.

Furthermore, if you consider the mdns hybrid proxy stateless, then you can have 
a DNS server that is roughly that stateless too.   I think it provides better 
service continuity if you are willing to retain some state, but everything will 
still work even if you don't, just as the hybrid proxy does.

Agreed.

Tim

___
homenet mailing list
homenet@ietf.org<mailto:homenet@ietf.org>
https://www.ietf.org/mailman/listinfo/hom

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

2016-05-05 Thread Tim Chown

Hi,

> On 5 May 2016, at 13:37, Juliusz Chroboczek  
> wrote:
> 
>>> We can and should.  The problem is that we won't see that code ship in
>>> new devices anytime soon, so we still have to make mDNS work.
> 
>> And this is why the dnssd WG is focused on making mDNS work on
>> multi-subnet networks.
> 
> Is there something I can read on this particular subject?

The WG charter is at: https://datatracker.ietf.org/wg/dnssd/charter/. 
A thing to note is that both large enterprises and (small) homenets are in 
scope, one of which is managed, one of which isn’t.

The requirements are documented in RFC 7558, which was published last year.

The current hybrid proxy draft is at 
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03, and is likely to be 
pushed to the IESG after the next update, based on discussion at the BA 
meeting. 
Section 6 describes the current implementation status. 
The author is Stuart Cheshire, who also of course is an author of mDNS and 
DNS-SD.

A parallel DNS Push draft allows optimisation, see: 
https://tools.ietf.org/html/draft-ietf-dnssd-push-07
(This draft is being split into two parts after discussion at the BA meeting, 
one of which will be done in the dnsop WG)

Finally, Markus has written a homenet-oriented hybrid proxy draft: 
https://tools.ietf.org/html/draft-ietf-homenet-hybrid-proxy-zeroconf-02, which 
aims to handle the unmanaged use of hybrid proxy.

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

2016-05-05 Thread Tim Chown

> On 25 Apr 2016, at 03:39, Ted Lemon  wrote:
> 
> On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
> > 
> 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.
> 
> I'd be grateful if you could expand on that.  Why can't we define a way
> for clients to do DDNS?
> 
> We can and should.   The problem is that we won't see that code ship in new 
> devices anytime soon, so we still have to make mDNS work.

And this is why the dnssd WG is focused on making mDNS work on multi-subnet 
networks.

But Ted has raised the question of DNS Update there, and we agreed in BA that 
we’d accept a draft on issues around coexistence of mDNS and DNS Update.

> > Just 2136 isn't enfough, because there's no authentication scheme,
> 
> I don't understand this argument.  How is non-secured DDNS any less secure
> than mDNS?  What am I missing?
> 
> This is an implementation issue, not a security issue--sorry for not making 
> that clear.   In order to preserve the same security characteristics that 
> mDNS has, we have to ensure that the update actually originated on the local 
> link, which requires a different sort of listener than is present in a 
> typical DNS server.   And existing DNS servers typically don't have any way 
> to support unauthenticated updates on a first-come, first-served basis, so if 
> you allow unauthenticated updates, you don't have any way to avoid 
> collisions.   Otherwise you are correct.   The answer is to write a document 
> that describes how to do that, and if you read the homenet naming arch 
> document, you can see that I actually sketched out a solution there, which I 
> expect to go in a different document, likely in a different working group.

There are many worms in that can :)

> Oh, sure, we Poles are not quite as pessimistic as the Finns.  I'm
> actually of a divided mind here -- I rather like distributed solutions
> (hence prefer mDNS to DDNS) but dislike proxying.  Part of me just wishes
> we'd mandate site-local multicast and do mDNS over that
> 
> The problem with site-local multicast for mDNS is that multicast isn't a 
> great solution even on the local wire when that wire is wireless.And, you 
> have to do modify the client anyway.

Indeed; this was discussed early on in the dnssd WG, and not considered for 
those reasons. 

> Furthermore, if you consider the mdns hybrid proxy stateless, then you can 
> have a DNS server that is roughly that stateless too.   I think it provides 
> better service continuity if you are willing to retain some state, but 
> everything will still work even if you don't, just as the hybrid proxy does.

Agreed.

Tim

> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] The minimal Babel profile for Homenet

2015-10-28 Thread Tim Chown

On 28 Oct 2015, at 13:07, Juliusz Chroboczek  
wrote:
> 
>>>  (2) SHOULD RFC 6126, IPv4 subset;
> 
>> Why not MUST? [...] I don't think the prodding should be done by causing
>> unnecessary pain for average consumers.
> 
> Fully agreed, but I'm not sure what is the WG's thinking about IPv4.  RFC
> 7368 (Homenet arch) is conveniently vague about IPv4.  My reading is that
> the authors of RFC 7368 expected that router vendors will use multiple NAT
> for IPv4, and that they will ignore whatever we mandate.

Well, it was simply written as per directed by the WG chairs to not explicitly
consider IPv4. The focus was on IPv6 home networking.

As it says in the intro:

"The architectural constructs in this document are focused on the
   problems to be solved when introducing IPv6, with an eye towards a
   better result than what we have today with IPv4, as well as aiming
   for a more consistent solution that addresses as many of the
   identified requirements as possible.  This document aims to provide
   the basis and guiding principles for how standard IPv6 mechanisms and
   addressing [RFC2460] [RFC4291] can be employed in home networking,
   while coexisting with existing IPv4 mechanisms.  In emerging dual-
   stack home networks, it is vital that introducing IPv6 does not
   adversely affect IPv4 operation.  We assume that the IPv4 network
   architecture in home networks is what it is and cannot be modified by
   new recommendations.  This document does not discuss how IPv4 home
   networks provision or deliver support for multiple subnets.  It
   should not be assumed that any future new functionality created with
   IPv6 in mind will be backward compatible to include IPv4 support.
   Further, future deployments, or specific subnets within an otherwise
   dual-stack home network, may be IPv6-only, in which case
   considerations for IPv4 impact would not apply.”

Or in other words, IPv4 is as it is. In practice, many home networks will be 
dual-stack for some time, so deployments need to consider IPv4.

The hipnet work, for example, which was strongly compliant with RFC 7368, 
included IPv4 delegations within the home net, so avoided multiple NATs.

> OTOH, the HNCP draft does (mostly) the right thing wrt. IPv4, so I guess
> we could ignore RFC 7368's lack of assertiveness here and say that RFC 6126
> style IPv4 is MUST, except if IPv4 is not supported at all.  (I'm not
> overly keen on the "MUST implement, SHOULD deploy" style of compromise.)

My understanding is that RFC7368 basically leaves you free to do as you will 
with IPv4.

>> It's ok for vendors to ship with IPv4 disabled by default
> 
> That's policy, in my opinion it's HNCP's job, not Babel's.  Babel should
> run with IPv4 unconditionally enabled, if HNCP chooses to publish an IPv4
> prefix, who is Babel to disagree?
> 
> I guess we're in full agreement here, just looking for the right wording.

RFC 7368 does not mandate disabling IPv4, nor does it require IPv4 to be 
enabled :)

Tim

> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Despair

2015-08-05 Thread Tim Chown

 On 5 Aug 2015, at 13:34, Ray Bellis r...@bellis.me.uk wrote:
 
 On 05/08/2015 12:44, Dave Taht wrote:
 
 I would like to require the design team
 
 *to actually install the software*.
 
 Dave,
 
 We've heard you before, but with the best will in the world we cannot
 *require* IETF volunteers to put their own time and money into this.
 
 Heck, I can't even run the Homenet stack myself as my ISP doesn't yet
 have native IPv6 and also wants extra money to get their edge router
 running in bridge mode.
 
 [and no, before you suggest it, changing ISPs is *not* an option].

I see the homenet wiki content is 4 years old - 
http://tools.ietf.org/wg/homenet/trac/wiki 

Perhaps Dave/Juliusz/Markus could be allowed to add info there about their
implementations for Babel+HNCP? That might help people find and use the
info… even if not as yet formally an adopted WG solution.

If there’s an open source IS-IS based solution, then that could also be posted 
there,
so those interested in exploring both approaches could get hands-on experience?

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] HNCP, RA and DHCPv4

2015-07-31 Thread Tim Chown

Hi,

 On 27 Jul 2015, at 14:58, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr 
 wrote:
 
 snip
 
 Renumbering is not as smooth -- it appears to be impossible to remove
 a set of addresses wholesale, retracting a set of PIOs merely causes the
 old addresses to become deprecated.  Since after a renumbering event we're
 no longer routing towards the retracted prefix, the client will need to
 timeout its TCP connections, and any UDP applications will need to rebind
 to the non-deprecated addresses (please check your NTP and BitTorrent 
 clients).

Much will depend if the ISP is offering their customer a ‘graceful’ renumbering 
event. If they do, then the principle applied in RFC4192 could be applied, and
you will have a period where both prefixes (old and new) co-exist, before the
old prefix is removed. In that case, the older connections can be retained, at
least until that removal.

If the ISP is ‘flash’ renumbering, then yes, this is certainly a challenge. It 
would
thus be useful to know what types of events customers / homenets might see.

For internal connections, if the homenet is running ULA alongside its ISP
prefix, then the sessions will survive through use of the ULAs. Which is why
it’s useful to be able to provide stable prefixes internally.

 The situation with DHCPv4 is not as satisfactory.  It is not possible to
 force the clients to either pick a different default router or to renew
 their lease (FORCERENEW is not useful).  This means that DHCPv4 clients
 will be stuck with a non-functional address until they choose to renew.
 As Markus explained to me, this is mitigated by three factors:
 
  1. since IPv4 addresses are NATed, IPv4 renumbering is not likely to
 happen;
 
  2. since DHCPv4 is not a very noisy protocol, we can use very low
 renewal times;
 
  3. Windows users have already been trained to reboot when something
 doesn't work as expected.
 
 I know there are DHCP and 6man/6ops people on this mailing list, any
 opinions on whether we're doing it wrong and whether updates to RA/DHCPv4
 are desirable?

The interesting thing here is that many people (in my view quite rightly) like 
the 
whole ‘fate sharing’ principle of a prefix, a router and an RA. The ‘problem’
with DHCP is that if the outing information changes, a default gateway learnt
from a DHCP server may well become stale / out of date information.

homenet doesn’t generally design IPv4 solutions, it’s focused on IPv6, but
if HNCP allows dynamic update of DHCP server configuration information,
then that’s potentially useful.

Tim

 
 -- Juliusz
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] some IS-IS questions

2015-07-31 Thread Tim Chown

On 28 Jul 2015, at 21:21, Gert Doering g...@space.net wrote:
 
 Hi,
 
 On Tue, Jul 28, 2015 at 11:55:16AM -0400, Ted Lemon wrote:
 This means that the end user can be assumed to plug home routers together 
 in arbitrary topologies, [..]
 
 Our goal is for this to work in a multihomed IPv6 environment.   
 
 Just to repeat myself from yesterday :-) - OpenWRT with HNCP and Babels
 achieved this nicely enough 15+ months ago.  Yes, it had some rough
 edges, but it *worked*.

And maybe a year before that there was working code for OSPF (with multiple 
implementations based on at least Bird and Quagga) which had working code 
for homenet routing, including automatic prefix configuration and src/dst 
routing.

Hindsight is a wonderful thing. If homenet had decided to separate out the
configuration from the routing at an earlier point, we’d certainly have been
where we are now rather sooner. The OSPF implementations allowed us to
see quite clearly that the separation of configuration was desirable (as much
as Markus was increasingly creative with new TLVs!), so that experience
while arguably ‘lost’ time was something we learnt from. Part of the homenet
journey.

Personally, I like where we are with Babel and HNCP now. Many of the same
people, esp. Markus and Dave, who prototyped previous work, have been 
awesome in repeating their efforts for HNCP  Babel, and that’s great.

It was a shame to see many open source developers feeling frustrated at
Prague. I hope they do continue their efforts. We would not be where we
are now in homenet without them. The HNCP work should now be able to be
completed independently of the routing protocol chosen, and if the Babel
side meeting from Prague leads to wider understanding of Babel, and its
standards status being elevated, that would be great.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt

2015-07-09 Thread Tim Chown

Hi,

 On 9 Jul 2015, at 16:35, Ray Bellis r...@bellis.me.uk wrote:
 
 On 09/07/2015 16:28, Juliusz Chroboczek wrote:
 It is very hard to find a wording for this that everyone agrees with.
 
 Yes.
 
 For now it was changed to “DNCP is an abstract protocol, that must be
 combined with a specific profile to make a complete implementable
 protocol.”
 
 I'm not sure that I know what an abstract protocol is.  I would suggest
 something like the following:
 
  This document (DNCP) defines a distributed algorithm that can be used by
  protocols that need to flood static or slowly changing information in
  a timely manner across an IP network, as well as a suggested packet
  format to be used by such protocols.
 
 I'd also eliminate the vague term DNCP profile, and replace it by
 protocol using DNCP.
 
 no-hat
 
 The draft defines TLVs.  To me that means it's somewhat more than an
 algorithm.
 
 In OO programming terms, it would be an abstract superclass of HNCP,
 but it's not pure abstract
 
 /no-hat

Having reviewed the homenet prefix distribution draft for OPS-DIR, I would say 
that *that* is an algorithm. It mentions no protocol specifics (and is thus not 
something you could build an interoperable implementation from).

Tim

 Ray
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet requirements on ISPs -- should write them down?

2015-04-28 Thread Tim Chown

Hi,

 On 27 Apr 2015, at 19:01, Michael Richardson mcr+i...@sandelman.ca wrote:
 
 
 This WG has been chartered to address networking issues in the home.
 In the process of doing this we have made various assumptions about what ISPs
 might (or might not) provide.  These have mostly been aligned with what other
 groups (particularly ops area groups) have said.
 
 In many cases, we have taken the approach about what ISPs might/sometimes do,
 or things that we think all ISPs will do.  For instance, BCP38 (ingress
 filtering of source addresses) puts a significant constraint on how we build
 our homenets.  We have also said decided that we won't deal with the case
 where an ISP provides enough IPv6 space to number the homenet, (other than to
 say that we hope to fail gracefully).
 
 QUESTION:
I wonder if we should collect these things into an ISP requirements 
 document.
Well... requirements might be too strong a word here.   Maybe 
 wishlist is
more appropriate; my purpose is not to argue the precise term here, but
rather to condense the list more clearly.

I agree.

I think there are a number of things that could/should be teased out of the 
work done
to date and made more explicit (and expanded) in separate documents. These might
include, as rough working titles :

- Recommendations for ISPs providing residential IPv6
- Management and monitoring of IPv6 home networks (something Joel asked for as 
we
  wrapped up RFC7368)
- Security architecture for IPv6 home networks
- Graceful(!) renumbering of IPv6 home networks (drawing on 6renum and its gaps 
document)

The ISP document would also help more knowledgable customers understand the
expectations they might have of their ISP.

Something for the chairs to consider. None of the above should prevent existing 
work
continuing, but it may be useful to document common understanding of what we’re
trying to achieve.

Tim

 BACKGROUND to why this email today:
 
 I say this with a hat I wear a few days/month as the maintainer of a PPPoE
 appliance/access concentrator that has widespread deployment, and has been
 shipping IPv6 (rfc6204/7084) support since last fall.
 I think that it will grow support for additional things we might specify in
 homenet.  For instance delegation of reverse DNS zones.
 
 (In creating my work plan, in the end I had to reverse engineer the Broadband
 Forum TR-187 to decide what services I needed to provide. RFC6204 wasn't 
 enough)
 
 I am updating the NTP software in this appliance, and I'm looking at a
 question, should I enable 5906 by default.  rfc5906 is, to save you a trip to
 your browser:
 Network Time Protocol Version 4: Autokey Specification
   This memo describes the Autokey security model for authenticating
   servers to clients using the Network Time Protocol (NTP) and public
   key cryptography.  Its design is based on the premise that IPsec
   schemes cannot be adopted intact, since that would preclude
   stateless servers and severely compromise timekeeping accuracy.  In 
 addition,
   Public Key Infrastructure (PKI) schemes presume authenticated
   time values are always available to enforce certificate lifetimes;
   however, cryptographically verified timestamps require interaction
   between the timekeeping and authentication functions.
 
 ...
 In smaller, understaffed ISPs, anything the edge concentrator can do out
 of the box without additional configuration is a boon, so being the NTP
 server for the connected homes is a good thing should I think about
 turning on 5906?  well, the question becomes: will anyone need it?
 
 --
 ]   Never tell me the odds! | ipv6 mesh networks [
 ]   Michael Richardson, Sandelman Software Works| network architect  [
 ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
 [
 
 
 
 
 
 
 
 
 --
 Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
 -= IPv6 IoT consulting =-
 
 
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Orchestration of renumbering

2015-03-25 Thread Tim Chown

 On 25 Mar 2015, at 02:01, Brian E Carpenter brian.e.carpen...@gmail.com 
 wrote:
 
 On 25/03/2015 08:47, JF Tremblay wrote:
 
 On Mar 24, 2015, at 2:00 PM, Brian E Carpenter 
 brian.e.carpen...@gmail.com wrote:
 
 [...] Make-before-break
 renumbering (a.k.a. planned renumbering) is preferable but we can't
 rely on it. (I also try to never forget Fred Baker's observation that
 there is no such thing as renumbering: there is only numbering.)
 
 Any reference for reading (on Fred’s principle)?
 
 I'm not aware of a written version; it's something I've heard him say
 more than once. Of course there is RFC 4192, but it isn't in that.

And it’s very true. A point made several times through 6renum’s lifetime.

For one, it’s in the introduction here:
https://tools.ietf.org/html/draft-baker-6renum-oss-renumbering-00 
https://tools.ietf.org/html/draft-baker-6renum-oss-renumbering-00

Tim

 Brian
 
 [...] However, Dave Taht told us
 recently that renumbering *is* currently broken, and I'd like to see his
 list of issues. For now, here are the issues that I see:
 
 I’ll let Dave answer for himself, but my personal experience at home 
 currently is that it breaks quite often. As soon as the home network gets 
 renumbered, new RAs are flooded, but no RAs are sent to de-prefer the 
 current prefix (as specified in RFC7084 L-13). I’ve seen this happen both 
 with 6RD and in native, with two home router vendors. I usually flap my link 
 physically to flush old addresses. 
 
 Btw, I didn’t raise this morning, but I believe smooth renumbering from an 
 ISP is possible, at least for cable ISPs (costly, but possible). This 
 requires support for multiple concurrent prefix delegations on home routers, 
 which I haven’t seen yet in the wild. This requirement isn’t explicitly 
 mentioned in RFC7084, only indirectly through the support for DHCPv6-PD 
 (WPD-1). 
 
 So on the short term, proper implementation of RFC7084 L-13 is required for 
 smoother unplanned renumbering. For smooth planned renumbering, support for 
 multiple concurrent PDs is required. It’s too bad that the homenet 
 architecture doc (RFC7368 section 3.4.1) does not even mentions this 
 possibility. 
 
 JF
 
 
 
 
 
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-09 Thread Tim Chown

On 9 Oct 2014, at 12:03, Ole Troan otr...@employees.org wrote:

 it doesn't make sense to specify something that breaks SLAAC.
 
 protocol design is politics. we want to make it clear to the address 
 delegation authorities that not delegating a large enough address block will 
 lead to breakage.
 
 in my view, if we let this principle slide, then the risk isn't that the 
 delegations are /80s, but that they will be /128s. and you're back to IPv6 
 NAT anyhow.

So - provocative question - should this draft be Experimental in status instead 
if it’s diving below /64 boundary?

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

2014-10-08 Thread Tim Chown


On 8 Oct 2014, at 14:14, Pierre Pfister pierre.pfis...@darou.fr wrote:
 
 Why should we mandate homenet implementations to *brake* in situations where 
 they could work fine ? Why should we voluntarily prevent a link from being 
 configured if we actually can configure it ?
 
 If MUSTs are the solution, then I would rather see a ‘ISP MUST provide a /56 
 to customers’ than ‘Homenet MUST brake when the provided prefix is not big 
 enough’.

But this is what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1

i.e. don’t go longer than /64, and ISPs should provide enough prefixes.

The why64 text is very relevant here.

Tim___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] HNCP security?

2014-09-20 Thread Tim Chown

 On 19 Sep 2014, at 21:59, Ted Lemon mel...@fugue.com wrote:
 
 On Sep 19, 2014, at 4:54 PM, Michael Thomas m...@mtcc.com wrote:
 I guess that's kind of what I've been getting at: should we capture all of 
 this in a threats document?
 I'm a little uncomfortable with the formality, but I'm even more 
 uncomfortable with the seeming desire
 by some to sweep this all under the rug.
 
 I think it would be worth gathering the information in a document if someone 
 wants to write one, sure.   Just talking and not gathering the results is a 
 waste of time.   I think there are a fair number of people who have ideas 
 about how this should work.   I don't know if a threats document per se is 
 the right thing to do, but a document where this discussion is tracked and 
 recorded would definitely be helpful.   It would be a shame though if that 
 effort derailed forward progress, as such things sometimes do.

I think it would be useful to do, and needn't hold up progress. It would give 
us a common understanding - hopefully - of which threats are being covered and 
which are not. And which are handled by layers/protocols outside the scope of 
homenet's charter.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] HNCP security?

2014-09-16 Thread Tim Chown

On 16 Sep 2014, at 14:52, Michael Richardson mcr+i...@sandelman.ca wrote:
 
 I think that we can assume that wired links are secure.
 The only time we care if wireless is secured is when we want to form an
 adjacency over the wireless link.   I think it is acceptable to refuse
 to form an adjancency over an insecured wireless link.

A little side story…

I have an old house with quite thick walls. Standard 802.11 doesn't reach all 
rooms. Not that long ago I bought a pair of Netgear powerline Ethernet adaptors 
to extend coverage between rooms. I’d used an older version before, and it 
worked well, giving more throughout than the wireless and with the extended 
range. 

The interesting thing was that soon after plugging them in I noticed I’d lost 
connectivity on a laptop, and my desktop was behaving oddly. I looked at the 
network config to remind myself of the IP address of my default ADSL router. I 
used a browser to connect to the default router by IP to check its 
configuration. And got quite a surprise as it was a Sky router - a surprise as 
I’m not a customer of theirs! 

To cut a long story short, my powerline adaptors had formed a single network 
with powerline adaptors in a neighbour’s house. At which point my devices were 
getting responses from two DHCP servers, and some were routing out via the 
neighbour’s router. And that included some of my wireless devices - no point 
having WPA2 to protect against unwanted ‘guests’ if they can come in a power 
line Ethernet back door :)

Now, what I should have done, but it’s easy to get distracted and forget(!), 
was use the magic ‘auto configure a shared secret’ button on each of my 
adaptors to avoid them merging with my neighbour’s devices, or manually 
configure shared secrets (yuk). But clearly neither of us had done that.

The interesting thing was I could see the neighbour’s SSID from their Sky 
router splash screen, but having walked around the nearest streets, I couldn’t 
find it. I wonder how far away that house was...

There’s obviously some interesting implications of this. One is that there are 
insecure wired links too! 

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-17 Thread Tim Chown

Hi Ray,

I like your questions, and I think many of your own suggested answers to your 
questions are in line with what I believe the WG has assumed in its 
discussions. I find myself in agreement with most (and perhaps all) of them.  
But obviously I can’t speak for the WG, only my perception of WG consensus as 
the document editor.

I would say we did shy away from a specific answer on a separate configuration 
protocol in London, but since then HNCP has evolved. I agree the multi-path 
clarification is needed.

I think Alex is heading into too much detail, when we are trying to avoid that 
(what Ray describes are general principles).

I’m talking with Ted and the chairs on the approach to take.  Expect news soon 
:)

Tim

On 14 Jun 2014, at 14:44, Ray Hunter v6...@globis.net wrote:

 
 
 Tim Chown wrote:
 
 On 13 Jun 2014, at 14:57, Ted Lemon mel...@fugue.com 
 mailto:mel...@fugue.com wrote:
 
 On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti lore...@google.com 
 mailto:lore...@google.com wrote:
 Not to me they didn't. Seriously - if you understand what we're being 
 asked to do, and it's simple to explain, then it shouldn't take long for 
 you to type. Please?
 
 The working group would presumably like for there to be routing on the 
 homenet.   What problems is the routing supposed to solve?   What things 
 are priorities?   What things aren't priorities?
 
 Clearly we need the routing solution to get packets to the right egress 
 based on source address.   Do we also need it to do load sharing across 
 parallel links, if such links exist?   Is it important to minimize the 
 number of hops? 
 
 Para 7 of 3.5:
 It may be beneficial for traffic to use multiple paths to
a given destination within the homenet where available, rather than a
single best path.
 
 How long of a delay can there be between changes to the topology (e.g., a 
 router being unplugged) and recovery, assuming that a flow was going 
 through that router? 
 
 Para 6 of 3.5:
 Minimising convergence time should be a goal in any
routed environment, but as a guideline a maximum convergence time at
most 30 seconds should be the target (this target is somewhat
arbitrary, and…“
 
 Is it okay to break a flow in that situation, or does it need to survive 
 the transition? 
 
 Not stated.  Should it be different to the border router resetting?
 
 Does the routing protocol need to be aware of the type of media a given 
 link crosses, and does it need to prefer one media type over another where 
 both are available?
 
 Para 5 of 3.5:
 Multiple types of physical interfaces must be accounted for in the
homenet routed topology.  Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of
any routed deployment.The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path
computation should be considered for optimising communication in the
homenet.“
 
 I'm basically making questions up here.   The document should say what the 
 working group wants routing to accomplish.   Right now it's a bit of a 
 kitchen sink, with a lot of (IMHO) inappropriately prescriptive text.
 
 Well, 3 of the 4 questions seem to be answered, or at least considered if 
 left relatively open.
 
 Tim
 
 
 ___
 homenet mailing list
 homenet@ietf.org mailto:homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 
 OK. Ted asked for additional questions and answers, and I think he has a 
 point in that there should be hooks to requirements in the architecture that 
 facilitate selection of the correct routing protocol(s) later, without 
 unnecessarily limiting the choice.
 
 
 Here's my contribution after going through a few comparisons texts of common 
 routing protocols that I found online. I pose a question, give my personal 
 view, and then check if I can find an answer in the current text.
 
 
 Does the Homenet Architecture require the routing protocol to carry arbitrary 
 configuration information?
 [my view] No. Assuming the existence of a separate Homenet configuration 
 protocol, the routing protocol must facilitate auto-configuration, but does 
 not necessarily have to supply configuration to other processes.
 [this is not currently explicitly defined the architecture document AFAICS]
 
 
 Does the Homenet Architecture require the routing protocol to support 
 multiple address families?
 [my view] No. The Homenet architecture is IPv6 only. Although support for 
 IPv4 and other address families may be beneficial, it is not an explicit 
 requirement to carry the routing information in the same routing protocol.
 [this is not currently in the architecture document AFAICS]
 
 
 Does the Homenet Architecture require the routing protocol to support SADR?
 [my view] Yes.
 [this is in the current architecture document]
 
 A routing protocol

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-17 Thread Tim Chown

Hi,

On 17 Jun 2014, at 18:48, joel jaeggli joe...@bogus.com wrote:

 On 6/17/14, 10:38 AM, ietfdbh wrote:
 
 -Original Message-
 From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Alexandru
 Petrescu
 [...]
 
 I suppose parents will likely ask the IPv6 specialists something like
 this:
 - should I click on '6rd' or '6to4' or on 'DHCPv6' or on 'PPPoE'?
 - should I click on ULA or not?
 - should I click on private addresses or not?
 - should I click on Delegate inside when using Delegate from outside,
   or not?
 
 So if you use a current IPv6 supporting CPE, normally you do nothing.
 
 very occasionally you need to tick a box to enable it.
 
 It is a mistake to assume that end users should be exposed to the
 selection of transition technologies and that would ever be appropriate
 in the general case.

I agree, this conversation is heading into the weeds here, at least for closing 
off the arch text.

Tim

 - what should I fill in as next-hop address?
 - what does dotted-decimal notation mean with IPv6 addresses?
 (these are examples from existing consumer equipment for in-house)
 
 Wow! What parents!
 Mine would be more likely to ask how do I turn this on?
 
 David Harrington
 ietf...@comcast.net
 +1-603-828-1401
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-13 Thread Tim Chown


On 13 Jun 2014, at 14:38, Ted Lemon mel...@fugue.com wrote:

 On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti lore...@google.com wrote:
 No, the problem is that the working group doesn't know what is being asked 
 for.
 
 We could go around on this all week…

I must say as the editor of the arch text I am also very confused. I don’t 
understand what is required in a replacement for the “contentious paragraph 
(paragraph 4 of section 3.5), rather than simply removing the paragraph based 
on strong WG consensus.

In producing the -13, which was pushed out at IETF London, it seemed to me that 
there was clear WG consensus in that meeting that we should not constrain, 
witness the minutes at 
http://www.ietf.org/proceedings/89/minutes/minutes-89-homenet (under Slide 9). 
This view was reinfroced by comments elsewhere, and by the WG chairs. While 
it’s possible the WG view may have changed since London, it’s not a big 
surprise that it hasn’t. That message is why the one reference to link metrics 
earlier in section 3.5 is clearly qualified by “if supported by the protocol in 
use”.

As Ray points out, the paragraph added by the Routing ADs does make other some 
text in other paragraphs (which isn’t so prescriptive) seem out of place. My 
personal view, which happens to be in line with most (all?) who have commented 
in the WG is simply to strike the proposed prescriptive paragraph.  The 
question of course is whether/if Ted can square that off with our routing ADs 
who have genuine concern in raising the issue… it’s simply that the WG is 
coming back here and saying “it’s OK, thanks for raising the point, but we’re 
sure we want to do it this way”.

The -13 also includes other changes in response to discussion at London, as 
documented in the minutes, e.g. about the zero or one routing protocols. 

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-13 Thread Tim Chown


On 12 Jun 2014, at 23:44, Michael Richardson mcr+i...@sandelman.ca wrote:
 
 I will attempt to read the diffs; but... It Just Doesn't Mattertm
 better is the enemy of good enough, and it was good enough a year ago.

Well… :)

The last few months have basically been about bashing through a list of around 
80+ IESG comments and discusses. The good news is that this one paragraph is (I 
really really hope) the last outstanding issue of that list to resolve. 

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updates to Homenet Architecture Principles doc

2014-06-13 Thread Tim Chown


On 13 Jun 2014, at 14:57, Ted Lemon mel...@fugue.com wrote:

 On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti lore...@google.com wrote:
 Not to me they didn't. Seriously - if you understand what we're being asked 
 to do, and it's simple to explain, then it shouldn't take long for you to 
 type. Please?
 
 The working group would presumably like for there to be routing on the 
 homenet.   What problems is the routing supposed to solve?   What things are 
 priorities?   What things aren't priorities?
 
 Clearly we need the routing solution to get packets to the right egress based 
 on source address.   Do we also need it to do load sharing across parallel 
 links, if such links exist?   Is it important to minimize the number of hops? 
  

Para 7 of 3.5:
 It may be beneficial for traffic to use multiple paths to
   a given destination within the homenet where available, rather than a
   single best path.

  How long of a delay can there be between changes to the topology (e.g., a 
 router being unplugged) and recovery, assuming that a flow was going through 
 that router?   

Para 6 of 3.5:
Minimising convergence time should be a goal in any
   routed environment, but as a guideline a maximum convergence time at
   most 30 seconds should be the target (this target is somewhat
   arbitrary, and… “

 Is it okay to break a flow in that situation, or does it need to survive the 
 transition?   

Not stated.  Should it be different to the border router resetting?

 Does the routing protocol need to be aware of the type of media a given link 
 crosses, and does it need to prefer one media type over another where both 
 are available?

Para 5 of 3.5:
Multiple types of physical interfaces must be accounted for in the
   homenet routed topology.  Technologies such as Ethernet, WiFi,
   Multimedia over Coax Alliance (MoCA), etc. must be capable of
   coexisting in the same environment and should be treated as part of
   any routed deployment. The inclusion of physical layer
   characteristics including bandwidth, loss, and latency in path
   computation should be considered for optimising communication in the
   homenet.“

 I'm basically making questions up here.   The document should say what the 
 working group wants routing to accomplish.   Right now it's a bit of a 
 kitchen sink, with a lot of (IMHO) inappropriately prescriptive text.

Well, 3 of the 4 questions seem to be answered, or at least considered if left 
relatively open.

Tim

 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Single or Multiple Routing Protocols in Homenet

2014-06-01 Thread Tim Chown

On 1 Jun 2014, at 13:38, Sander Steffann san...@steffann.nl wrote:

 Hi,
 
 Op 1 jun. 2014, om 12:50 heeft Gert Doering g...@space.net het volgende 
 geschreven:
 
 On Sun, Jun 01, 2014 at 10:47:03AM +0200, Pierre Pfister wrote:
 So even if most will agree that supporting multiple routing protocol is a 
 madness in the general case. 
 It?s not that hard to ?support it? while requiring one single routing 
 protocol as mandatory in home networks.
 And whenever we want to move to another protocol, maybe in 20 years, it 
 will allow transitioning softly.
 
 Having multiple routing protocols and select between them is already 
 permitted by the current HNCP draft (for example).
 
 The question was more whether add ISIS today would bring a benefit to
 homenet, and I still maintain no - to the contrary, it is harmful - as
 you said, we can be happy if CPE vendors get one protocol right.
 
 +1
 
 I personally don't really care about which protocol that should be (I have 
 some preferences, but getting one protocol right outweighs all those 
 preferences by a huge margin) as long as we design something that is easy 
 enough for CPE vendors to implement correctly so that for the home user 
 everything just works.
 
 Needing to implement multiple protocols, having to negotiate with other 
 devices which of those protocols to use, network flaps because a device was 
 added to the network that doesn't support the protocol that the other devices 
 agreed upon etc. don't help in this regard.
 
 Please remember: the end goal is to create a situation for home users that 
 just works and works reliably, not to design the most fancy and cool 
 combination of protocols possible…

Just as a reminder, here is what we converged on at IETF89 for text in the 
homenet arch. The “zero or one” protocol message was clear. I don’t recall a 
clear answer on whether to pass config info via the routing protocol or a 
separate protocol, but as HNCP shapes up as a proposal I suspect the tradeoffs 
will become clearer towards an answer there.

  At most one routing protocol should be in use at a given time in a
   given homenet.  In some simple topologies, no routing protocol may be
   needed.  If more than one routing protocol is supported by routers in
   a given homenet, then a mechanism is required to ensure that all
   routers in that homenet use the same protocol.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] New arch text: draft-ietf-homenet-arch-12.txt

2014-02-14 Thread Tim Chown

Hi,

For info, this draft is intended to address any remaining IESG comments.  
Emails have been sent to the ADs in question with the chairs copied.  We hope 
that any remaining DISCUSSes can be cleared before London.

Tim

On 14 Feb 2014, at 18:17, 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 Working Group of the IETF.
 
Title   : IPv6 Home Networking Architecture Principles
Authors : Tim Chown
  Jari Arkko
  Anders Brandt
  Ole Troan
  Jason Weil
   Filename: draft-ietf-homenet-arch-12.txt
   Pages   : 52
   Date: 2014-02-14
 
 Abstract:
   This text describes evolving networking technology within residential
   home networks with increasing numbers of devices and a trend towards
   increased internal routing.  The goal of this document is to define a
   general architecture for IPv6-based home networking, describing the
   associated principles, considerations and requirements.  The text
   briefly highlights specific implications of the introduction of IPv6
   for home networking, discusses the elements of the architecture, and
   suggests how standard IPv6 mechanisms and addressing can be employed
   in home networking.  The architecture describes the need for specific
   protocol extensions for certain additional functionality.  It is
   assumed that the IPv6 home network is not actively managed, and runs
   as an IPv6-only or dual-stack network.  There are no recommendations
   in this text for the IPv4 part of the network.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-homenet-arch-12
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-12

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] APPSDIR review of draft-ietf-homenet-arch-10

2013-11-04 Thread Tim Chown


On 19 Sep 2013, at 14:24, Dave Cridland d...@cridland.net wrote:

 Ted Lemon wrote:
 On Sep 19, 2013, at 6:59 AM, S Moonesamy sm+i...@elandsys.com wrote:
 The Chairs have already agreed about the five topics to be covered. 
 It's not a problem.  The next step would be to take these topics, make 
 them accessible to the average reader, and organize them.  This may 
 require avoiding too many details if it is doable.
 
 I think that you are interpreting this document to be something that it is 
 not, and cannot yet be.   What this document is is an architecture for the 
 homenet working group—a crib sheet that tells us what we are trying to 
 accomplish.   I don't think it's intended to be something that a random 
 person who is not implementing home gateways would find useful.   The 
 working group is hoping that subsequent versions of this document will 
 evolve over time, and I think it would be good for the working group to 
 evolve the document into something that meets the goals that you've set out 
 above.
 
 However, I think that if the working group attempts to do that now, two 
 things will happen.  First, the working group won't actually get to the work 
 it's supposed to be doing, because completing the architecture document will 
 continue to be an all-consuming effort.   Second, the document that is 
 produced will be purely theoretical, not based on actual practice, and 
 probably useless.
 
 So I would like you to consider whether you can accept this restatement of 
 the purpose of the document.   Do you feel that this document cannot be of 
 use until it meets the goals you've set out above, or does the different 
 purpose I've expressed here make sense to you?   If the latter, can you 
 reconsider your review in light of this new stated purpose for the document? 
 Is part of the problem that the goals of the document are poorly expressed 
 in the document?   Given the goals I've stated, do all of your comments 
 still apply, or would you have responded differently to the document if 
 you'd been evaluating it on the basis I'm proposing?
 
 Then the title ought to call itself Requirements, or Proposed, or something.
 
 Actually, I genuinely struggle to understand the purpose of publishing 
 documents which are intended as working documents for a particular Working 
 Group as an RFC, but on the basis that it's required for some reason I don't 
 understand, then calling it the Home Networking Architecture for IPv6 is 
 confusing - I read that, perhaps terribly naively, as being a document 
 defining the Home Networking Architecture for IPv6. Partly because, right at 
 the top, it says The goal of this document is to define a general 
 architecture for IPv6-based home networking. It really had me fooled.
 
 I appreciate I'm obviously foolish and easily mislead, but perhaps calling 
 entitling it Architectural Requirements for IPv6 Home Networking, or 
 Proposals and Considerations for Home Networking Architecture for IPv6, 
 might give the reader the hint that it's not defining an architecture as such.
 
 Dave.

The title was amended slightly for -11:

The diff for the -11 is available here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-11.txt

Tim___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] APPSDIR review of draft-ietf-homenet-arch-10

2013-09-20 Thread Tim Chown

On 19 Sep 2013, at 11:59, S Moonesamy sm+i...@elandsys.com wrote:

 At 16:10 18-09-2013, Tim Chown wrote:
 
 There is already a split namespace for existing home networks. Devices may 
 live under .local (for mDNS/DNS-SD), which has meaning on the subnet in 
 question (though some emerging vendor products are proxying this through 
 routers - hence the desire to form a dnssdext WG to look at that topic), 
 and/or may use a globally unique name space.
 
 The issue in future home networks is how naming and SD works across a 
 routed, multi-link home. What is the equivalent local name space, that can 
 be used whether the home is externally connected or not, providing 
 independent operation where necessary.
 
 That section discusses how that local name space might look, and is the 
 result of considerable discussion in the homenet WG.
 
 Do you have something specific to propose to say instead?
 
 From the above I gather that the namespace issue is currently unresolved.  I 
 suggest stabilizing the document and put the part about namespace on hold.  
 You could document the discussion for now and list that as unresolved issues.

Apologies for the grievous chop in the above included text, but I think it's 
worth adding here that the dnssdext proposed charter (under review by the IESG 
currently I believe) focuses on service discovery, and has been steered away 
from naming issues. It instead proposes to document the issues arising. But 
additionally, thanks to Toerless, the proposed charter not only talk about the 
networking elements of a SD solution, but also what the API would look like to 
application developers who may be advertising or discovering the services.

As per Mike's question today, the relationship between homenet and a potential 
dnssdext WG would need further clarification, but there is overlap and there 
are some mutual interests. 

I'll do a more detailed review of your other comments later. 

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] APPSDIR review of draft-ietf-homenet-arch-10

2013-09-20 Thread Tim Chown


On 19 Sep 2013, at 20:43, Ted Lemon ted.le...@nominum.com wrote:

 On Sep 19, 2013, at 1:36 PM, S Moonesamy sm+i...@elandsys.com wrote:
 I agree that it would be good for the working group to evolve the document 
 (see my previous comments about stabilizing the document and having a 
 discussion about unresolved issues).  It might have been missed in my 
 comments; what I am saying is that the working group already has the text it 
 needs to get the work done; what's left is some rearrangement and tightening 
 of the text to get a crisp document.
 
 Possibly Tim got that from your comments—I didn't.   I should probably let 
 Tim respond rather than continuing to muddy the waters.

Long email threads are prone to misunderstanding, so I'll just try to state my 
interpretation of where the arch doc is, and how it got there.

The arch doc, which is Informational, emerged from the original homenet 
charter, as per http://datatracker.ietf.org/wg/homenet/charter/. This talks 
about, for example, emerging IPv6 home networks with internal routing, 
heterogeneous links, and internal service separation. As well as the 
implications of moving from private IPv4+NAT to global IPv6. It says The task 
of the group is to produce an architecture document that outlines how to 
construct home networks involving multiple routers and subnets and also 
specifies the five areas to include: routing, prefix configuration, security, 
naming and service discovery. So the arch text that has evolved over some 15 
iterations over a year and a half reflects that, and the layer 3 focus.

You can argue that it's a snapshot of current thinking, and we have discussed 
the notion of homenet versions (and indeed current discussions about hipnet and 
homenet are potentially about such an evolution, and whether it can be made to 
work), but I think it's a little more than that given the 18+ months of 
discussion that have led us to where we are, including literally thousands of 
list emails, and at least five IETF meetings. Some paragraphs have been the 
result of 200+ emails. The document title has remained unchanged over that 
time, and the structure relatively stable. While there are some very valid 
DISCUSSes on the text, I believe it represents, as a whole, a good consensus of 
the WG.

I think the vast majority of DISCUSSes can be addressed without any serious 
surgery. And it's good to have such interest focused on the document.

The questions from APPSDIR seem to focus around a) the document structure and 
how/whether it's readily digestible by APPSDIR people, and whether certain 
application-oriented aspects are discussed/made clear, and b) the document 
title.

As the document editor, I agree with Jari and Brian that I believe the text 
meets the original brief. That said, the reality is that whatever is built at 
layer 3, and the way in which security and naming/SD are handled, will have an 
affect on applications. I've always assumed there would be a separate text 
aimed at application developers, just as I expect further texts on naming/SD, 
security, and routing protocol/prefix configuration solutions. The arch doc is 
not intended to be a standards track complete spec, rather as an Informational 
document it states the WG consensus on the path that we'll be taking in that 
future work. Could it be more concise? Yes, but having had some long threads to 
get consensus, I'm wary of significant pruning that might spark further long 
discussions. Might some of the documented principles change with the benefit of 
future hindsight? Yes, it's possible some may, but we need something to work 
from, and to point at when dojng the future work. And the RFC library is full 
of examples of -bis documents.

Do we want to spend more time now, given the desire to move ahead with the 
other work, restructuring the arch doc? It could be done, but I wonder whether 
the gain is a worthwhile tradeoff, when a separate document could be produced, 
co-authored perhaps by APPSDIR people.  Or perhaps we might instead add a short 
section early in the document on application implications, answering some or 
all of the questions SM raised.

And the title? Well, personally I have no emotional attachment to the current 
title. If the IESG were to say let's rename it Networking Principles for 
Future IPv6 Home Networks then I would lose no sleep.

Sorry if that was a bit rambling, but hopefully it makes some of the history 
and how we got where we are at least a bit clearer. If any of the above sounds 
in any way tetchy, my apologies, its the result of parsing a few thousand 
emails to get to the document that we currently have...

Tim___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] APPSDIR review of draft-ietf-homenet-arch-10

2013-09-20 Thread Tim Chown

On 20 Sep 2013, at 16:08, Michael Thomas m...@mtcc.com wrote:

 On 9/20/13 8:04 AM, Jari Arkko wrote:
 I believe the draft meets the charter goals. It's certainly a snapshot,
 and should be labelled as such, but it isn't intended to stray much
 outside layer 3, and shouldn't.
 
 Whether work is need in the application eco-system for home networks
 is a separate discussion.
 FWIW, I agree with Brian. (And I'm speaking as an author and WG participant, 
 not with my AD hat on.)
 
 
 For the benefit of those of us who weren't in Berlin, can somebody outline 
 what
 the relationship is between this group and the (m?)dnsext bof/wg?

This wasn't discussed in the dnssdext BoF.

However, the BoF steered dnssdext towards SD, and away from naming, instead 
agreeing to put a deliverable in the charter about the naming issues arising, 
which at least two people have volunteered to work on already. dnssdext also 
has multiple scenarios, including home networks, but also academic/commercial 
enterprise, pan, mesh and 'hotspot'.

The homenet architecture doc has scoped to cover routing, prefix configuration, 
security, naming and SD, so the overlap, if dnssdext is formed, is the SD 
element of homenet, and the naming issues arising. My understanding is that 
homenet will produce more specific draft(s) on naming and SD, and I think at 
the moment the most useful 'collaboration' is to ensure homenet SD requirements 
are captured in the dnssdext requirements draft. It obviously makes sense for 
there to be common work here, the question is perhaps more over timing, and 
whether a single solution is possible.

But you'll need a homenet chair or an AD for a more formal answer.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2013-08-02 Thread Tim Chown

Hi,

Just to note that the update from -09 to -10 is purely to address AD review 
comments, which were largely points of clarification in the text.

These can be seen reasonably clearly from the diff page at 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-10.txt.

Tim

On 1 Aug 2013, at 17:23, 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 Working Group of the IETF.
 
   Title   : Home Networking Architecture for IPv6
   Author(s)   : Tim Chown
  Jari Arkko
  Anders Brandt
  Ole Troan
  Jason Weil
   Filename: draft-ietf-homenet-arch-10.txt
   Pages   : 48
   Date: 2013-08-01
 
 Abstract:
   This text describes evolving networking technology within
   increasingly large residential home networks.  The goal of this
   document is to define a general architecture for IPv6-based home
   networking, describing the associated principles, considerations and
   requirements.  The text briefly highlights specific implications of
   the introduction of IPv6 for home networking, discusses the elements
   of the architecture, and suggests how standard IPv6 mechanisms and
   addressing can be employed in home networking.  The architecture
   describes the need for specific protocol extensions for certain
   additional functionality.  It is assumed that the IPv6 home network
   is not actively managed, and runs as an IPv6-only or dual-stack
   network.  There are no recommendations in this text for the IPv4 part
   of the network.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-homenet-arch
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-homenet-arch-10
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-10
 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New draft - draft-lepape-6man-prefix-metadata-00

2013-07-24 Thread Tim Chown

On 22 Jul 2013, at 10:01, Shwetha Bhandari (shwethab) shwet...@cisco.com 
wrote:

 Hello,
 
 A new draft draft-lepape-6man-prefix-metadata-00  describing 
 a method for applications to learn and influence source address selection by 
 associating
 IPv6 prefixes with meta-data when configured by
 the network is submitted. Motivation to do this and details of a prototype 
 that has been developed are included. Related drafts that define DHCPv6 and 
 ND options to realize
  conveying of meta-data associated with a prefix are 
 draft-bhandari-dhc-class-based-prefix
 and 
 draft-korhonen-6man-prefix-properties.
 Motivation for doing this work is relevant to homenet hence adding homenet wg.

Hi Swetha,

You may want to have a look at draft-anipko-mif-mpvd-arch-00, if you ahven't 
already, which is work from a design team in the mif WG. Section 4.2.2 is very 
relevant.  The metadata could also be provisioning domain information, 
perhaps.

Tim

 
 On 7/15/13 8:52 PM, internet-dra...@ietf.org internet-dra...@ietf.org 
 wrote:
 
 
 A new version of I-D, draft-lepape-6man-prefix-metadata-00.txt
 has been successfully submitted by Maico Le Pape and posted to the
 IETF repository.
 
 Filename: draft-lepape-6man-prefix-metadata
 Revision: 00
 Title: IPv6 Prefix Meta-data and Usage
 Creation date: 2013-07-15
 Group: Individual Submission
 Number of pages: 16
 URL: 
 http://www.ietf.org/internet-drafts/draft-lepape-6man-prefix-metadata-00.txt
 Status:  
 http://datatracker.ietf.org/doc/draft-lepape-6man-prefix-metadata
 Htmlized:
 http://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00
 
 
 Abstract:
This document presents a method for applications to influence the
IPv6 source selection algorithm used by the IP stack in a host.  To
do so, IPv6 prefixes are associated with meta-data when configured by
the network.  This meta-data allows the network to describe the
purpose and properties of the prefix enabling applications to make
intelligent decision when selecting a prefix.
 
 
  
  
 
 
 The IETF Secretariat
 
 
 IETF IPv6 working group mailing list
 i...@ietf.org
 Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] section 3.6.3

2013-07-15 Thread Tim Chown

On 18 Jun 2013, at 02:08, Michael Thomas m...@mtcc.com wrote:

 Yeah, I haven't actually tried listening on port 80 on my android when I 
 happen
 to be on v6 and seeing if it's walled off. I was hoping that lazywebs would 
 help
 me out here. *If* phones are not walled off now, I have no objection to this 
 section as
 it's a stake in the ground that hosts can be their own firewalls. But I'd 
 like to have
 some belief that that is true before we declare homenet firewalls obsolete.

The arch text doesn't declare edge firewalls obsolete.

It talks about realms and borders, and the need to have appropriate filtering 
between realms, including the homenet and ISP.

The case for border firewalls is reinforced by, for example, this paper: 
http://internetcensus2012.bitbucket.org/paper.html

The text about the value of firewalls is merely noting that infections picked 
up by activity from within the homenet should not be overlooked (in part the 
driver for Eric Vyncke's advanced IPv6 security draft, which he has 
subsequently lapsed).
Tim


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] IETF 87 - call for agenda items

2013-07-05 Thread Tim Chown

On 5 Jul 2013, at 08:59, Lorenzo Colitti lore...@google.com wrote:

 On Thu, Jul 4, 2013 at 10:56 PM, Michael Richardson mcr+i...@sandelman.ca 
 wrote:
 I would like the WG to spend some face time dealing with (making a list of), 
 things that need to be configured, which are not routes.
 
 (So, I would include prefixes in the list)
 
 I disagree that routes prefixes can be treated separately from routes, 
 because one router's prefixes are every other router's routes (well, either 
 that,or things don't work).
 
 Far be it from me to object to people doing more work, but... isn't it 
 premature to attempt to define a generic architecture to configure anything 
 that's possible to congfigure? That seems like it's a lot to bite off, and 
 would take a while. Can we get away with a layered approach, where we first 
 build a network with working routing, and then we figure out how to run 
 services on top of it?

That seems eminently sensible.

Tim___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-boutier-homenet-source-specific-routing-00

2013-07-05 Thread Tim Chown

On 5 Jul 2013, at 09:10, Lorenzo Colitti lore...@google.com wrote:

 On Fri, Jul 5, 2013 at 2:41 AM, Juliusz Chroboczek 
 j...@pps.univ-paris-diderot.fr wrote:
  With the exception of the text on babel, a lot of the material you
  wrote is already covered there.
 
 Your draft covers what we describe in Sections 2.1.1 and part of 2.2.2.
 That's roughly 15% of our text.
 
 Why does [TROAN] not also cover 2.2.3? Is the conceptual forwarding algorithm 
 in [TROAN] incomplete?
 
 As for 15% of our text, perhaps that's not the right metric? I mean, it 
 would certainly be possible to increase the length of [TROAN] by 6x by adding 
 irrelevant text, but I don't think that would be an improvement. :)

I don't think another draft in this space hurts as such. It describes another 
example of using source routing. It seems pretty likely, and it is already in 
the arch text, that this capability is highly desirable to solve the exit 
selection problem.

Can you remind me - what method did Markus' source routing implementation that 
was successfully demonstrated at IETF85 use?

Tim___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Fwd: Draft submission deadlines change

2013-07-03 Thread Tim Chown

Begin forwarded message:

 From: IETF Chair ch...@ietf.org
 Subject: Draft submission deadlines change
 Date: 3 July 2013 06:17:01 BST
 To: IETF Announcement List ietf-annou...@ietf.org
 Reply-To: i...@ietf.org

 Please note that for IETF 87, there is only one deadline for draft 
 submission: Monday 15th July. Previously, there had been two different 
 deadlines, one for -00 and another one for other versions. The IESG has 
 decided to experiment with just one deadline for now to simplify the set of 
 deadlines and enable easier submission of new drafts. While we realise that 
 the change comes near the deadline, we hope that you find the extra time 
 useful.

 But please do note that working group chairs will continue to make smart 
 decisions about what topics are worthwhile for discussing in a session in the 
 upcoming meeting, and will also set their agendas in a timely manner and 
 create deadlines for their working groups that must be adhered to. The 
 earlier new drafts are submitted, the more time there is to talk about them 
 on the mailing lists and consider them for the session agendas. This is 
 particularly important for BoFs.

 Jari Arkko for the IESG

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Source-specific routes in Linux [was: atomic updates...]

2013-05-20 Thread Tim Chown

On 8 May 2013, at 10:45, Dave Taht dave.t...@gmail.com wrote:

 On Wed, May 8, 2013 at 2:29 AM, Tim Chown t...@ecs.soton.ac.uk wrote:
 On 7 May 2013, at 12:08, Markus Stenberg markus.stenb...@iki.fi wrote:
 
  Yet another implementation of interest might be:
 
  https://github.com/edderick/quagga_zOSPF/
 
  [1]/[2] versions do not interoperate with it (but they interoperate with
  Arkko one); latest [3] version interoperates with it, but not Arkko..)
 
 Hi,
 
 So the github zOSPF iplementation above was done this year by an 
 undergraduate project student of mine, Ed Seabrook.  He has tested his code 
 against both Ben's and Markus' implementations, using a netkit test 
 environment, with pretty successful results overall.  Ed has given some 
 feedback to the draft authors based on his experience.
 
 It would be helpful if those comments were more public.  

Markus and Edward have discussed the issues arising from Edward's project work. 
 There is a small number of open questions/ambiguities resulting. I agree these 
should be summarised and posted here for comment to help improve the relevant 
draft(s).

 
 Ed chose to build on Quagga because he knew the bird implementations existed, 
 and wanted to show interoperability with a different platform.  
 
 CeroWrt uses quagga-RE (for BGPpgp and babel support), and if it is possible 
 to merge these patches into that branch, and the results useful, I'd be 
 delighted to do so...

It would be useful to get some code review... I'll email you off-list.

Tim___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] New revision of homenet arch doc

2013-05-10 Thread Tim Chown

Hi,

A new revision of the homenet arch doc is almost done.  We hope to push it out 
over the weekend. So if you have any burning issues you feel haven't been 
raised, now would be a good time to air them.

Thanks,
Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet-arch review (delegated ISP prefixes)

2013-03-13 Thread Tim Chown

Thanks again for the comments Jon.  All noted and I agree with Mark's response.

Tim

On 6 Mar 2013, at 04:34, Mark Townsley m...@townsley.net wrote:

 
 Replying, changing the very misleading subject. 
 
 Thanks for the comments, please see inline.
 
 On Mar 1, 2013, at 2:45 AM, Brzozowski, John wrote:
 
 Tim,
 
 
 Per your request below here are some comments pertaining to the section
 you mention below.
 
 * The section seems to hint at two extremes stable on one end and very
 dynamic i.e. at each CER reboot.  I think it is important to note that
 there is middle ground here and that providers typically have good reason
 for requiring prefix changes, largely related to network capacity
 management.  It is not clear to me if this need to be called out in the
 text, however, I thought you should know.
 * Agreed regarding /64 subnet lengths
 * This section does not differentiate between a residential service and a
 commercial or SOHO service.  Is this outlined elsewhere in the draft?
 Does it need to be?
 
 That's more of a charter question. While we should aim to create technology 
 that is generally useful outside the home, the defined scope is the home. 
 Among other things, this should help underscore the auto-configuration 
 requirement as the further you dip into SOHO territory, the more likelihood 
 that there is an administrator of some sort (whether it be a remote worker's 
 IT department or otherwise) becomes more and more prevalent. 
 
 While the SO absolutely must be able to work with our HO (what looks to 
 us like a special type of additional ISP, if you will), we stop short of, 
 say, trying to define the VPN router's security policy or whether it should 
 use IPsec Tunnel mode or GRE with Transport Mode or SSL or... 
 
 (Personally, I would like to see homenet's technology have impact outside the 
 home - we're tackling some important problems IPv6 has had for a while.) 
 
 * Note - some devices today can only utilize a /64 and nothing more these
 would not break.
 
 Good point, and this brings up a general issue of working with existing 
 non-homenet routers that support IPv6. The document should probably highlight 
 this. 
 
 * No NPTv6 please
 
 Section 2.4
 
 As such, neither IPv6 NAT or NPTv6 is recommended for use in the homenet 
 architecture.
 
 * ULAs support could be introduced at a later date
 
 Why wait?
 
 * Agreed regarding bridging avoidance
 * How is relatively stable prefix defined?
 
 Relative to changing the prefix whenever the CER is reset:
 
 Some ISPs may offer relatively stable prefixes, while others may change the 
 prefix whenever the CER is reset.
 
 Feel free to offer up a better description. I think the salient point ends up 
 being that the home network is going to have to be resilient to prefix 
 change. 
 
 
 * Good text regarding PIA
 * Regarding renumbering also note that operators take precautions to
 ensure this is seamless as well including lease time lowering in advance
 of the renumbering event.  We have been doing this for years.
 
 Consistent with RFC 4912 or not? (because that is what we are pointing to 
 right now)
 
 * Forced renumbering for privacy sounds unfortunate but based on various
 emails I have seen lately this seems to be something that must be
 supported.
 
 Yes, sadly. 
 
 * Agreed that service discovery is essential
 
 I hope these comments are useful, I recognize I was not overly verbose.  I
 hope this is a feature not a bug.  Please let know if you wish to discuss
 further.
 
 Thank you for the review and input, John.
 
 - Mark
 
 
 John
 -Original Message-
 From: Tim Chown t...@ecs.soton.ac.uk
 Date: Wednesday, February 27, 2013 5:56 AM
 To: v6...@ietf.org v6...@ietf.org
 Subject: Re: [v6ops] new draft: draft-shishio-v6ops-dpvt
 
 
 On 26 Feb 2013, at 14:07, Brzozowski, John
 john_brzozow...@cable.comcast.com wrote:
 
 
 [jjmb] incorrect I have both, just stating that I have both.  Apologies if
 I was not clear.  I also have a good # of home routers actively using IPv6
 enabled broadband today, ~3%.
 
 
 
 
 Congratulations, btw. That must be a large number when converted to real
 customers :)
 
 
 The homenet architecture assumes a CPE rather than a single host. It
 discusses ISP allocations in section 3.4.1 of
 http://tools.ietf.org/html/draft-ietf-homenet-arch-07.  As that text
 is in WGLC, any comments on that section would be welcome (preferably on
 the homenet list).
 
 
 Tim
 
 ___
 v6ops mailing list
 v6...@ietf.org
 https://www.ietf.org/mailman/listinfo/v6ops
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07

2013-03-13 Thread Tim Chown

Hi Ray,

Thanks as ever for the comments, which I have integrated and commented on 
below

On 23 Feb 2013, at 18:40, Ray Hunter v6...@globis.net wrote:

 As requested I have read draft-ietf-homenet-arch-07. Thanks everyone for
 the effort so far.
 
 IMHO I think the document is in very good shape, but that we're not
 quite there yet
 (which I guess means I'm obliged to supply comments on why I think
 that's the case).
 
 The main thrust of my comments below is an underlying feeling that we
 haven't yet fully got a handle on the boundary at the ISP/customer
 interface  the homenet/Internet interface, and that this will bite us
 later.
 
 I also think there's quite a bit of room to tighten up on nomenclature.
 e.g. home network v. homenet. ISP uplink v. Customer Internet
 connections. Border v. CER v. Border CER.
 
 Perhaps rather surprisingly, homenet is not defined anywhere.
 
 regards,
 RayH
 
 Detailed comments
 ===
 
 Section 1
 s/While at the time of writing some complex home network topologies
 exist, but most are/
 While at the time of writing some complex home network topologies exist,
 most are /
 
 s/like to avoid such/like to avoid, such/
 
 s/IPv6 with an eye/IPv6, with an eye/
 
 s/can not be affected by new /cannot be modified by new /
 
 
 /[RFC6204] defines basic requirements for customer edge routers
   (CERs).  The scope of this text is the internal homenet, and thus
   specific features on the CER are out of scope for this text./
 
 I find this particular formulation confusing.
 
 Perhaps
 /[RFC6204] defined basic requirements for customer edge routers (CERs),
 which has recently been updated with the definition of requirements for
 specific transition tools on the CER in RFC 6204-bis
 [I-D.ietf-v6ops-6204bis] i.e. DS-Lite [RFC6333] and 6rd [RFC5969]. Such
 detailed specification of CER devices is considered out of scope of this
 architecture document, and we assume that any required update of the CER
 device specification as a result of adopting this architecture will be
 handled as separate and specific updates to these existing documents./
 
 Section 1.1.
 /CER: Customer Edge Router.  A border router at the edge of the homenet./
 
 I regularly read Homenet BR or Border Router on this list used
 interchangeably with CER.
 Are they different? Equivalent? Or do we need to change our
 behaviour/definitions?

We assume that the CER has an interface to one or more ISPs, and to one or more 
internal subnets.  See section 3.2 where topology is discussed.

 This is my biggest worry. Do we have a good handle on the interface at
 the border?

The text talks about demarcation: 
Demarcation of the CER. The CER(s) may or may not be managed by
the ISP.  If the demarcation point is such that the customer can
provide or manage the CER, its configuration must be simple.  Both
models must be supported.

 Does the set of End-User network(s) in Section 3 map 1:1 with a homenet?
 I don't think so: it includes the CER.
 
 What is a Service Provider Network? The rest of the Internet that
 isn't in the homenet?
 Wouldn't harm to copy some more definitions from 6204.

Fair point, some of that has been copied.  We don't use language like 'end-user 
network' in this text though; instead we use 'homenet'.

 Section 2.1
 
 s/This is discussed later in the document./This is discussed in Section
 3.7./
 
 /border router(s)/
 See comment on 1.1 Border Router v Customer Edge Router?

Added to the definitions.

 /There will also be the need to discover which routers in the homenet
   are the border router(s) by an appropriate mechanism.  Here, there
   are a number of choices.  These include an appropriate service
   discovery protocol, or the use of a well-known name, resolved by some
   local name service.  Both might have to deal with handling more than
   one router responding in multihomed environments./
 
 Above paragraph does not make sense to me.
 Seems to be a context shift in the middle of the paragraph.
 How is a name service related to discovery of a border router?
 We're not suggesting all CER's have to be called a particular hostname?

Deleted, as it's covered under routing.

 /2.2.  Global addressability and elimination of NAT/
 Strictly speaking, NAT won't be eliminated entirely. IPv4 will still use
 NAT. IPv6 never had NAT.
 How about just /2.2.  Global addressability/
 
 s/The end-to-end communication that is potentially enabled with IPv6/
 The possibility for direct end-to-end communication on the Internet that
 will be restored by the introduction of IPv6/
 
 The Internet architecture always was, and still is, direct end-to-end
 communication. We just temporarily lost the ability to do it due to lack
 of addresses.

Indeed.  The elmination of NAT part has been left in though.

 s/on the firewall/
 on any firewall/
 
 
 Section 2.3
 s/Default Address Selection for IPv6[I-D.ietf-6man-rfc3484bis]/
 Default Address Selection for Internet Protocol Version 6 (IPv6) [RFC6724]/
 
 s/We

Re: [homenet] last call comments on section 3.7

2013-03-13 Thread Tim Chown

Comments in line...

On 28 Feb 2013, at 22:09, Michael Thomas m...@mtcc.com wrote:

 In general, I do not think this is ready to go. From what I can see, there is
 a significant amount of disagreement about whether mdns and/or sd have a
 place in the homenet architecture, and more than a little bit of groping
 around as to what the problems are that need to be solved. This section is
 both prescriptive in ways it ought not be, and speculative in ways that an
 architecture document shouldn't be doing. I personally think that enumerating
 requirements for what any solution ought to solve for is way more important,
 but is sadly lacking in this section.

The aim of the document is to discuss the principles involved.

 I think there is an unanswered question in this wg as to whether
 naming should take a posture of how to integrate local naming into a wider
 global scope, or figuring out how to adapt globally scoped naming into a
 local context. In practical terms: whether we start with mdns and .local
 and figure out how to hack it, or do we start with DNS and figure out how
 to make it work against requirements. I will again say that the lack of
 well agreed requirements for what we're doing hinders resolving this
 question.

I don't think that needs to be dictated here.  We should be able to drive that 
from the principles that we can (hopefully) reach consensus on.

 3.7.1 Service Discovery
 
 This section starts out with telling us how it will be presented to the user 
 (GUI)
 without any reference to why a user or anything else needs service discovery.
 As service discovery is not common on the internet today, I think this 
 requires
 a lot more motivation/requirements before jumping and telling us that out of
 scope GUI's will come to the rescue -- it's not even clear that 
 machine-machine
 interfaces to find and configure, say, my IP speakers to my IP home 
 entertainment
 system won't be the norm.

Service discovery *is* common in home networks today.  Currently users see such 
SD via whatever GUIs they use.  But sure, the future is likely to also include 
device to device SD.

 Bottom line: remove the how and get immediately to the why. Then we
 can have a discussion.
 
 3.7.2 Assigning Names
 
 I think this can be easily rewritten to not need any informative references 
 to yet
 to be approved drafts that are not agreed upon.

That reference to mDNS has been removed. 

 3.7.3 Namespaces
 
 It's not clear to me why a single namespace is desirable. Do rebellious 
 teenagers
 really want to be part of their fuddy-duddy parent's namespace? Does it even
 matter, architecturally? At least some motivation would be helpful. Part of my
 uncomfort here is that there is a hidden assumption that a home is an 
 indivisible
 unit. Is that really true?

A fair point, a homenet realm may have its own namespace, potentially.  Or any 
specific device could always independently use some 3rd party dynamic DNS 
service.

 I'm not sure why ISP provided naming should be considered the default: we 
 really
 don't know what will be the case, and obviously ISP's have a big downside both
 from changing ISP's, as well as the multiple-ISP's standpoint. I think that 
 we can more
 safely say that this service is just some cloud service provided somewhere 
 on the
 net since there isn't any locality requirement that I'm aware of.

Downgraded to 'likely'.

 This section dwells in solution space far more than I think it ought, and is 
 highly
 speculative (eg, .sitelocal, ulqdn, etc). Instead of speculating, it would be 
 better
 to say what characteristics we want, and what requirements we need to fulfill.

Trimmed a little in response.

 3.7.4 Homenet name service
 
 Somewhere in this document we really need to make clear how mobility figures 
 into
 all of this. That is, what happens when things move around and what the 
 implications
 are for naming, both in my home, and on yours.
 
 I don't think we should compare and contrast mdns as being zeroconf with
 the implication that DNS is not. You can achieve zeroconf using service
 announcement and not require multicast at all (at least not to announce the
 service). In fact, until we have something resembling rough consensus, I don't
 really think it's appropriate to favor one or the other in this document.

I don't think the document does favour either.  
 
 Again, ditch the references to ISP with something cloud-like.

Good idea. Or both.

 I don't understand what mDNS has to do with service announcement to a
 repository. mDNS is a way to find names in lieu of a repository (that is, each
 device is it's own authoritative name service). Sending naming/service 
 announcements
 to a repository is an adjunct of the repository protocols and has nothing to 
 do
 with mDNS that I can figure out.

Well, a device in a homenet today will commonly use both unicast and multicast 
DNS, the former for internal devices, the latter for external.

 More speculation about mDNS vs. SRV records

Re: [homenet] last call comments on section 3.7

2013-03-13 Thread Tim Chown

On 13 Mar 2013, at 03:32, Ted Lemon mel...@fugue.com wrote:

 I'm curious as to why Michael's comments garnered only a single reply—I think 
 he raised some good points.   

The question is whether no one agrees.  There have been previous comments that 
the text both in this section and in general is OK.

 I've been reviewing the architecture document, and it's a hard read.   I 
 think it's actually pretty good in principle, and I know that part of the 
 reason it's so heavy is because the authors are trying to represent a 
 plurality of opinions, including my own.

I think that's fair comment as to why the document is the way it is.  It's very 
difficult to be concise when there are so many views and comments being made. 
It can be pruned further for sure if you/the chairs want that. 

I noticed when reviewing the text to see if the hipnet draft was compliant or 
not that it is indeed hard to spot the requirements/principles.

I asked previously if bullet-point requirements would help, but note we 
previously had enumerated requirements/principles (which I thought were very 
clear and made the text much easier to glance through) but the WG requested 
these were instead presented as plain text paragraphs/wording.

We could restore bullet-point notes in each section, whether numbered or not. 
Another option is to add some kind of summary section listing them.

 But in a lot of cases I think it would improve the document to pare it fairly 
 heavily—to try to tease out the essence of what everyone wants, and then 
 leave out the details of how they propose to get it.   The architecture 
 should be what we want, not how we propose to get it.   We don't all agree on 
 how to get it, and perhaps those questions should be addressed separately.

It was always agreed that the specifics pointing to 'drafts in progress' would 
be trimmed in the final version, along with change notes. These have been left 
in as 'discussion pointers' while the architecture text is live.  I've noted to 
removed these in the candidate -08. 

 I can offer more detailed comments, but it would be a pretty big message, 
 which nobody would feel enthusiastic about reading.

Well, you could wait for a -08 resulting from last call, or make them now...

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] last call comments on section 3.7

2013-03-13 Thread Tim Chown

On 13 Mar 2013, at 18:41, Michael Thomas m...@mtcc.com wrote:

 On 03/13/2013 11:28 AM, Tim Chown wrote:
 On 13 Mar 2013, at 03:32, Ted Lemon mel...@fugue.com wrote:
 
 I'm curious as to why Michael's comments garnered only a single reply—I 
 think he raised some good points.
 The question is whether no one agrees.
 
 There are 5 authors listed on the draft, and it's been two weeks before 
 anybody
 has said a word. If the authors don't agree, they can at least say so. 
 Otherwise
 what is the point of last call comments?

The comments are being looked at, so that the key issues can be discussed here 
in Orlando. 

Personally, I have had a huge workload outside of the IETF for the past month.

The question is whether we have rough consensus within the WG.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Why do homenets need SD? (was: last call comments on section 3.7)

2013-03-13 Thread Tim Chown

On 13 Mar 2013, at 19:24, Michael Thomas m...@mtcc.com wrote:

 On 03/13/2013 11:20 AM, Tim Chown wrote:
 
 3.7.1 Service Discovery
 
 This section starts out with telling us how it will be presented to the 
 user (GUI)
 without any reference to why a user or anything else needs service 
 discovery.
 As service discovery is not common on the internet today, I think this 
 requires
 a lot more motivation/requirements before jumping and telling us that out of
 scope GUI's will come to the rescue -- it's not even clear that 
 machine-machine
 interfaces to find and configure, say, my IP speakers to my IP home 
 entertainment
 system won't be the norm.
 Service discovery *is* common in home networks today.  Currently users see 
 such SD via whatever GUIs they use.  But sure, the future is likely to also 
 include device to device SD.
 
 Service discovery is *not* common. Only in the rarified environment of
 IETF could such a statement be made with a straight face. Just because
 appletalk, lan manager protocols, etc provide such functionality doesn't
 mean they are in common use in homes.

I guess we'll have to agree to disagree there.

 In any case, this isn't responsive to the larger point that this section
 doesn't provide any motivation of why SD is needed or even important,
 and if it is, what the homenet requirements are.

The need for SD has been implicit from the start of the process.  No one else 
has questioned that need, as yet.  If others agree with you, it would be good 
if they spoke up now.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Scope of Work: broken kit deployments out-of-scope

2013-03-13 Thread Tim Chown


On 11 Mar 2013, at 12:45, Ted Lemon mel...@fugue.com wrote:

 On Mar 11, 2013, at 1:31 AM, H. Peter Anvin h...@zytor.com wrote:
 That doesn't give the option to the server, though... the client has to ask 
 for one or the other.
 
 What I would suggest is that if the client doesn't get a big enough 
 allocation, it request an additional allocation, rather than that it try to 
 anticipate what the server will return and prepare for the worst.

I agree with Ran's original comments.  These are reinforced in the candidate 
-08 text.

Are there IPv6 ISPs out there who would allocate an additional (say) /60 if the 
CER requested an additional prefix?  Would it not be simpler to state that the 
prefix in use in the homenet from any ISP should be contiguous, and sufficient 
in size for the homenet's requirement, as per 6177 (which recommends 
significantly more than a single /64?)

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] ISP-delegated IPv6 prefixes (3.4.1) in draft-ietf-homenet-arch-07

2013-03-13 Thread Tim Chown

On 9 Mar 2013, at 02:05, Michael Richardson mcr+i...@sandelman.ca wrote:

 
 STARK, == STARK, BARBARA H bs7...@att.com writes:
STARK Switching ISPs is not an option at this time. This is the
STARK only provider who offers something close to 30Mbps at a
STARK consumer-friendly price. I'm not going to move, either. In
STARK the world of trade-offs and doing what's right for me, the
STARK /64 is among the least of my concerns. For IETF homenet to
STARK attempt to influence CE router vendors to force me to care,
 
 I think you should, until your ISP and your CE router are sorted out,
 turn off your IPv6 at your router, and just use Teredo or an explicit
 tunnel with sixxs.net for your work-at-home IPv6 needs.
 
 I don't think that homenet should accomodate the particular set of
 constraints that you have.  I believe that they will go away.
 
 (me: I prefer end to end connectivity over the multi-dozen-megabit/s
 consumer-style, high-latency, bufferbloated incument telco junk. Mind
 you, they can't even spell IPv6...)

The candidate -08 has a reference to BCP 157.

And text basically as per Ran stated.  If you get a /64, then if you're in a 
single subnet dual-stack network you may well be fine.  But you can't expect to 
route to further subnets internally under the architecture as defined (though 
you are of course free to manually configure bridging mode or NPTv6 
yourself...).

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap?

2013-03-13 Thread Tim Chown

On 5 Mar 2013, at 17:52, Michael Behringer (mbehring) mbehr...@cisco.com 
wrote:

 Our draft shows a way to do that in a relatively simple and secure way. I 
 believe this is a fundamental requirement in a homenet; there are other ways 
 to more or less achieve this goal - that needs to be discussed. But we should 
 have the discussion. 

If you have text to propose for the arch text, please do so.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Scope of Work: broken kit deployments out-of-scope

2013-03-13 Thread Tim Chown

On 13 Mar 2013, at 20:11, Andrew McGregor andrewm...@gmail.com wrote:

 I've met one that will allocate more /48s if you ask, and have met a DHCPv6 
 server implementation that would give you a new prefix if you generated a new 
 client ID.  So, yes, they easily can exist and in at least one case do.

OK, thanks, but presumably the ISP wouldn't hand out such additional prefixes 
indefinitely?  

The question is whether the arch text should say if you don't get a big enough 
prefix, before entering some error state, try asking for more...?

Tim

 
 
 On Wed, Mar 13, 2013 at 3:59 PM, Tim Chown t...@ecs.soton.ac.uk wrote:
 
 On 11 Mar 2013, at 12:45, Ted Lemon mel...@fugue.com wrote:
 
  On Mar 11, 2013, at 1:31 AM, H. Peter Anvin h...@zytor.com wrote:
  That doesn't give the option to the server, though... the client has to 
  ask for one or the other.
 
  What I would suggest is that if the client doesn't get a big enough 
  allocation, it request an additional allocation, rather than that it try to 
  anticipate what the server will return and prepare for the worst.
 
 I agree with Ran's original comments.  These are reinforced in the candidate 
 -08 text.
 
 Are there IPv6 ISPs out there who would allocate an additional (say) /60 if 
 the CER requested an additional prefix?  Would it not be simpler to state 
 that the prefix in use in the homenet from any ISP should be contiguous, and 
 sufficient in size for the homenet's requirement, as per 6177 (which 
 recommends significantly more than a single /64?)
 
 Tim
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] isp's as namespace providers

2013-03-13 Thread Tim Chown

On 13 Mar 2013, at 21:12, Michael Thomas m...@mtcc.com wrote:

 On 03/13/2013 02:01 PM, Ted Lemon wrote:
 On Mar 13, 2013, at 4:14 PM, Michael Thomas m...@mtcc.com wrote:
 Why is it likely? This can very easily be rewritten to be agnostic as to
 who provides a global naming service for a homenet. If there isn't anything
 extenuating, that is what should be done.
 I think agnostic is good, but illustrative examples are good as well, and 
 the two I would suggest are that the ISP provides a mechanism for naming, 
 and that a cloud service provides a mechanism for naming.   Obviously you 
 can also set up your own name service, but I don't think this is a good 
 example for the use case we are trying to address.
 
 Illustrative works for me too. The reason I push back on ISP is because it 
 can
 be misconstrued to have some topological and/or security necessity. Which I'm
 pretty sure the authors are not intending.

Agreed. The likely comment stems from the most likely provision coming from 
the entity the homenet already has a relationship with by entering into a 
contract for connectivity.  There are opportunities for other providers to 
offer services in this area in the future, for sure.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] namespaces

2013-03-13 Thread Tim Chown

On 13 Mar 2013, at 21:24, Michael Thomas m...@mtcc.com wrote:

 On 03/13/2013 01:55 PM, Ted Lemon wrote:
 On Mar 13, 2013, at 4:11 PM, Michael Thomas m...@mtcc.com wrote:
 The reason I bring this up is that I don't understand why a single namespace
 is desirable. What are the implications if that is not the case? What 
 assumedly
 bad thing will happen if that's not the case? What goodness flows if it is?
 If you have devices that need to be addressed outside of the homenet, then 
 you have to have a global namespace, and of course that means a single 
 namespace.   And if you wander to another homenet, and devices are in the 
 same namespace, you may wind up turning up your host's (or their neighbor's) 
 air conditioning.
 
 And this is both orthogonal to my concern, as well as worth mentioning in
 this section, I think.

Right, so that's the concern that's been aired over both homenets using 
.sitelocal (or similar).

I agree with Mike though that we should say at least one global name space, 
as other name spaces may map to the homenet devices/prefixes.  Or you may have 
a homenet that (for example) has rooms with lodgers who may want to use their 
own name spaces in that part of the homenet.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] will CER's be globally authoritative resolvers?

2013-03-13 Thread Tim Chown


On 13 Mar 2013, at 22:49, Michael Thomas m...@mtcc.com wrote:

 On 03/13/2013 03:39 PM, Don Sturek wrote:
 Hi Mike,
 
 I think disconnected use is a MUST and not aspirational.
 
 I would not want my networked printer to stop working, my smart appliances
 to not be able to read my meter, etc. all because my ISP decided to do
 some maintenance.
 
 Ok, let's assume it's a MUST. That seems to imply that when I'm
 at home I want my CER to serve up RR's for my domain, but when
 I'm away something in the cloud is serving up my RR's because
 I don't want to deal with DoS against my CER, etc, etc.

This is an issue discussed in the mglt-homenet-front-end-naming-delegation and 
mglt-homenet-naming-delegation drafts.  Though those specific references will 
be removed from the final text. 

If your CER is being DOSed though, chances are you may not be able to access 
any home services anyway?

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Why do homenets need SD?

2013-03-13 Thread Tim Chown

On 13 Mar 2013, at 23:47, Michael Thomas m...@mtcc.com wrote:

 On 03/13/2013 03:18 PM, Ray Bellis wrote:
 On 13 Mar 2013, at 17:13, Ted Lemon mel...@fugue.com wrote:
 
 On Mar 13, 2013, at 5:08 PM, Michael Thomas m...@mtcc.com wrote:
 I don't have any statistics but it wouldn't shock me to hear that usb vs.
 networked printers are 10:1 more common.
 It would shock me.   Bonjour printing Just Works.
 
 It's also the only way I know of to print from an iDevice.
 
 The 2.5 year old HP B110a printer I have at home has never been physically 
 connected to a computer.
 
 It has virtual USB drivers for Windows, but for everything else it's 
 DNS-SD.

 What I find most telling is that after 25 years, printers are still the 
 canonical
 example of the need for SD. But printers have entire programs/wizards that
 support their existence, so they're really lousy as a canonical example. It 
 would
 be nice for things to attach themselves to my net and not require their awful 
 apps
 to be installed.

So you never use music collections on other devices, videos from a video 
server, or throw your laptop screen to a local plasma display for easy viewing 
by a group?  Those are just typical examples of common uses.  The problem 
though is that without manual intervention you only see the services in your 
local subnet.

Our university pretty much only has networked printers now, as they're 
managed and thus need to be monitored by the contractor.  My homenet has two 
networked printers; I don't want to rely on a specific host being up to be able 
to print. 

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [v6ops] new draft: draft-shishio-v6ops-dpvt

2013-02-27 Thread Tim Chown


On 27 Feb 2013, at 19:57, Owen DeLong o...@delong.com wrote:

 I'm not on the home net list and I need another list like I need a hole in 
 the head.

I know the feeling :)

 However, I think section 3.4.1 is reasonably well written. I think it would 
 be good if
 the following were added:
 
 ISPs are strongly encouraged to issue /48s to residential customers whenever 
 requested or hinted by the home gateway.
 
 Also, it appears that section 3.4.1 assumes a custom will change ISPs by 
 disconnecting provider A and then connecting provider B. It does not appear 
 to make a provision for connecting provider B and having a period of 
 transition with dual prefixes. This possibility should be considered and 
 addressed, IMHO.

Thanks for the comments. I've added that into the WGLC feedback list.

Tim

 Owen
 
 
 On Feb 27, 2013, at 5:56 AM, Tim Chown t...@ecs.soton.ac.uk wrote:
 
 
 On 26 Feb 2013, at 14:07, Brzozowski, John 
 john_brzozow...@cable.comcast.com wrote:
 
 [jjmb] incorrect I have both, just stating that I have both.  Apologies if
 I was not clear.  I also have a good # of home routers actively using IPv6
 enabled broadband today, ~3%.
 
 Congratulations, btw. That must be a large number when converted to real 
 customers :)
 
 The homenet architecture assumes a CPE rather than a single host. It 
 discusses ISP allocations in section 3.4.1 of 
 http://tools.ietf.org/html/draft-ietf-homenet-arch-07.  As that text is in 
 WGLC, any comments on that section would be welcome (preferably on the 
 homenet list).
 
 Tim
 ___
 v6ops mailing list
 v6...@ietf.org
 https://www.ietf.org/mailman/listinfo/v6ops
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2013-02-11 Thread Tim Chown

Hi,

Just a note to highlight that this new version is available. I suspect the 
chairs will want to push this to WGLC as soon as possible. All comments very 
welcome. If you wish to suggest changes, please give specific text if possible.

As a small note, the .xml version of the -07 was run through ispell, but the 
.txt not refreshed from that, so there's a small number of typos that will be 
corrected.  More substantive comment is required at this stage...

Thanks,
Tim

On 10 Feb 2013, at 18:42, 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 Working Group of the IETF.
 
   Title   : Home Networking Architecture for IPv6
   Author(s)   : Tim Chown
  Jari Arkko
  Anders Brandt
  Ole Troan
  Jason Weil
   Filename: draft-ietf-homenet-arch-07.txt
   Pages   : 46
   Date: 2013-02-10
 
 Abstract:
   This text describes evolving networking technology within
   increasingly large residential home networks.  The goal of this
   document is to define a general architecture for IPv6-based home
   networking, describing the associated principles, considerations and
   requirements.  The text briefly highlights specific implications of
   the introduction of IPv6 for home networking, discusses the elements
   of the architecture, and suggests how standard IPv6 mechanisms and
   addressing can be employed in home networking.  The architecture
   describes the need for specific protocol extensions for certain
   additional functionality.  It is assumed that the IPv6 home network
   is not actively managed, and runs as an IPv6-only or dual-stack
   network.  There are no recommendations in this text for the IPv4 part
   of the network.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-homenet-arch
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-homenet-arch-07
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-07

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] draft-ietf-homenet-arch

2013-02-01 Thread Tim Chown

Hi,

A new -07 version of draft-ietf-homenet-arch will be published over the weekend 
to incorporate comments made to date on the current version.  

If you have any specific (especially new) comments to make on that current 
version, now would be a good time to do so.

For the current version see: 
http://tools.ietf.org/html/draft-ietf-homenet-arch-06

Hopefully the -07 can move quickly to WGLC.

Tim


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Revised Homenet Agenda (again)

2012-11-07 Thread Tim Chown


On 7 Nov 2012, at 14:36, Mark Townsley m...@townsley.net wrote:

   IETF 85
   Homenet Working Group
   7th November 2012
   
   09:00 - 09:10  Note Well, Jabber Relay, Note taker(s)
   
   09:10 - 09:25  Homenet Architecture Update
   
  draft-chown-homenet-arch-06 (Tim Chown - 15m) 
To be clear, that's draft-ietf-homenet-arch-06.
http://tools.ietf.org/html/draft-ietf-homenet-arch-06

tim
  
   09:25 - 10:10  Security and Border Discovery
   
   9:25  draft-kline-default-perimeter-01 (Erik Kline - 15m)
   9:40  draft-boot-homenet-brdp-00 (Teco Boot - 15m)
   9:55  draft-behringer-homenet-trust-bootstrap-00 (Michael Behringer 
 - 15m)
   10:10 - 11:00  Routing and Prefix Assignment
   
  10:10  draft-arkko-homenet-prefix-assignment-03 (Jari Arkko - 15m)
  10:25  draft-haddad-homenet-multihomed (Damien Saucez - 15m)
  10:40  source + dest based routing (Jari Arkko, Lorenzo Colitti - 
 20m)
   
   
   11:00 - 11:25  Naming and Service Discovery
   
  11:00 update from MDNSEXT BoF (Tim Chown - 10m)
  11:10 draft-mglt-homenet-front-end-naming-delegation-01 (D. Migault 
 - 10m)
 
11:20  Wrap-up - (Arch Doc Questions)
  11:25 draft-troan-homenet-naming-and-sd (Ole Troan - time permitting)
  11:30  Close
   
   
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00

2012-10-23 Thread Tim Chown

On 23 Oct 2012, at 09:54, Ray Bellis ray.bel...@nominet.org.uk wrote:

 
 On 23 Oct 2012, at 09:50, Lorenzo Colitti lore...@google.com
 wrote:
 
 It can't deprecate it, but it can say that NPT66 is not supported in the 
 homenet architecture.
 
 Indeed.

We can capture those sentiments in -07, and use Brian's draft as just one 
example of why. 

When I said 'it was on the table', that was as something that could well 
happen. Personally, I would rather see the approach in 
ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 shorter term, and hope for 
better support in routing protocols longer term.

BTW, please note that RFC 3484 is now replaced by RFC 6724. It may take some 
time to adjust :)

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] service announcement vs service discovery

2012-10-22 Thread Tim Chown

Hi Mike,

Thanks for the comments.

On 19 Oct 2012, at 18:16, Michael Thomas m...@mtcc.com wrote:

 On 10/19/2012 09:36 AM, Tim Chown wrote:
 
 
 We can take comments towards a -06 over the weekend.  The most substantial 
 changes are in the Naming and Service Discovery section (3.7), so if you 
 have limited time please focus your reading there.
 
 One thing that I'm not sure whether it's been discussed or not is service 
 announcement.
 By service announcement, I mean where instead of multicasting out a message 
 looking
 for the canonical printer with all of its nasty properties especially for 
 things with batteries
 and lossy/slow networks, a device would instead announce its presence to 
 something
 that would later serve it up (eg, bind9, say).

I think this is covered in 3.7.4, certainly possible.

 That is, if we can posit a dns repository in our home edge routers, we can 
 avoid some
 of the insanity that ensues when you say that something MUST be strictly 
 zeroconf.
 I think we are long past the days where strict zeroconf should be the driving 
 principle;
 littleconf should be a valid option too.

And I don't think this possibility is excluded at all by the current arch text 
either. It talks of an authoritative name service running on the CER, with a 
dynamic registration service (e.g. dyndns).  I have added 'as far as possible' 
to the unmanaged text.

 Service announcement could also feed into things like Search where instead of
 having preset categories which make sense perhaps only to those who chose the
 category at the factory, we could also have structured and/or free-form text 
 with
 lots of  keywords and other identifying information that an indexer might 
 find useful.

That's probably straying a little into the UI side.  Again, I don't think we 
preclude that.  

 Mechanistically, we already have things like IXFR for DNS, so it's not likely 
 that
 this is wholesale invention, though it may well involve some tweaks. IXFR also
 gives the possibility for enrollment and access control which is pretty 
 problematic
 with service discovery.

I think these issues may come up in the mdnsext BoF - I encourage you to join 
that list and give comment there.

Tim


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt

2012-10-22 Thread Tim Chown

 must at the very
 least co-exist with the Internet name service./
 
 I would submit that it is highly desirable that the homenet name service
 IS the Internet name service.
 No gateways. No proxies. No 2 way synching of content. No timeout
 synchronisation problems.
 No 2nd guessing authority. No complexity of extending DNS e.g. via DNSSEC.
 No problems with highly mobile devices changing tethering.
 
 /As described in [I-D.mglt-homenet-naming-delegation], one approach is
 to run an authoritative name service in the homenet, most likely on the
 CER, which caches results, and to have the homenet's ISP provide a
 secondary name service./
 
 This exactly matches my comment above for 3.7.3. And I think this draft
 is an excellent straw man that any alternatives should have to beat to
 be considered for inclusion in homenet as the default solution. I have
 no problem with better or extended, if that can be clearly demonstrated.

OK, I think we're in agreement here then :)  If not, please clarify.

 /This might imply that state information should be distributed in the
 homenet, to be recoverable by/to the new CER./
 Or backed up to a configuration server hosted at the ISP? e.g. a new DNS
 primary could populate itself from the ISP secondary server if it
 detects it has a blank zone file (by querying your own zone name for NS
 glue records in the delegating DNS).

Yes, that could be an ISP service.  I'll add text.

 Section 3.7.7
 Must also include search domains for local FQDN-derived zones.

Added.

 Nits
 
 
 s/homenet/Homenet/g ?

I'm OK with little h.

 s/and is thus need not be/and thus need not be/
 
 Section 2.5
 s/it is better to not expose/it is better not to expose/
 
 s/ideally zero configuration/minimal, and ideally zero configuration/
 
 Section 3.2.1
 s/Routing cycles within a topology are in a sense good in that they
 offer redundancy./Loops within a routed topology are in a sense good in
 that they offer redundancy./
 s/Bridging cyslces can be dangerous /Bridging loops can be dangerous /
 s/It is only cycles using simple repeaters/It is only loops using simple
 repeaters/

Corrected - I thought I'd nailed all those!

 Section 3.2.2
 
 s/Some may or may not be walled gardens./Some may or may not provide a
 default route to the Pubic Internet./
 
 
 Section 3.5.1.
 s/Where multicast is routed cross a homenet/Where multicast is routed
 across a homenet/
 
 Section 3.6.3
 s/testomony/testimony/
 
 Section 3.7.5
 s/ISP should should not /ISP should not /
 
 Section 3.7.6
 s/dicovery/discovery/

All nabbed, thanks - my ispell mistake, sorry.

 The open issue is whether the LQDN should be used alongside a global
 FQDN if one is available (with appropriate mappings/CNAMEs and reverse
 entries to the global FQDN as proposed I think by Curtis), or if the
 global domain is available then no local domain should be used. 
 I prefer the latter.

OK, that's pretty much what 3.7.3 says.  Thanks.

 To me the easiest way to achieve a simple and clear
 implementation is to define that a homenet is either stand-alone (with
 ULA + local name space) or normally attached (with FQDN and GUA and
 sufficient timers and caches to keep it up during temporary outages of
 the ISP link). I suspect that implementing sometimes attached homenets
 with coexistence of ULA  GUA and LQDN  FQDN is going to be a lot
 tougher. But maybe some developers can jump in and keep me honest on
 that assumption.
 
 regards,
 RayH

Thanks for all the comments. -06 will be out very soon.

Tim

 
 
 One item where there seemed to be a lack of a firm conclusion (despite
 some firm statements each way) was the question of using a single
 global name space or separate internal and external name spaces. The
 current text essentially says:
 * The default is to use an ISP-provided domain in the homenet, but
 with the user able to use an independent domain name instead if preferred.
 * If no global domain is available, the homenet uses either a ULQDN
 (preferred) or ALQDN, and these are scoped to the local homenet (i.e.
 the homenet can only be reached remotely if using a global domain).
 
 
 
 Tim
 
 On 19 Oct 2012, at 17:00, internet-dra...@ietf.org
 mailto: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 Working Group of the
 IETF.
 
 Title   : Home Networking Architecture for IPv6
 Author(s)   : Tim Chown
 Jari Arkko
 Anders Brandt
 Ole Troan
 Jason Weil
 Filename: draft-ietf-homenet-arch-05.txt
 Pages   : 43
 Date: 2012-10-19
 
 Abstract:
  This text describes evolving networking technology within
  increasingly large residential home networks.  The goal of this
  document is to define an architecture for IPv6-based home networking,
  while describing the associated principles, considerations

[homenet] draft-ietf-homenet-arch-06.txt

2012-10-22 Thread Tim Chown

Hi,

The -06 that I've just posted includes some comments made since last Friday.

Tim

On 22 Oct 2012, at 17:23, 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 Working Group of the IETF.
 
   Title   : Home Networking Architecture for IPv6
   Author(s)   : Tim Chown
  Jari Arkko
  Anders Brandt
  Ole Troan
  Jason Weil
   Filename: draft-ietf-homenet-arch-06.txt
   Pages   : 44
   Date: 2012-10-22
 
 Abstract:
   This text describes evolving networking technology within
   increasingly large residential home networks.  The goal of this
   document is to define an architecture for IPv6-based home networking,
   while describing the associated principles, considerations and
   requirements.  The text briefly highlights the specific implications
   of the introduction of IPv6 for home networking, discusses the
   elements of the architecture, and suggests how standard IPv6
   mechanisms and addressing can be employed in home networking.  The
   architecture describes the need for specific protocol extensions for
   certain additional functionality.  It is assumed that the IPv6 home
   network is not actively managed, and runs as an IPv6-only or dual-
   stack network.  There are no recommendations in this text for the
   IPv4 part of the network.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-homenet-arch
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-homenet-arch-06
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-06

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt

2012-10-19 Thread Tim Chown

Hi all,

The architecture text has been updated to -05.

See: http://tools.ietf.org/html/draft-ietf-homenet-arch-05

We can take comments towards a -06 over the weekend.  The most substantial 
changes are in the Naming and Service Discovery section (3.7), so if you have 
limited time please focus your reading there.

One item where there seemed to be a lack of a firm conclusion (despite some 
firm statements each way) was the question of using a single global name space 
or separate internal and external name spaces. The current text essentially 
says:
* The default is to use an ISP-provided domain in the homenet, but with the 
user able to use an independent domain name instead if preferred.
* If no global domain is available, the homenet uses either a ULQDN (preferred) 
or ALQDN, and these are scoped to the local homenet (i.e. the homenet can only 
be reached remotely if using a global domain).

The open issue is whether the LQDN should be used alongside a global FQDN if 
one is available (with appropriate mappings/CNAMEs and reverse entries to the 
global FQDN as proposed I think by Curtis), or if the global domain is 
available then no local domain should be used.

Tim

On 19 Oct 2012, at 17:00, 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 Working Group of the IETF.
 
   Title   : Home Networking Architecture for IPv6
   Author(s)   : Tim Chown
  Jari Arkko
  Anders Brandt
  Ole Troan
  Jason Weil
   Filename: draft-ietf-homenet-arch-05.txt
   Pages   : 43
   Date: 2012-10-19
 
 Abstract:
   This text describes evolving networking technology within
   increasingly large residential home networks.  The goal of this
   document is to define an architecture for IPv6-based home networking,
   while describing the associated principles, considerations and
   requirements.  The text briefly highlights the specific implications
   of the introduction of IPv6 for home networking, discusses the
   elements of the architecture, and suggests how standard IPv6
   mechanisms and addressing can be employed in home networking.  The
   architecture describes the need for specific protocol extensions for
   certain additional functionality.  It is assumed that the IPv6 home
   network is not actively managed, and runs as an IPv6-only or dual-
   stack network.  There are no recommendations in this text for the
   IPv4 part of the network.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-homenet-arch
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-ietf-homenet-arch-05
 
 A diff from the previous version is available at:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-05

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] draft-ietf-homenet-arch-04

2012-10-11 Thread Tim Chown

On 1 Oct 2012, at 13:59, RJ Atkinson rja.li...@gmail.com wrote:

 Consumer oriented providers handing out /64s
 to home nets is also bad.
 
 Agreed (s/consumer-oriented/any/). 
 
 HomeNet WG ought to be VERY clear about this.
 
 HomeNet WG ALSO ought NOT enable or encourage 
 such behaviour by encouraging ANY scenarios 
 where SLAAC can't work properly.


There is clear consensus in this thread that homenet must support SLAAC and 
DHCPv6, and thus the architecture text should reinforce the comments that Ran 
has made.

The residential deployments I am aware of in Europe all support at least /60 
and up to /48.  The most common is probably /56.  We should not add complexity 
to homenet scenarios and break SLAAC to account for ISPs that might currently 
only offer a /64.  

There have been recent discussions elsewhere I believe on limitations of prefix 
delegation in certain types of mobile networks where only a /64 is offered 
currently, but those one would hope are temporary until DHCPv6-PD is supported 
there.

Curtis can of course take proposals to 6man for discussion, but the 
architecture text here would not include those.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] -03 comments?

2012-07-02 Thread Tim Chown


On 2 Jul 2012, at 10:23, Ray Bellis wrote:

 In the heat of the discussion around Olafur's posting on naming, it may 
 have escaped people's notice that Tim posted a -03 revision of our core 
 architecture draft late last week.
 
 We'd like to encourage you all to _thoroughly_ review and comment on this 
 document.  I hope to see only one or two more significant revisions before we 
 can punt this to the IESG.

Thanks Ray,

There is a changelog against -02 in the appendix.  The main style difference is 
that the bulleted points introduced in -02 have been removed in -03 through 
chair guidance.

The aim is to push out a -04 before Vancouver, integrating the naming/SD 
material from the current list discussion.  There's also one or two other 
comments to catch up on, e.g. about pushing stuff from 2.5 on borders into 
section 3 where we talk about the network model.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

2012-03-21 Thread Tim Chown


On 20 Mar 2012, at 21:25, Brian E Carpenter wrote:

 On 2012-03-20 21:51, Anders Brandt wrote:
 
 It is a surprise to me that ULA addresses are not by default routable within 
 the site.
 I can easily imagine a number of LLN border routers which autonomously 
 allocate
 different ULA prefixes for use within their individual LLN subnets.
 
 IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they
 cover an entire enterprise or home network, but not if they cover a subset.
 
 Meeting a ULA address outside the local prefix will cause the LLN node to 
 forward
 its IP packets to the default gateway (border router) of the LLN subnet. 
 This way
 packets can travel between LLN subnets using normal routing with long-term 
 stable
 ULA addresses. We need the stable addresses for control-style applications 
 in LLNs.
 
 Obviously it requires a routing protocol in the (homenet) LAN but are there 
 other issues?
 
 It doesn't just require a routing protocol; it also requires a routing policy
 that knows which routers have to block the ULAs (plural). That seems a lot
 more complex that a rule that says only a border router originates and 
 delegates
 a ULA prefix, because that border router would also know to block the
 prefix across the border.

So we need to determine what the homenet arch text will say on this. 

I think the assumption so far has been that, as per PD8 in 
draft-ietf-homenet-arch-02, 
one router would be elected the master to delegate /64 ULA prefixes within the
homenet, both to ULA-only LLNs and to links that also have a GUA prefix.  If 
there's 
an assumption an LLN router will not support that, and instead generate its own 
/48 
ULA, we need to talk about that, or any other scenario that will lead to 
multiple /48 ULAs 
in a single homenet site.

The arch text currently says that ULAs should be used (CN1) and that ULAs 
should be 
preferred for internal communications to GUAs (section 2.4).  It doesn't say 
how connections 
from outside the homenet can be made to internal ULA-only devices.

The 3484-bis text has changed the default ULA preference to protect against ULA 
leakage,
so if you now want ULAs preferred you need to somehow inject the specific site 
/48 ULA
being used with high precedence into the policy table (and as also pointed out 
here if your 
site is using less than a /48, you should also have some way to learn what the 
site prefix 
length is). In the homenet case is that injection achieved on receipt of an RA, 
or would it 
require the proposed DHCPv6 option to be used (which may not be widely 
implemented 
for some time, and the DHCPv6 server still needs to learn the ULA to put in the 
option)? 

On the one hand homenet is saying we'd prefer to use ULAs by default without 
needing
some magic to achieve it while 6man is saying we need to protect against ULA 
leakage, 
so if you want to prefer ULA for internal connection stability figure out the 
magic.  

This needs to be mapped to words for the homenet arch text.

Tim

 
 Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
 and discuss it over on v6ops.
 
Brian
 
 
 Thanks,
  Anders
 You'll find the above logic in the current 3484bis draft.
 
 -Dave
 
 IETF IPv6 working group mailing list
 i...@ietf.org
 Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 
 IETF IPv6 working group mailing list
 i...@ietf.org
 Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Issue tracker

2012-03-21 Thread Tim Chown

Hi,

The chairs have suggested using the issue tracker for the architecture text.  
These should appear to the list soon.

We can split out additional issues with the tracker as they're identified.  The 
naming and service discovery areas are still in their relative infancy.

Please feel free to comment on the tracker topics so we can see if we have 
consensus forming prior to the Paris session.

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Security goals

2012-03-11 Thread Tim Chown


On 11 Mar 2012, at 05:28, Cameron Byrne wrote:
 On Mar 10, 2012 5:05 PM, Tim Chown t...@ecs.soton.ac.uk wrote:
 
  a) An assumption of Simple Security with default deny on the CER.
 This implies PCP or uPnP to support punching holes.  The text
  also talks about addressability vs reachability.
 
 I still disagree with this premise that we must default deny and have a mess 
 of inadequate and complex  signalling to compensate . Can someone articulate 
 a threat model that requires this default deny and state tracking ? Or must 
 we put the cart before the horse without facts presented (maybe I missed that 
 detailed presentation of threats) ? Because win2k required a network based 
 firewall, we must always cripple e2e?
 
 Or, can homenet simply say home devices must be independently secure, may 
 have host based firewalls, or they must be placed in a properly screened 
 subnet of fundamentally flawed devices that require network security controls 
 and multi device port coordination ?
 
 

The -02 that is coming soon still has simple security as a default position, 
but also states a requirement for support of RFC 6092's transparent mode.  That 
should be something a residential user can enable simply, if they choose to do 
so.

Tim

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Framing homenet borders and default policies

2012-03-11 Thread Tim Chown

The -02 coming soon makes it clear the examples are just that.

Tim

On 6 Mar 2012, at 20:19, Randy Turner wrote:

 After a 2nd reading of the current arch doc, I'm still not sure where the 
 bounding box is around our work - seems like the language in section 3 
 should be tightened up - or rephrased to emphasize that the list of topology 
 support is normative and not a set of examples
 
 Randy
 
 
 
 On Mar 6, 2012, at 11:38 AM, Michael Richardson m...@sandelman.ca wrote:
 
 
 {I was cleaning out email that I felt I SHOULD read}
 
 Mark == Mark Townsley m...@townsley.net writes:
   Mark For the 3 base cases listed above (Local, Internet, Guest) If
   Mark we can solidly answer the 5 (6) questions below, we've
   Mark accomplished well what is within our scope:
 
   Mark 1. Do we share or accept assigned prefixes over this link?
   Mark 2. Do we share or accept routing information over this link?
   Mark 3. Do we share or accept services information over this link?
   Mark 4. Do we share or accept naming information over this link?
   Mark 5. Do we allow application traffic to flow over this link? If
   Mark so, do we apply a firewall function?  (6.) Do we allow
   Mark troubleshooting protocols over this link (ping, traceroute -
   Mark could be part of the FW question in #5)?
 
 What are we going to do with this?
 Does this discussion go into the architecture document?
 
 -- 
 ]   He who is tired of Weird Al is tired of life!   |  firewalls 
  [
 ]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net 
 architect[
 ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
 driver[
  Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE
  then sign the petition. 
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Discovery [snmp for monitoring home network]

2012-03-10 Thread Tim Chown


On 10 Mar 2012, at 23:53, Brian E Carpenter wrote:

 Cutting to the chase (and this answers Don too):
 
 There may be good reasons to consider SLP, but I'd
 like to see how these line up against the home net goals.
 
 Exactly. It's perfectly fine by me if SLP is not the right
 answer for future homenets, but this should be a goal-based
 decision, not based on what happens to be deployed on
 single-subnet homenets today.

Indeed; the arch text is capturing those goals, so some discussion and 
definition of those is very welcome.  

Tim

 
 Regards
   Brian
 
 On 2012-03-11 11:02, Kerry Lynn wrote:
 On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter
 brian.e.carpen...@gmail.com wrote:
 On 2012-03-10 08:42, Paul Duffy wrote:
 On 3/9/2012 1:55 PM, Brian E Carpenter wrote:
 On 2012-03-10 05:00, Jim Gettys wrote:
 ...
 I was just observing comments I came across in code being used for
 printer discovery.
 Why would we consider anything other than SLP for service discovery?
 Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more
 traction in the consumer space than SLP.
 
 Please do correct if I'm wrong.
 Aren't we trying to influence the future rather than document the
 past?
 
 Brian,
 
 I'm not sure of your point; mDNS and DNS-SD are Standards Track
 drafts currently in the RFC-Editor queue and there are tens of millions
 of deployed mDNS responders.  If SLP is running in my home, I'm
 not aware of it.
 
 We need a name-based service discovery solution. That's also a
 requirement emerging from 6renum. I think we should decide what's
 the best recommendation; it may end up being DNS-based, but this
 is what SLP was designed for, so IMHO it should be considered.
 
 Just as homenet has Largest Possible Subnets, Fewest Topology
 Assumptions, and Self Organizing principles, perhaps we should
 also consider Fewest Protocols as well.  To my mind, using DNS for
 both service discovery and name resolution has many advantages.
 These are documented in the above mentioned drafts, but I would
 just point out three: simple DNS-based discovery is trivial to add to
 an existing resolver, mDNS has been demonstrated in constrained
 environments (e.g. it places limits on name length and character
 set), and it is based on a well-understood (and well-supported)
 protocol.  There may be good reasons to consider SLP, but I'd
 like to see how these line up against the home net goals.
 
 I will add that I've co-authored a draft that considers extending mDNS
 to site scope and would like to receive any comments people have:
 https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/
 
 Thanks, -K-
 
 This is clearly *not* what SNMP was designed for.
 
  Brian
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet Architecture Interim Meeting

2011-09-21 Thread Tim Chown


On 19 Sep 2011, at 22:01, Mark Townsley wrote:
 
 Procedurally, the WG can do what it wants to here, there is no official 
 method for declaring a document a WG document. Different WGs operate in very 
 different manners in this regard.
 
 What I am suggesting here is that a draft should be published any moment now 
 (Tim?), and that I want people to read it and let us know if it is an OK 
 start for a work in progress for the WG to actively try to finish. If there 
 are no other competing architecture documents to evaluate, I'd like to see it 
 move towards being a WG document rather quickly (we're supposed to be 
 finished by December). This by no means says the document is finished or even 
 has consensus of the WG in its current state, just that it is the document 
 the WG will try and turn into a final product. All this means is that it 
 becomes the working group's document rather than Tim, Jari, Jason and 
 Ole's document. 


Sounds fine.

Now that the update is out, I would just say that so long as the WG knows this 
is the homenet architecture draft, it's status is not that important, except 
that the charter target was WG adoption by the end of this month, and we 
shouldn't treat those targets too lightly.

From the perspective of the interim meeting, I believe the agenda of that 
meeting includes slots for each of the five requirements (routing, naming, 
security, etc) so we should be agreeing as much as we can at the very least on 
the general principles we will follow for those slots, if not the architecture 
in full. 

Tim
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

83 matches

Mail list logo