Skip to main content

IPv6 Home Networking Architecture Principles
draft-ietf-homenet-arch-17

Revision differences

Document history

Date Rev. By Action
2014-10-22
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-09-15
17 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-09-04
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-07-25
17 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-07-25
17 (System) RFC Editor state changed to EDIT
2014-07-25
17 (System) Announcement was received by RFC Editor
2014-07-24
17 (System) IANA Action state changed to No IC from In Progress
2014-07-24
17 (System) IANA Action state changed to In Progress
2014-07-24
17 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation - Defer::AD Followup
2014-07-24
17 Cindy Morgan IESG has approved the document
2014-07-24
17 Cindy Morgan Closed "Approve" ballot
2014-07-24
17 Cindy Morgan Ballot approval text was generated
2014-07-04
17 Tim Chown New version available: draft-ietf-homenet-arch-17.txt
2014-06-12
16 Tim Chown New version available: draft-ietf-homenet-arch-16.txt
2014-06-09
15 Adrian Farrel
[Ballot comment]
I am tired of the discussion of this document.

I am alarmed that a paragraph that was inserted to address my Discuss and …
[Ballot comment]
I am tired of the discussion of this document.

I am alarmed that a paragraph that was inserted to address my Discuss and on the basis of which I cleared my Discuss at version 14 was removed from version 15 with the change log comment "removed spurious paragraph".

This leaves me with the option of reasserting my Discuss or Abstaining. I choose to Abstain because I no longer have confidence that this work will be produced with the relevant level of care or integrity.
2014-06-09
15 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Abstain from No Objection
2014-06-09
15 Tim Chown New version available: draft-ietf-homenet-arch-15.txt
2014-06-08
14 Adrian Farrel [Ballot comment]
Thanks for the efforts that went into addressing my Discuss
2014-06-08
14 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2014-06-08
14 Tim Chown New version available: draft-ietf-homenet-arch-14.txt
2014-03-13
13 Adrian Farrel
[Ballot discuss]
Updated further  for revision -13.

Thanks for continuing to chip away at my Discuss on this important document.

=======

I had a Discuss …
[Ballot discuss]
Updated further  for revision -13.

Thanks for continuing to chip away at my Discuss on this important document.

=======

I had a Discuss point about the statement in 3.5 that said

|  It is desirable, but not absolutely
|  required, that the routing protocol be able to give a complete view
|  of the network, and that it be able to pass around more than just
|  routing information.

This now reads

> Using
> information distributed through the routing protocol, each node in
> the homenet should be able to build a graph of the topology of the
> whole homenet including links, nodes, connectivity, and (if the
> routing protocol supports them) link metrics.

I still feel that this is a rather limited view of the way routing can work and I don't see anything in the document on which to build this "requirement".

Your objectives are may be more easily stated in terms of what you want the routing protocol to achieve in terms of routing packets, not through statements of how the routing protocol will distribute information in support of those ends.

But this text is converging. Thanks for taking out the mention of "non-routing information". That was my major concern.

I'm going to hold on to this Discuss for one more iteration in the hope that we can replace the "how to implement it" type of requirement with a "what we want to achieve" type of requirement.

I think you want to be able to make next hop decisions to achieve packet forwarding that follows CSPF for a number of potential constraints including link and node status, hop count, and link metric.

(Note that this issue is converging on one of my Comments that says "what paradigm do you want routing to arrive at?")
2014-03-13
13 Adrian Farrel
[Ballot comment]
Also updated for -13 with some points degraded from Discusses.

==========

Note that the new text in 3.5 seems to have introduced some …
[Ballot comment]
Also updated for -13 with some points degraded from Discusses.

==========

Note that the new text in 3.5 seems to have introduced some redundancy (not to mention a spelling error).

  The homenet unicast routing protocol should be based on a previously
  deployed protocol that has been shown to be reliable and robust, and
  that allows lightweight implementations, but that does not preclude
  the selection of a newer protocol for which a high quality open
  source implemenation becomes available.  The availability of open
  source implementations is an important consideration.

===================

| There is no discussion in 3.5 of preferring links or path lengths. It is
| sort of fundamental if you say routing is needed to say what paradigm
| you hope will be employed. Should self-configuration include assigning
| metrics according to node/link capabilities?

> I think that should be included in the solution text(s) taken to routing area.

Happy to have the discussion there, but what are the requirements of a homenet?
Is there a requirement to prefer shorter paths (fewest hops) or to prefer paths
for other reasons? Is this dependent on the underlying technology?

Routing people, I am confident, can build the protocols to do what is required.
What they cannot do is guess how the network should behave. Seems kind of like
an architectural principal to me.
2014-03-13
13 Adrian Farrel Ballot comment and discuss text updated for Adrian Farrel
2014-03-10
13 Benoît Claise
[Ballot comment]
The new changes address my DISCUSS. Thanks

This one is a new comment, which you should really change (RC editor note would do …
[Ballot comment]
The new changes address my DISCUSS. Thanks

This one is a new comment, which you should really change (RC editor note would do it)

OLD:

  The specific protocols required to facilitate homenet management and
  monitoring are out of scope of this document.

NEW:
  Specifying the required protocols to facilitate homenet management and
  monitoring is out of scope of this document.



Below I left the comments that have not replied to/addressed AFAICT.
Up to your AD to follow up or not at this point in time.


-

  [RFC6204] defines basic requirements for customer edge routers
  (CERs).  This document has recently been updated with the definition
  of requirements for specific transition tools on the CER in
  [I-D.ietf-v6ops-6204bis], specifically 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.  Further, the scope of this text
  is the internal homenet, and thus specific features on the WAN side
  of the CER are out of scope for this text.

I don't understand if, in this architecture you expect all CERs to be compliant with RFC 6204 or [I-D.ietf-v6ops-6204bis]? At least partly for the features on the homenet side?
You mentioned "Such detailed specification of CER devices is considered out of scope of this architecture document", but I don't understand what it means. Do you mean "irrelevant": "Such detailed specification of CER devices is considered irrelevant for this architecture document"?
But I guess that the some features, which are required by 6204/6204bis are required.
I read the above paragraph multiple times, and could not get it.


- Section 3.2.3 Dual-stack topologies

  That said, it is desirable that IPv6
  works better than IPv4 in as many scenarios as possible.

What does "works better" mean?

-
It seems that a big problem in home networks today is with WIFI, actually multiple WIFIs and combination of (powerline, wifi). I'm surprised to see so little about this aspects in the draft.

- I start to see home wifi routers that are forced by the service provider to offer free hot spots for other customers of this ISP (for example: http://www.voo.be/en/internet/wi-free/) Is this considered as a guest network in your draft? Any specific requirements in that area. Or maybe this is outside of the border of the homenet...

- Below is some more feedback from Jouni Korhonen (JiK), part of this OPS-DIR review (I don't think I've seen a reply to this).

2.4.  Unique Local Addresses (ULAs)

  ...
  Note that unlike private IPv4 RFC 1918 space, the use of ULAs does
  not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT
                    ^^^^^^^^^^^^^^^^^^^^

JiK: Might be just me but what exactly is "host-based NAT"? I know what you
are after but is this term defined somewhere? I found at least two
interpretations for it.

3.2.2.  Network topology models

  ...
  For IPv6 homenets, the network models described in [RFC6204] and its
  successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum,
  be supported.
  ...

JiK: I would reword "successor RFC 6204-bis" to just "successor".

  ...
      used for one or more providers, or multiple CERs.  The presence of
      multiple CERs adds additional complexity for multihoming
      scenarios, and protocols like PCP that need to manage connection-
      oriented state mappings.
  ...

JiK: Reading the document so far it is unclear to me how PCP (and without expanding
the acronym, nor giving a reference to it) relates to the number of CERs.

3.2.2.2.  B: Two ISPs, Two CERs, Shared subnet

  ...
  example shows one shared subnet where IPv6 nodes would potentially be
  multihomed and receive multiple IPv6 global addresses, one per ISP.
  ...                            ^^^^^^^^^^^^^^^^^^^^^^

JiK: I take prefix is meant here, not address.

3.2.4.  Multihoming

  ...
  routed to the proper egress to avoid BCP 38 filtering if exiting
  ...

JiK: I would reword "BCP 38 filtering" to "BCP 38 ingress filtering".

JiK: The discussion of multihoming seems to neglect the case where the CER
would actually speak some routing protocol to its upstream provider. I take
that is done purposely but I cannot find any text saying why it has been
neglected. I understand it does not fit the existing model of consumer
subscriptions but in Section 2.6. it is said that "IPv6-only networking will
be deployed first in 'greenfield' homenet scenarios", which would at least to
me imply some more freedom on choices how to deploy a service.

3.3.4.  Homenet realms and borders

  ...
  e.g. for some specific Grid or LLN-based network, and for these to be
  ...                    ^^^^

JiK: a reference or explanation about Grid is missing in the I-D.

3.4.1.  Use of ISP-delegated IPv6 prefixes

  ...
  prefixes longer than /64 (which would break SLAAC), use of NPTv6, or
  ...           

JiK: SLAAC is never expanded.

  Thus a homenet CER should request, for example via DHCP-PD, that it
                                                      ^^^^^^^

JiK: First time occurrence.. not expanded nor reference given.


3.4.2.  Stable internal IP addresses

  ...
  filtering at the border(s) of the homenet, as mandated by RFC 6024
  requirement S-2.                                          ^^^^^^^^
  ...

JiK: Should be RFC 6204.

3.4.3.  Internal prefix delegation

JiK: It seems that DHCP PD is used with and without '-' in other polaces
in the document . Choose one style.

3.5.  Routing functionality

  ...
  Multiple interface PHYs must be accounted for in the homenet routed
  ...                ^^^^

Jik: PHY is used twice in the document. Never expanded or explained. Same
for MoCA..

3.5.  Routing functionality

  ...
  environment, but as a guideline a maximum convergence time at most 30
  seconds should be the target.
  ...

JiK: For my curiosity.. how did we end up to this 30 secs convergence time
again?

  networks.  IPv6 VM solutions may also add additional routing
                  ^^

JiK: Although explained in the terminology & abbreviations I would expand
VM on the first occurrence.

3.6.1.  Addressability vs reachability

  protocol such as UPnP or PCP [RFC6887].  In networks with multiple
                    ^^^^

JiK: No reference given to UPnP. (well in terminology and abbreviations yes
but would add one here too). Maybe expand UPnP on the first occurrence also.

3.6.5.  ULAs as a hint of connection origin

  As noted in Section 3.6, if appropriate filtering is in place on the
  CER(s), as mandated by RFC 6024 requirement S-2, a ULA source address
                          ^^^^^^^^

JiK: Should be RFC 6204

3.7.1.  Discovering services

  ...
  Users will typically perform service discovery through GUI interfaces
  ...
  an appropriate API for the discovery to be performed.
  ...

JiK: Expand GUI and API on the first occurrences.

3.7.3.  Name spaces

  ...
  Unique Locally Qualified Domain Name
  ...

JiK: give the abbreviation as well (for the similar style as in the
rest of the document is using).

  ...
  Also, with the introduction of new 'dotless' top level domains, there
  ...

JiK: A reference to some document?

  ...
  available by name via an Internet name space, and that a 'split view'
  is preferred for certain devices.
  ...

JiK: A reference to a document that describes the 'split view' ?

3.7.4.  The homenet name service

  ...
  to support appropriate name service security methods, including
  DNSSEC.
  ...

JiK: Add a reference to DNSSEC.

3.7.5.  Independent operation

  ...
  Having an independent local trust anchor is desirable, to support
  secure exchanges should external connectivity be unavailable.
  ...

JiK: What is the local trust anchor? Reading so far it is not immediately
clear to me.

3.7.6.  Considerations for LLNs

  ...
  solutions for use by the Constrained Application Protocol (CoAP) in
  ...

JiK: Give a reference to CoAP?

3.7.7.  DNS resolver discovery

  ...
  local FQDN-derived zones should be included.
  ...

JiK: It is not clear to me what local FQDN-derived zones
are supposed to mean.
2014-03-10
13 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2014-03-04
13 Tim Chown New version available: draft-ietf-homenet-arch-13.txt
2014-02-23
12 Adrian Farrel
[Ballot discuss]
Updated for revision -12.

I am glad that this work is being done by the IETF, and I think it is
very important …
[Ballot discuss]
Updated for revision -12.

I am glad that this work is being done by the IETF, and I think it is
very important to the future of the Internet. However I still have a
number of comments some of which are at the level of Discusses.

=======

| Section 3.1.1
|
| It is desirable to reuse existing protocols where possible, but at
| the same time to avoid consciously precluding the introduction of new
| or emerging protocols.
|
| I am pretty sure this says "Use a protocol."
|
| If you are not precluding a new protocol when an existing one can be
| reused, then are you actually going to satisfy your desire?
|
| It is desirable to have cake. At the same time, we should not preclude
| eating it.
|
| However, I would also note that the homenet charter has something to say
| on this topic, and I don't believe this document should be at variance
| with what the charter says.
|
| I think the resolution of this issue is to remove this discussion from
| the document. It really has nothing to do with the architecture.

You originally said:
> - have left 3.1.1 in, marked as an open issue (one to be raised in the
>    session this week).  This principle has had consensus in the WG
>    from the outset.

Mark said:
> I agree that the current text could use improvement, perhaps borrowing
> more from what is in the charter already. We can talk about that in our
> homenet meeting.

You have now said:
> I understand what you're saying here, but this text has been in the
> document pretty much as-is since its first version, for 2+ years, when
> it was agreed in the Philadelphia interim meeting, and has not drawn
> any comments to remove it previously.  So we assume consensus
> remains on it being there.

That bugs me :-)
Me: The text is unclear
You: Yes, but we have consensus on it
I have to say, having consensus does not make it magically any clearer!

Let me restate my point (which I don't think is a large point, but one that will
guide how the WG operates as it works on this topic).
If the text intended to say:
- If there is an existing protocol that can be used, prefer to use it.
- If there is no such existing protocol, use a new or emerging one.
- Make no design decisions that make it impossible to use a new or
  emerging protocol.
...then simple rewording can make the difference.

But charter says:
The group will apply existing protocols to handle the five
requirements above. For prefix configuration, existing protocols are
likely sufficient, and at worst may need some small enhancements, such
as new options. For automatic routing, it is expected that existing
routing protocols can be used as is, however, a new mechanism may be
needed in order to turn a selected protocol on by default
...and you can't rewrite your charter in an RFC!

So, how about...

OLD
  It is desirable to reuse existing protocols where possible, but at
  the same time to avoid consciously precluding the introduction of new
  or emerging protocols.
NEW
  Existing protocols will be used to meet the requirements of home
  networks. Where necessary, extensions will be made to those
  protocols. When no existing protocol is found to be suitable, a
  new or emerging protocol may be used. Therefore, it is important
  that no design or architectural decisions are made that would
  preclude the use of new or emerging protocols.
END

Now, I could live with that despite my philosophical debate with Mark about
whether the discussion of which protocols to use belongs in the architecture
document, because at least my proposed text brings the topic back to the
architecture. (Personally, I think architectures are abstract and functional so
they don't mention more than the existence and purpose of protocols.)

=============

| 3.5 says...
|
| As per prefix delegation, it is assumed that a single routing
| solution is in use in the homenet architecture.  If there is an
| identified need to support multiple solutions, these must be
| interoperable.
|
| ...which is internally inconsistent (either there is one solution or
| not) and in conflict with the discussion of LLNs within the home.

You suggested later that

> - the LLN interoperability would presumably come from a gateway
> between the 'regular' homenet and the LLN.

...and maybe that is what you mean by "interoperable" in this context. If so...

s/these must be interoperable/it must be possible to achieve interworking
through the use of a gateway function/

(We normally say that two implementations are interoperable when they can speak
to each other on the wire.)

But let's unpick this a bit.
You say "a single routing solution is in use in the homenet architecture." You
do not say "a single routing solution is in use in any given homenet."
There is a big implication here that, for example, there will not be support by
the Homenet WG for both OSPF and ISIS solutions. How will the WG choose?

==============

| 3.5 says some odd things
|
|  It is desirable, but not absolutely
|  required, that the routing protocol be able to give a complete view
|  of the network, and that it be able to pass around more than just
|  routing information.
|
| I should think it highly undesirable that the routing protocol be
| able to give a complete view of the network. That is neither something
| that is the job of a routing protocol, nor something that is good to do
| to low-capacity devices be they routers or hosts.
|
| We can also have a philosophical discussion if you like about whether a
| routing protocol should be employed to pass around non-routing
| information. Such a use, either by flooding or by more direct means, is
| likely to make the routing aspects of the routing protocol slower to
| converge and more expensive to run.
|
| This seems to be in conflict with 3.3.3's preference to avoid flooding
| and burning of scarce resources.
|
| This issue might be resolved by separating out the requirements/desires
| in terms of functions (we want to be able to get information between
| nodes in a p2p, p2mp, or broadcast way) from how it is achieved (through
| routing).

You said:
> - the "complete view' part has been extensively (as in probably 100+ emails)
> discussed; I'd be wary of reawakening that if we changed it...

I have no fear.
"Complete view" is clearly not what is intended. You do not want to know the
shoe size of the stand-in network operator's third child by his first marriage.
So this could be qualified, and easily. For example: "Using information
distributed through the routing protocol, each node in the homenet should be
able to build a graph of the topology of the whole homenet including links,
nodes, connectivity, and link metrics."

Then you added:
> This currently says:
>
>"It is desirable, but not absolutely required, that the routing protocol be
> able to give a complete view of the network, and that it be able to
> pass around more than just routing information."
>
> That still leaves room for a separate configuration protocol; there has
> been list discussion about this.

I am not worried that you would preclude a separate configuration protocol. I am
not worried that you would preclude a separate management protocol. I *am*
worried that you will overload your routing protocol using it for the
distribution of other *arbitrary* information not related to routing. As I say,
this is contrary to your desire not to burn scarce resources (especially since
the use of a flooding protocol seems to be in vogue for the solutioneers).

It is also something that the Routing Area has come to see as risky. Routing
protocol implementations are built with assumptions of network size and network
information. We have learned that, as these parameters change, implementations
and even protocols become unstable.

It would really help if the architecture, instead of saying "we could shuffle
this information (although we're not quite sure what it is) using the routing
protocol" said "we have identified the following types of information that need
to be moved around the network from these nodes to those nodes." It could then
go on to give advice about which are the appropriate types of mechanism for each
type of information
2014-02-23
12 Adrian Farrel
[Ballot comment]
Also updated for -12 with some points degraded from Discusses.

==========

You have

> "The homenet unicast routing protocol should be based on …
[Ballot comment]
Also updated for -12 with some points degraded from Discusses.

==========

You have

> "The homenet unicast routing protocol should be based on a previously
>  deployed protocol that has been shown to be reliable and robust, and
>  that allows lightweight implementations.  The availability of open
>  source implementations is an important consideration. "

There is an unspoken implication that the *current* availability of open source
of poor quality is more important that the future availability of open source of
high quality. You might want to polish that out, but I shan't delay you on it.

===========

Wrt BCP 38, section 3.5 certainly makes the point.  It would have been nice
if the earlier sections explained themselves a bit better. For example, in 2.2

  It should thus be considered the norm for devices on IPv6 home
  networks to be multi-addressed, and to need to make appropriate
  address selection decisions for the candidate source and destination
  address pairs for any given connection.

...could state why there is a need (which is, I think, BCP 38).

===========

| Section 3.1.2.
|
|  Where possible, any requirement for changes to hosts and routers
|  should be minimised, though solutions which, for example,
|  incrementally improve capability with host or router changes may be
|  acceptable.
|
| I think this doesn't say anything.
| What are the real requirements?
|- backward compatible
|- not require ejection of equipment from the home?
|- migration paths need to be written?
|- acceptable if full function not available with old equipment?

> - added 3.1.2 detail as an open issue
>
> The WG meeting at IETF88 appeared to have consensus to
> leave this as is when we ran through it.

I hear you. But my question is not answered! What are the requirements?

Perhaps part of the trouble is with the word "minimised" which some people take
to mean "set to zero" while others interpret as "keep relatively low".

Actually, I see that this section has been updated in a way that helps.

It still seems a little odd to be doing all this work if changes to routers are
to be resisted. For example, if I want to do routing based on source address, I
really am going to have to change my routers.

===================

| Section 3.2.1 and 3.2.2.1
|
| "Loop" may not be the best word to describe a topological construct
| in which there are redundant paths. Loop tends to be used to describe
| what happens when a packet is trapped. Such loops are not good :-)
|
|- "loops" is probably Ok here; the meaning seems clear.

Well, a graph theorist might agree with you, but I think the term is misleading
and possibly wrong.

"Alternate paths" are good, "loops" are bad.

=====================

| Section 3.5
|
|  The routing environment should be self-configuring, as discussed
|  previously.  An example of how OSPFv3 can be self-configuring in a
|  homenet is described in [I-D.ietf-ospf-ospfv3-autoconfig].
|  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.
|
|What is the value of the sentence about an example of how OSPF can be
|made self-configuring? Why would you say this an not observe how IS-IS
|is able to self-configure? Suggest deleting the solution-specific stuff.

> It’s simply an example - happy to take Ted’s decision on this.  No strong
view.
>
> At present the example is left in, but yes it could be either.

Maybe in the light of the potential for wars in this area and the (assumed by
me) fact that the WG has not made a selection of one and only one of the IGPs,
this example is better left out or supplemented by the statement that ISIS is
already self-configuring.

===============

| There is no discussion in 3.5 of preferring links or path lengths. It is
| sort of fundamental if you say routing is needed to say what paradigm
| you hope will be employed. Should self-configuration include assigning
| metrics according to node/link capabilities?

> I think that should be included in the solution text(s) taken to routing area.

Happy to have the discussion there, but what are the requirements of a homenet?
Is there a requirement to prefer shorter paths (fewest hops) or to prefer paths
for other reasons? Is this dependent on the underlying technology?

Routing people, I am confident, can build the protocols to do what is required.
What they cannot do is guess how the network should behave. Seems kind of like
an architectural principal to me.

================

| It is unclear to me whether 3.5.2 is a statement about routing (it is in
| section 3.5) or about a more general attribute such that the section
| should be placed elsewhere.

> Just a general principle.

Maybe move it out of 3.5, then.

===============

|Section 3.7
|
|  The homenet requires devices to be able to determine and use unique
|  names by which they can be accessed on the network.
|
|I suspect you mean that the names are not used by any other device, not
|that the device must choose a single name.
|
|See also 3.7.2

> Yes.

But no change to the text?
2014-02-23
12 Adrian Farrel Ballot comment and discuss text updated for Adrian Farrel
2014-02-18
12 Stewart Bryant
[Ballot comment]
Having read through the text again and reviewed the comments from other members of the IESG, I am of the view that the …
[Ballot comment]
Having read through the text again and reviewed the comments from other members of the IESG, I am of the view that the long term interests of the Internet would be best served by the removal of the routing text from this draft and the definition of the routing components in a working group that will get better scrutiny by routing specialists, i.e. adopting of the routing protocol requirements and definition by a WG within the router area.

"A routing protocol that can make routing decisions based on source and destination addresses is thus desirable, to avoid upstream ISP BCP38 ingress filtering problems."

The reason for this requirement could be given greater clarity in the text.
2014-02-18
12 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2014-02-14
12 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2014-02-14
12 Joel Jaeggli
[Ballot comment]
was discuss

The secdir review revists the question of default allow/deny policy and the documents non-position, position, on that. I am actually aware …
[Ballot comment]
was discuss

The secdir review revists the question of default allow/deny policy and the documents non-position, position, on that. I am actually aware of the discussion in the working group and the nuance of the respective arguments having been a contributor to the discussion.

I personally would rather see:

The document declare a lack of consensus with respect to which is more appropriate.

Describe the policy as situationaly appropriate (e.g. there are consensus cases where one model is appropriate or the other model is appropriate).

this is not strongly held but it's worth discussing.
2014-02-14
12 Joel Jaeggli [Ballot Position Update] Position for Joel Jaeggli has been changed to No Objection from Discuss
2014-02-14
12 Tim Chown New version available: draft-ietf-homenet-arch-12.txt
2013-11-04
11 Richard Barnes
[Ballot comment]
Thanks to the authors for adding S3.3.5 to discuss propagation of ISP-sourced information to endpoints.  I hope the WG will keep this problem …
[Ballot comment]
Thanks to the authors for adding S3.3.5 to discuss propagation of ISP-sourced information to endpoints.  I hope the WG will keep this problem in mind as they develop more concrete recommendations.
2013-11-04
11 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss
2013-10-30
11 Stephen Farrell
[Ballot comment]

Thanks for responding to my discuss points and including
some appropriate text on those that weren't silly:-)

I want to buy one of …
[Ballot comment]

Thanks for responding to my discuss points and including
some appropriate text on those that weren't silly:-)

I want to buy one of these soon, (well, when a local ISP
has a v6 deal that works), so please keep up the good
work.
2013-10-30
11 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to Yes from Discuss
2013-10-21
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-10-21
11 Tim Chown IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2013-10-21
11 Tim Chown New version available: draft-ietf-homenet-arch-11.txt
2013-09-26
10 Cindy Morgan State changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer
2013-09-26
10 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2013-09-26
10 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-09-26
10 Sean Turner
[Ballot discuss]
Thanks for slogging through the process to get here.  Hopefully you won't find these too annoying and I too think this is a …
[Ballot discuss]
Thanks for slogging through the process to get here.  Hopefully you won't find these too annoying and I too think this is a valuable effort.  Can't wait to tweak my security settings at home to irk my wife when this all arrives in the wild :)

0) (sorry a hobby horse but I gotta ask) How come there's no recommendation on whether or not DHCPv6 authentication should be used in the home or between the home and the ISP?

1) This is something that I suspect will get cleared up on the call:

How much of this is being driven by the belief that homenets will be multi-homed?  I guess I'm asking whether we're designing a bunch of stuff for the power user or whether most folks can get along just fine without multiple subnets, multi-homing, etc.
2013-09-26
10 Sean Turner
[Ballot comment]
I support my fellow AD's discuss points.

0) abstract: Is it that network is getting geographically larger or that it's getting more populated …
[Ballot comment]
I support my fellow AD's discuss points.

0) abstract: Is it that network is getting geographically larger or that it's getting more populated or both?

  This text describes evolving networking technology within
  increasingly large residential home networks.

maybe in the abstract:

  This text describes evolving networking technology within
  residential home networks that are increasing in size and
  density of IP-enabled devices (e.g., toasters).

Always want to give a nod to Jari's toaster.  Did it ever get a name?

1) I support Brian's 1st point about this also being a requirements draft as well as an architecture.  Maybe that can't be helped, but I did think that some uses of the term requirement could just be totally dropped.  Further, s3 says:

The aim of this text is to outline how to construct advanced IPv6-
based home networks involving multiple routers and subnets using
standard IPv6 addressing and protocols [RFC2460] [RFC4291].

But then you're not going to do that you're going to add requirements for new protocols - which fine in my mind I'd just like the words to match up.

2) s1: r/that we would like to avoid/that should be avoided

3) s1: Might also be good to say why you don't want these:

  Such networks also
  typically employ solutions that we would like to avoid, such as
  private [RFC1918] addressing with (cascaded) network address
  translation (NAT)[RFC3022], or they may require expert assistance to
  set up.
 
e.g., private addresses leak and then we ended up with AS112 ... etc.

4) s1.1: Would have added subnet in the list. Add informative reference for WPA2?

5) s2.1: should this be "to Ethernet" as opposed to "from Ethernet":

Constraining the flow of certain traffic from Ethernet links to much
lower capacity links thus becomes an important topic.

The idea being you'd want as much to run on ether as you could right to help with the poor constrained device bandwidth?

6) This might just be a wording thing so it might be easy to clear up:

s2.1 contains the following

  Likewise, there may be a need to separate building control or
  corporate extensions from the main Internet access network, or
  different subnets may in general be associated with parts of the
  homenet that have different routing and security policies.

The corp extensions part kind of threw me for a loop.  Are those the ISP's extensions, a home user's employer's extension when they're using a VPN, some sensor gone rogue in my house ... ?

6) s2.2: I think it does a pretty good job of distinguishing between reachability and addressability.  A back pointer to s3.6 would definitely help here because I originally thought out wait that's it but was later appeased somewhat.  I do think the last sentence in the first paragraph should be changed to include the words "and possibly malicious traffic" because it's not just like you're being bothered by the traffic it's some script kiddie (or worse) trying to hack in to your new smarttv to watch you watch tv.

7) s3: Does this sentence line up with the new requirements being introduced:

The aim of this text is to outline how to construct advanced IPv6-
based home networks involving multiple routers and subnets using
standard IPv6 addressing and protocols [RFC2460] [RFC4291].

Shouldn't it say and point out where we think tweaks need to added.

8) s3.6:  I'd like to hear some more on the call about Joel's idea, but the mitigation discussed most is filter - firewalls are kind of glossed over.  Should there be some kind of recommendation about having a default firewall turned on?

9) s2.2/s.6: Firewalls vs Filtering.  I kind of tripped over this because it seems like in s3.6 a firewall is just a big filter, but in s2.2 it mentioned applications so I thought maybe an application layer firewall, but there's also stateful firewalls.  I assume you're not discussing application layer firewalls at all in this draft, but it might be good to explain the difference between plain filtering and stateful filtering in the terminology section.
2013-09-26
10 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2013-09-26
10 Brian Haberman
[Ballot discuss]
There are several items within this document that I think need discussing...

1. Even though this document is labeled an architecture, I am …
[Ballot discuss]
There are several items within this document that I think need discussing...

1. Even though this document is labeled an architecture, I am concerned when I see seemingly random requirements documented in various parts of the document.  Are there a concrete set of requirements that can be documented in a standalone section (ideally with some justifications)?

2. Section 1.1 (and other parts of the draft) talks about borders & realms and their impact on forwarding unicast and multicast traffic.  I am concerned that these two terms need to be scoped properly to bring them in line with the RFC 4007, specifically the definition of scopes & zones (section 5 of 4007).  Of note, this draft says those types of boundaries need to be automagically created, yet 4007 specifically states that boundaries between zones must be configured by an administrator.

3. The introduction states that this draft is focused on the internals of the homenet "and thus specific features on the WAN side of the CER are out of scope".  However, section 2.6 discusses transition scenarios that are already defined in RFC 6204 (6204bis).  What is the purpose of having transition text in *this* draft?

5. Does the discussion of walled gardens in section 3.2.4 (next-to-last paragraph) need an explicit reference to section 4.2.1 of RFC 3002?  The guidance provided in 3002 is very explicit and I would not want homenet to go against that consensus.

6. This is more of a general concern, but I am seeing a lot of zero-config magic being wished for in this document.  While it is a noble goal, I don't see how it dovetails with other aspects such as home vs. guest subnets, device enrollments vs. unmodified hosts, and the need for policies in some scenarios.  There are some aspects of a complex network that require some level of human intervention to get right.  How would a router know that an attached subnet should be treated as the guest subnet?  How does a router know that a particular upstream link is to a corporate VPN?

7. I think it is inappropriate to discuss IPv6 address allocation policies in section 3.4.1.  The fourth paragraph in that section is on dangerous grounds trying to mandate what an ISP allocates to a customer.

8. Section 3.6.5 seems rather odd to me.  Trusting a packet's source address to be correct and use it to affect security settings seems questionable.  Especially if it is based on an assumption that border filters are in place and operational.  What is the genesis/basis for this text?
2013-09-26
10 Brian Haberman Ballot discuss text updated for Brian Haberman
2013-09-26
10 Jari Arkko [Ballot Position Update] New position, Recuse, has been recorded for Jari Arkko
2013-09-26
10 Stewart Bryant
[Ballot comment]
Having read through the text again and reviewed the comments from other members of the IESG, I am of the view that the …
[Ballot comment]
Having read through the text again and reviewed the comments from other members of the IESG, I am of the view that the long term interests of the Internet would be best served by the removal of the routing text from this draft and the definition of the routing components in a working group that will get better scrutiny by routing specialists, i.e. adopting of the routing protocol requirements and definition by a WG within the router area.
2013-09-26
10 Stewart Bryant Ballot comment text updated for Stewart Bryant
2013-09-25
10 Stephen Farrell
[Ballot discuss]

I'll end up as a Yes for this, since I think homenet is
important and potentially a real win. So sorry to pile …
[Ballot discuss]

I'll end up as a Yes for this, since I think homenet is
important and potentially a real win. So sorry to pile
on in the meantime.

(1) general - its hard to have any confidence that all
this zero-conf stuff can ever be secure. Can you tell me
why I should be confident that security won't be
constantly sacrificed at the altar of zeroconf in later
work?

(2) 3.3.4: this says that the default mode internally
should be to share everything. I think that
underestimates the problems that may occur when a user
buys a nice new device which on first boot up and
thereafter periodically scans the internal network and
then sends all that nice marketing information back to
the equipment vendor or application service provider.
I'm not sure what this architecture can do about that
but I do think it needs to be recognised, e.g. there's
just as little reason to trust a new bit of h/w as a new
Andoid or IOS app that a user has installed.

(3) 3.4.5 - I'm not convinced that addressing is the
only privacy issue here, and even if it were I don't
understand why you cannot make some kind of
recommendations about address privacy.  For an example
of another privacy issue if a globally unique name is
chosen, couldn't that be very privacy unfriendly? Why
are there no privacy requirements posed?

(4) 3.7.4: Why is DNSSEC only "desirable"? I think it
would have been better to say that if DNS is used then
DNSSEC MUST NOT be broken by a homenet router or naming
service.

(5) Would it be reasonable to add a requirement that
homenet devices MUST have good random number generation
and that homenet specs MUST make it clear where good
(P)RNGs are needed? There have been many failures in
this respect in recent times so I think it'd be a fine
addition to this document. But, if you tell me the WG
thought about that and decided against then I'll make
this a comment.
2013-09-25
10 Stephen Farrell
[Ballot comment]

- "cloud-based" is used a couple of times. Seems like
marketing language to me and better avoided.

- 3.7.3 - if you do …
[Ballot comment]

- "cloud-based" is used a couple of times. Seems like
marketing language to me and better avoided.

- 3.7.3 - if you do use a UniqueString "based on"
something else, please make those unlinkable if possible
(e.g. via application of a salt and hash function).  Not
sure if that's worth a note. The reason for that is to
not add yet another way in which knowing one value,
allows you to fingerprint someone based on the derived
value.

- 3.7.5 - why a "trust anchor"? Seems like too much or
too little detail there.
2013-09-25
10 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2013-09-25
10 Benoît Claise
[Ballot discuss]
DISCUSS

The numerous comments from the IESG/directorates simply reflect the fact that you worked on an important piece of work. Thanks


- zeroconf, …
[Ballot discuss]
DISCUSS

The numerous comments from the IESG/directorates simply reflect the fact that you worked on an important piece of work. Thanks


- zeroconf, which is mentioned throughout the document. It should be expanded in the "operations and management" section 3.8.2
Also, on that zeroconf topic, I agree with Brian Point 6
  It is not practical to expect home users to configure their networks.
  Thus the assumption of this document is that the homenet is as far as
  possible self-organising and self-configuring, i.e. it should
  function without pro-active management by the residential user.

- Regarding 3.8.2.  Operations and Management, here is Jouni's feedback (part of OPS-DIR)

  JiK: I would like to see here also the other operational considerations
  spread out in the document like: subscribers config names for services,
  SSIDs, WPA2 keys, defining which nodes are "servers" etc..

  Frankly compared to the high quality of the rest of the document, this
  section needs some considerable face lifting. Specifically, homenet
  envisioned by this architecture document can be a nightmare for the
  average Joe, if and when something breaks or malfunctions.

I fully agree with Jouni. When I read ..
  It is not practical to expect home users to configure their networks.
  Thus the assumption of this document is that the homenet is as far as
  possible self-organising and self-configuring, i.e. it should
  function without pro-active management by the residential user.
... I expect a lot more from the "Operations and Management" section

-

  The homenet should be self-organising and configuring as far as
  possible, and thus not be pro-actively managed by the home user.
It seems to me that it conflicts with the notion of border, which will have to be configured , in all non trivial homenet deployments

-

  Also, with the introduction of new 'dotless' top level domains, there
  is also potential for ambiguity between, for example, a local host
  called 'computer' and (if it is registered) a .computer gTLD.  Thus
  qualified names should always be used, whether these are exposed to
  the user or not.

http://www.icann.org/en/news/announcements/announcement-30aug13-en.htm
2013-09-25
10 Benoît Claise
[Ballot comment]
- I agree with other AD's concerns regarding the open source topic.

-
  However, users may be interested in the status of …
[Ballot comment]
- I agree with other AD's concerns regarding the open source topic.

-
  However, users may be interested in the status of their networks and
  devices on the network, in which case simplified monitoring
  mechanisms may be desirable.

Do you expect the management to be done over IPv6? This should be specified. Clearly this is not the case in the industry today.
Maybe add something in section 2.6 IPv6-only operation, under the 3 bullets
  o  Ensure that the manageability information is available via IPv6



-

  [RFC6204] defines basic requirements for customer edge routers
  (CERs).  This document has recently been updated with the definition
  of requirements for specific transition tools on the CER in
  [I-D.ietf-v6ops-6204bis], specifically 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.  Further, the scope of this text
  is the internal homenet, and thus specific features on the WAN side
  of the CER are out of scope for this text.

I don't understand if, in this architecture you expect all CERs to be compliant with RFC 6204 or [I-D.ietf-v6ops-6204bis]? At least partly for the features on the homenet side?
You mentioned "Such detailed specification of CER devices is considered out of scope of this architecture document", but I don't understand what it means. Do you mean "irrelevant": "Such detailed specification of CER devices is considered irrelevant for this architecture document"?
But I guess that the some features, which are required by 6204/6204bis are required.
I read the above paragraph multiple times, and could not get it.

-

  For IPv6 homenets, the network models described in [RFC6204] and its
  successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum,
  be supported.

I searched networks in [I-D.ietf-v6ops-6204bis] . I guess that you mean:

    3.1.  Current IPv4 End-User Network Architecture . . . . . . . .  4
    3.2.  IPv6 End-User Network Architecture . . . . . . . . . . . .  5

Please call that Network Architecture


- Section 3.2.3 Dual-stack topologies

  That said, it is desirable that IPv6
  works better than IPv4 in as many scenarios as possible.

What does "works better" mean?

-
It seems that a big problem in home networks today is with WIFI, actually multiple WIFIs and combination of (powerline, wifi). I'm surprised to see so little about this aspects in the draft.

- I start to see home wifi routers that are forced by the service provider to offer free hot spots for other customers of this ISP (for example: http://www.voo.be/en/internet/wi-free/) Is this considered as a guest network in your draft? Any specific requirements in that area. Or maybe this is outside of the border of the homenet...

- Below is some more feedback from Jouni Korhonen (JiK), part of this OPS-DIR review (I don't think I've seen a reply to this).

2.4.  Unique Local Addresses (ULAs)

  ...
  Note that unlike private IPv4 RFC 1918 space, the use of ULAs does
  not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT
                    ^^^^^^^^^^^^^^^^^^^^

JiK: Might be just me but what exactly is "host-based NAT"? I know what you
are after but is this term defined somewhere? I found at least two
interpretations for it.

3.2.2.  Network topology models

  ...
  For IPv6 homenets, the network models described in [RFC6204] and its
  successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum,
  be supported.
  ...

JiK: I would reword "successor RFC 6204-bis" to just "successor".

  ...
      used for one or more providers, or multiple CERs.  The presence of
      multiple CERs adds additional complexity for multihoming
      scenarios, and protocols like PCP that need to manage connection-
      oriented state mappings.
  ...

JiK: Reading the document so far it is unclear to me how PCP (and without expanding
the acronym, nor giving a reference to it) relates to the number of CERs.

3.2.2.2.  B: Two ISPs, Two CERs, Shared subnet

  ...
  example shows one shared subnet where IPv6 nodes would potentially be
  multihomed and receive multiple IPv6 global addresses, one per ISP.
  ...                            ^^^^^^^^^^^^^^^^^^^^^^

JiK: I take prefix is meant here, not address.

3.2.4.  Multihoming

  ...
  routed to the proper egress to avoid BCP 38 filtering if exiting
  ...

JiK: I would reword "BCP 38 filtering" to "BCP 38 ingress filtering".

JiK: The discussion of multihoming seems to neglect the case where the CER
would actually speak some routing protocol to its upstream provider. I take
that is done purposely but I cannot find any text saying why it has been
neglected. I understand it does not fit the existing model of consumer
subscriptions but in Section 2.6. it is said that "IPv6-only networking will
be deployed first in 'greenfield' homenet scenarios", which would at least to
me imply some more freedom on choices how to deploy a service.

3.3.4.  Homenet realms and borders

  ...
  e.g. for some specific Grid or LLN-based network, and for these to be
  ...                    ^^^^

JiK: a reference or explanation about Grid is missing in the I-D.

3.4.1.  Use of ISP-delegated IPv6 prefixes

  ...
  prefixes longer than /64 (which would break SLAAC), use of NPTv6, or
  ...           

JiK: SLAAC is never expanded.

  Thus a homenet CER should request, for example via DHCP-PD, that it
                                                      ^^^^^^^

JiK: First time occurrence.. not expanded nor reference given.


3.4.2.  Stable internal IP addresses

  ...
  filtering at the border(s) of the homenet, as mandated by RFC 6024
  requirement S-2.                                          ^^^^^^^^
  ...

JiK: Should be RFC 6204.

3.4.3.  Internal prefix delegation

JiK: It seems that DHCP PD is used with and without '-' in other polaces
in the document . Choose one style.

3.5.  Routing functionality

  ...
  Multiple interface PHYs must be accounted for in the homenet routed
  ...                ^^^^

Jik: PHY is used twice in the document. Never expanded or explained. Same
for MoCA..

3.5.  Routing functionality

  ...
  environment, but as a guideline a maximum convergence time at most 30
  seconds should be the target.
  ...

JiK: For my curiosity.. how did we end up to this 30 secs convergence time
again?

  networks.  IPv6 VM solutions may also add additional routing
                  ^^

JiK: Although explained in the terminology & abbreviations I would expand
VM on the first occurrence.

3.6.1.  Addressability vs reachability

  protocol such as UPnP or PCP [RFC6887].  In networks with multiple
                    ^^^^

JiK: No reference given to UPnP. (well in terminology and abbreviations yes
but would add one here too). Maybe expand UPnP on the first occurrence also.

3.6.5.  ULAs as a hint of connection origin

  As noted in Section 3.6, if appropriate filtering is in place on the
  CER(s), as mandated by RFC 6024 requirement S-2, a ULA source address
                          ^^^^^^^^

JiK: Should be RFC 6204

3.7.1.  Discovering services

  ...
  Users will typically perform service discovery through GUI interfaces
  ...
  an appropriate API for the discovery to be performed.
  ...

JiK: Expand GUI and API on the first occurrences.

3.7.3.  Name spaces

  ...
  Unique Locally Qualified Domain Name
  ...

JiK: give the abbreviation as well (for the similar style as in the
rest of the document is using).

  ...
  Also, with the introduction of new 'dotless' top level domains, there
  ...

JiK: A reference to some document?

  ...
  available by name via an Internet name space, and that a 'split view'
  is preferred for certain devices.
  ...

JiK: A reference to a document that describes the 'split view' ?

3.7.4.  The homenet name service

  ...
  to support appropriate name service security methods, including
  DNSSEC.
  ...

JiK: Add a reference to DNSSEC.

3.7.5.  Independent operation

  ...
  Having an independent local trust anchor is desirable, to support
  secure exchanges should external connectivity be unavailable.
  ...

JiK: What is the local trust anchor? Reading so far it is not immediately
clear to me.

3.7.6.  Considerations for LLNs

  ...
  solutions for use by the Constrained Application Protocol (CoAP) in
  ...

JiK: Give a reference to CoAP?

3.7.7.  DNS resolver discovery

  ...
  local FQDN-derived zones should be included.
  ...

JiK: It is not clear to me what local FQDN-derived zones
are supposed to mean.
2013-09-25
10 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2013-09-25
10 Adrian Farrel
[Ballot discuss]
I am glad that this work is being done by the IETF, and I think it is
very important to the future of …
[Ballot discuss]
I am glad that this work is being done by the IETF, and I think it is
very important to the future of the Internet. However I have a number
of comments some of which are at the level of Discusses.

---

Section 3.1.1

  It is desirable to reuse existing protocols where possible, but at
  the same time to avoid consciously precluding the introduction of new
  or emerging protocols.

I am pretty sure this says "Use a protocol."

If you are not precluding a new protocol when an existing one can be
reused, then are you actually going to satisfy your desire?

It is desirable to have cake. At the same time, we should not preclude
eating it.

However, I would also note that the homenet charter has something to say
on this topic, and I don't believe this document should be at variance
with what the charter says.

I think the resolution of this issue is to remove this discussion from
the document. It really has nothing to do with the architecture.
                         
---

Section 3.1.1 and 3.5

I am concerned by the drive towards "available" code and the requirement
(you use "should") for open source implementations. Are we moving from
being a standards body to a political one? While the existence of
running code is a great way to demonstrate that a protocol is stable and
works and has support (I did write 6972), I do not believe that having
available code is part of the IETF philosophy.

Probably a WG has the right to decide that this is a rule they wish to
employ, although maybe it should be the subject of a more overt
consensus call with careful discussion.

Can the chairs assure me that this has been debated properly in the WG?

[BTW, I am assuming that "available" is intended to imply open source or
similar, and not "commercially available".]

I think that the resolution of this issue is to remove this discussion
from this document. it really has nothing to do with the architecture.

---

BCP 38 is an important tool in the ISP's armoury. However, it is a real
cause of loss of function and capability in the home network. RFC 6724
does nothing to ease this because, although it may give advice about
selecting a source address, it doesn't handle the case where a device
wishes to change its source address.

A multi-homed home needs to be flexible and resilient. It also needs to
support mobility within the home as well as from outside the home into
the home. Such resilience and mobility need to be achieved without
service disruption and at the network layer.

SA-based routing is only a sticking plaster since, while it gets the
packets to the right CER based on their SA, it doesn't help when the
SA needs to be changed.

The home should become part of the Internet, not a wart on the side, and
IP packets should be dynamically routable without the need to ask the
sender to change the source address. Otherwise, all the excitement about
end-to-end communication is rather diluted.

This debate could be quite wide and deep, and should surely involve the
routing and operations communities.

I think this issue could be resolved for this document by more clarity
in the document about the required parameters of the homenet (e.g. is BCP                                     
38
required at the ISP-CER boundary?), and less discussion about how
solutions might be formed. The discussion of solutions will, of course,
be needed - just not in this document.

----

And, following from the previous...

I am disappointed by the discussion of routing requirements and
solutions in this document. It would be better if the document was
clearer about the solution model that needs to be applied (section 2.3)
is pretty much clear enough, and if it left all resolution of the
problem out of scope of this document. If routing changes are needed,
perhaps these could be determined within the Routing Area. If
operational changes are acceptable, perhaps the Ops Area could make a
determination. In short, this document is too open to the passing
opinions of how things might be done, and once that has been made into
an RFC it will be really hard to do something different.

This issue (of the document making suggested solutions) may be more
general (for example, the end of 3.3.1, or the end of 3.4.3), I just
feel it more around routing.

I think this issue could be resolved by careful grooming of the text so
that it describes the requirements (if they exist) such as a host must
be able to choose between different addresses and BCP 38 must be assumed
to be in use. But the text should not suggest how routing will achieve
that (or even if it is a routing issue since tunnelling solves it
without any modification to routing :-)

---

When 3.3.3 says...

  Therefore protocols that avoid being 'chatty', do not require
  flooding, and enable isolation of traffic between subnets are
  preferable to those which burn scarce resources.

... it is being too simplistic. Different protocols have different
plusses and minuses. What is best for one network type is not best
for another.

And then 3.5 goes on to say...

  As per prefix delegation, it is assumed that a single routing
  solution is in use in the homenet architecture.  If there is an
  identified need to support multiple solutions, these must be
  interoperable.

...which is internally inconsistent (either there is one solution or
not) and in conflict with the discussion of LLNs within the home.

But I find some disconnect about whether an LLN is part of the homenet
or not. 3.5 says:

  In general, LLN or other networks should be able to attach and
  participate the same way as the main homenet, or alternatively map/be
  gatewayed to the main homenet.  Current home deployments use largely
  different mechanisms in sensor and basic Internet connectivity
  networks.  IPv6 VM solutions may also add additional routing
  requirements.

Noting that 3.7.6 is pretty sure that an LLN can be part of the homenet.


Furthermore: what does "interoperable" mean?!

---

3.5 says some odd things

  It is desirable, but not absolutely
  required, that the routing protocol be able to give a complete view
  of the network, and that it be able to pass around more than just
  routing information.

I should think it highly undesirable that the routing protocol be
able to give a complete view of the network. That is neither something
that is the job of a routing protocol, nor something that is good to do
to low-capacity devices be they routers or hosts.

We can also have a philosophical discussion if you like about whether a
routing protocol should be employed to pass around non-routing
information. Such a use, either by flooding or by more direct means, is
likely to make the routing aspects of the routing protocol slower to
converge and more expensive to run.

This seems to be in conflict with 3.3.3's preference to avoid flooding
and burning of scarce resources.

This issue might be resolved by separating out the requirements/desires
in terms of functions (we want to be able to get information between
nodes in a p2p, p2mp, or broadcast way) from how it is achieved (through
routing).

---

3.8.2 is an ambitious punt. While there is clearly no need for active
configuration management, diagnostics will be required. It is very
naive to assume that the self-configured network will never have a
problem requiring someone (user or engineer) to inspect and rectify
problems.

I think 3.8.2 needs to be promoted beyond something that "this text is
neutral towards".
2013-09-25
10 Adrian Farrel
[Ballot comment]
I am curious to see the discussion of this document still rolling on
the homenet mailing list right up to IESG evaluation, but …
[Ballot comment]
I am curious to see the discussion of this document still rolling on
the homenet mailing list right up to IESG evaluation, but I trust the
responsible AD to make sure that the necessary changes are made to
reflect consensus, and that those changes will be brought back to the
IETF and/or the IESG as applicable.

---

Section 1.1

  o  FQDN: Fully Qualified Domain Name.  A globally unique name space.

  o  LQDN: Locally Qualified Domain Name.  A name space local to the
      homenet.

A name is not a name space.

---

Section 2.4

The use of a 'master' router for the allocation of ULAs is fine until
that router is down. At that point it becomes impossible to add a device
(or renew a lease) in some subset of the home behind another router.

Not sure how big this issue is since if there was only one router it
would need to be up to get a ULA and to route packets. But it seems that
if you have multiple routers it is probably because your network is
large enough to have some regions that are largely self-sufficient.

Would you fall back to a second /48 or would you fail the allocation of
the ULA?

This seems to be particularly relevant considering 3.2.1 para 1

---

Section 3.1

  The principles described in this text should be followed
  when designing homenet solutions.

Not clear (to me) at whom this statement is targeted. At the IETF, the
standards community, the equipment manufactures, the home-owner?

---

Section 3.1.2.

  Where possible, any requirement for changes to hosts and routers
  should be minimised, though solutions which, for example,
  incrementally improve capability with host or router changes may be
  acceptable.

I think this doesn't say anything.
What are the real requirements?
- backward compatible
- not require ejection of equipment from the home?
- migration paths need to be written?
- acceptable if full function not available with old equipment?

---

Section 3.2.1 and 3.2.2.1

"Loop" may not be the best word to describe a topological construct
in which there are redundant paths. Loop tends to be used to describe
what happens when a packet is trapped. Such loops are not good :-)

---

Basic topologies and basic function

Notwithstanding network B(E) and network E(B) in figure 1, I don't find
enough discussion of hosts that are multi-homed to multiple separate
networks within the home.

Additionally, I don't find enough discussion of devices that are
mobile within the home (yes I see 3.5.2). Such devices may be multi-
homed to different networks in the home at the same time, and may
themselves be capable of routing. That makes some pretty bold statements
about topology.

You haven't discussed the case of a host with its own direct connection
to a service provider network. Such a host might likely not have router
function, but it might be capable of participating as a host on one of
the home networks as well as having a direct connection to the provider.

Now, if we combine some of these aspects we can consider:
- a device that enters and leaves the home, and moves around within the
  home
- such a device that is capable of routing packets

---

Does the final paragraph of 3.2.2.3 really belong at the top of 3.2?

---

While there is some discussion of neighbouring homenets and also of
awareness of realms and borders, the document seems to miss the very
likely deployment of home networks that have connectivity to other
shared networks (maybe the network operators should close their ears).
This will result, at least, in a home having a /48 for ULAs within the
home, but also a collection of homes having a /48 (via a master router,
I guess) for traffic between the homes.

It is less likely that traffic from one home will be routed through
another homenet to reach the Internet (because that costs money) but I
can see it happening for a number of reasons, and this might be achieved
as a guest network or with wider address allocation. It is not clear to
me whether, at that point, they have just made one big homenet, or if
there is something more complex going on.

---

Does section 3.4.4 say anything?

It is part of 3.4 so I suppose it is meant to apply to specifically to
lifetimes/timers associated with addresses. Maybe it could be clearer
about what the issues are? Maybe "integrated" is not the right word?

---

Section 3.5

  The routing environment should be self-configuring, as discussed
  previously.  An example of how OSPFv3 can be self-configuring in a
  homenet is described in [I-D.ietf-ospf-ospfv3-autoconfig].
  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.

What is the value of the sentence about an example of how OSPF can be
made self-configuring? Why would you say this an not observe how IS-IS
is able to self-configure? Suggest deleting the solution-specific stuff.

---

There is no discussion in 3.5 of preferring links or path lengths. It is
sort of fundamental if you say routing is needed to say what paradigm
you hope will be employed. Should self-configuration include assigning
metrics according to node/link capabilities?

---

It is unclear to me whether 3.5.2 is a statement about routing (it is in
section 3.5) or about a more general attribute such that the section
should be placed elsewhere.

BTW, why say "(wireless)"? Surely the fact is true with wired subnets as
well, and particularly with a mixture.

---

Somewhere in 3.6 should probably refer back to 3.3.1

---

Section 3.7

  The homenet requires devices to be able to determine and use unique
  names by which they can be accessed on the network.

I suspect you mean that the names are not used by any other device, not
that the device must choose a single name.

See also 3.7.2

---

Section 3.7.1

"GUI interfaces"

Is that GUII? :-)

---

I think 3.7.3 (or 3.7.5?) glosses that each CER and each ISP may
generate a different globally unique name space such that devices in the
homenet have multiple fully qualified names. Not sure it has a
significant consequence.

---

Nothing in 3.8.1 about pushing ECN to the host?
2013-09-25
10 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel
2013-09-25
10 Stewart Bryant
[Ballot discuss]
"The homenet unicast routing protocol should be based on a previously deployed protocol that has been shown to be reliable, robust, to allow …
[Ballot discuss]
"The homenet unicast routing protocol should be based on a previously deployed protocol that has been shown to be reliable, robust, to allow lightweight implementations, and of which open source implementations are available.  "

To require an open standard is entirely within the ethos of the IETF and I would support it, but I am concerned that requiring open source is more of a political statement for which there is no IETF mandate.

I am concerned about this statement and I would like to discuss it with the authors:

"A routing protocol that can make routing decisions based on source and destination addresses is thus desirable, to avoid upstream ISP BCP38 ingress filtering problems."

I agree with and support the need to steer the packet to the correct egress router, but for Figure 2 surely a default g/w mechanism would work, and for figure 3 a simple change to the forwarding code would work. For more complex networks (none of which you show)  surely something less than a full routing protocol would suffice? Indeed I am wondering whether all that is needed is a simple change to the forwarder.

My concern is that we may needlessly trigger the development of a whole new routing protocol unless this requirement is specified with greater clarity.
2013-09-25
10 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant
2013-09-25
10 Barry Leiba
[Ballot comment]
There's been a good discussion that's come out of the AppsDir review:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10404.html
...and I trust the authors to know what's appropriate to …
[Ballot comment]
There's been a good discussion that's come out of the AppsDir review:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10404.html
...and I trust the authors to know what's appropriate to do as a result of that.

In his GenART review:
http://www.ietf.org/mail-archive/web/gen-art/current/msg08984.html
...Elwyn brings up a few minor points that are more than editorial, which I want to highlight:

Section 2.4 begins with a discussion of ULAs "within the scope of a single site," and the fifth paragraph in Section 3.4.2 arguably belongs in 2.4, probably early in the section, rather than down in 3.4.2.

The paragraph in Section 3.7.3 that discusses dotless domains probably needs a little work, at least to (1) be more fluffy about whether dotless domains are really upon us, and (2) say a word or two about what a dotless domain is, for readers who haven't been following the situation.

It's probably true that a reference for WPA2 would be good, but I've checked around and can't find something suitable.  There's some vague stuff on the WiFi Alliance pages:
http://www.wi-fi.org/knowledge-center/glossary/wpa2%E2%84%A2
...but otherwise, it's buried in the 802.11 specs.  It's probably not worth spending a lot of time looking for a good reference, but if one turns up that's fine.

And I'm sure the authors will address the editorial comments appropriately.
2013-09-25
10 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from No Record
2013-09-24
10 Pete Resnick
[Ballot comment]
A bunch of comments and a few questions follow. None of these rise to the level of requiring a DISCUSSion; t is, after …
[Ballot comment]
A bunch of comments and a few questions follow. None of these rise to the level of requiring a DISCUSSion; t is, after all, just Informational. However, please take these into consideration, and I'd appreciate answers to the queries:

1.1: You define LLN here. But throughout the document, sometimes you use LLN to mean "home automation device network" (see 2.1 below), where the network might not necessarily be low-power or lossy, and sometimes you truly mean LLN. I suggest you look through the document and make sure you identify which are which. (For example, in 2.4, I don't think you're really talking about LLNs; you're talking about home automation networks.)

There's no need for a definition for UPnP here. It is only cited once (in 3.6.1), and even there it's simply an example. (I'm not at all clear why this document, even in 3.6.1, has to advertise for UPnP, a non-IETF technology. I'd rather the example simply be removed from 3.6.1 and stick to PCP.)

You refer to "guest" networks throughout the document, but don't define it here. I find the concept a bit odd myself; I know many corporations have a concept of a guest network, but it's rare for home networks to have such a thing. Can you explain why this is a useful construct in a home network? If it turns out to be, it's probably worth defining here.

2.1. Instead of "building control", please use the term "home automation" here. "Home automation" encompasses more than "building control" for homes, and "building control" includes things that are not part of home networking. By the way: It is a home automation (or building control) "network" or "subnet", not a home automation "extension", isn't it?

The use of the word "extension" here and elsewhere (as in "corporate extension" or "extension network") is nothing I've heard used before and it is undefined in this document. In the context of a corporate network, don't you simply mean a "corporate virtual (private?) network"? Or are you really talking about the possibility of corporations providing a dedicated network in a home premise that might be interconnected with the user's ISP and home automation networks?

2.4: I think you're simply talking about home automation devices here, not LLNs.

2.5: (Tilting at a windmill) Zeroconf and simple naming are really only useful for ULAs. To avoid the need for manual configuration of GUAs, the ability to configure DDNS (i.e., giving the user the ability to type in a domain name and have it update the AAAA record with the auto-configured address) must be provided. (See also 3.7.3 below.)

3.1.2: This section seems a little thin, and frankly I can't figure out what it really means: Certainly few home CERs nowadays allow you to plug them into other home CERs from different providers and have anything useful happen, so saying that changes to routers needs to be "minimized" seems unrealistic. Sure, you won't be making wholesale changes to IPv6, but this section seems to be saying something different. What do you mean by "minimized"?

3.2.2.1: What's the interest of Link F? The Interior Router looks like it's linked to the CER through Network E already. Does having F separate mean anything in particular?

You mention that B and E are "bridged". Is that any different than in figure 2, where the two CERs are bridged across a single network?

3.2.3:

  ...it is important not
  to introduce new IPv6 capabilities that would cause a failure if used
  alongside IPv4+NAT...

Are there examples of what you're thinking of here?

3.3:

  The home network architecture should be naturally self-organising and
  self-configuring under different circumstances relating to the
  connectivity status to the Internet, number of devices, and physical
  topology.  At the same time, it should be possible for advanced users
  to manually adjust (override) the current configuration.

The architecture is not "self-configuring" or configurable. I think you mean that homenet (routing?) *devices* need to be self-configuring and that advanced uses be able to override their configurations. If not, please explain.

3.4.1:

  ...it is recommended that the receiving router instead enters an error
  state and issues appropriate warnings.
 
That sure sounds like a recommendation designed to be ignored. You are either saying that manufacturers should make equipment that will fail to function in certain circumstances, or you're encouraging the creation of a "HOMENET certified" brand. Neither one seems like a good thing.

The last 5 paragraphs of this section strike me as a bit odd: The norm for homenets (from the earlier discussion) seems to be that it must handle users plugging together of devices from different providers and removal of those devices from the network. It seems like handling *that* gracefully will make all issues of renumbering/prefix changes/new ISP/etc. simply degenerate cases of the bigger issue of dealing with networks being plugged together and unplugged randomly.

3.5.2: This seems a bit hand-wavy. Perhaps that's the best that can be done in this document.

3.7.3: This section is a bit thin on how global name spaces will work. If homenets are going to have global name spaces, the authoritative server you mention in the first paragraph is going to almost certainly be a DDNS server, and changes are going to be needed on the hosts to support this. We certainly *do* want printers and other services to keep their names up to date with different GUAs coming and going. I think a discussion of this would be useful.
2013-09-24
10 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-09-12
10 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Sam Weiler.
2013-09-12
10 Barry Leiba [Ballot comment]
Switching my ballot back to "no record", to remind me to cover the GenART review for Jari.
2013-09-12
10 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Record from No Objection
2013-09-11
10 Pete Resnick Telechat date has been changed to 2013-09-26 from 2013-09-12
2013-09-11
10 Pete Resnick State changed to IESG Evaluation - Defer from IESG Evaluation
2013-09-11
10 Richard Barnes
[Ballot discuss]
This is a "DISCUSS-discuss", mainly a question I would like to have an answer to because service discovery is an important feature of …
[Ballot discuss]
This is a "DISCUSS-discuss", mainly a question I would like to have an answer to because service discovery is an important feature of homenets for applications.

One challenge that we've run into, e.g., in GEOPRIV, ECRIT, and ALTO, is that it is sometimes necessary (or at least helpful) for the homenet DHCP server to pass along information that it gets from its upstream DHCP server.  For example, DNS resolver addresses, or the options for LoST and HELD/ALTO [RFC5223][RFC5986] -- mostly service discovery sorts of things. 

Would this document be an appropriate place to discuss this sort of behavior?  It would be good to get the above recommendation in writing somewhere, but it's not immediately clear what the recommendation would be for homenets -- do you pass on all options, some subset?  I guess you could make recommendations in individual option definitions, but that seems laborious and error-prone.
2013-09-11
10 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2013-09-11
10 Elwyn Davies Request for Last Call review by GENART Completed: Ready. Reviewer: Elwyn Davies.
2013-09-11
10 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-09-11
10 Brian Haberman
[Ballot discuss]
There are several items within this document that I think need discussing...

1. Even though this document is labeled an architecture, I am …
[Ballot discuss]
There are several items within this document that I think need discussing...

1. Even though this document is labeled an architecture, I am concerned when I see seemingly random requirements documented in various parts of the document.  Are there a concrete set of requirements that can be documented in a standalone section (ideally with some justifications)?

2. Section 1.1 (and other parts of the draft) talks about borders & realms and their impact on forwarding unicast and multicast traffic.  I am concerned that these two terms need to be scoped properly to bring them in line with the RFC 4007, specifically the definition of scopes & zones (section 5 of 4007).  Of note, this draft says those types of boundaries need to be automagically created, yet 4007 specifically states that boundaries between zones must be configured by an administrator.

3. The introduction states that this draft is focused on the internals of the homenet "and thus specific features on the WAN side of the CER are out of scope".  However, section 2.6 discusses transition scenarios that are already defined in RFC 6204 (6204bis).  What is the purpose of having transition text in *this* draft?

4. While I fully support open-source software and recognize its benefit to the IETF, I do not find it appropriate to espouse (borderline require) its use in an architecture document.  The text in section 3 and 3.5 is rather inappropriate in this context.

5. Does the discussion of walled gardens in section 3.2.4 (next-to-last paragraph) need an explicit reference to section 4.2.1 of RFC 3002?  The guidance provided in 3002 is very explicit and I would not want homenet to go against that consensus.

6. This is more of a general concern, but I am seeing a lot of zero-config magic being wished for in this document.  While it is a noble goal, I don't see how it dovetails with other aspects such as home vs. guest subnets, device enrollments vs. unmodified hosts, and the need for policies in some scenarios.  There are some aspects of a complex network that require some level of human intervention to get right.  How would a router know that an attached subnet should be treated as the guest subnet?  How does a router know that a particular upstream link is to a corporate VPN?

7. I think it is inappropriate to discuss IPv6 address allocation policies in section 3.4.1.  The fourth paragraph in that section is on dangerous grounds trying to mandate what an ISP allocates to a customer.

8. Section 3.6.5 seems rather odd to me.  Trusting a packet's source address to be correct and use it to affect security settings seems questionable.  Especially if it is based on an assumption that border filters are in place and operational.  What is the genesis/basis for this text?
2013-09-11
10 Brian Haberman
[Ballot comment]
1.  I will channel some of my I* colleagues and say that section 2.2 should probably discuss privacy issues that may arise.

2. …
[Ballot comment]
1.  I will channel some of my I* colleagues and say that section 2.2 should probably discuss privacy issues that may arise.

2. I think it would be useful if the discussion of ULAs in section 2.4 mentioned that the address selection policy in IPv6, by default, prefers using ULA source addresses when the destination is a ULA.

3. Section 2.5 uses the term "zeroconf" without any previous definition.

4. Section 3.4.4 makes no sense to me.  Other sections have a copious amount of detail and this one just says "timers have different lifetimes, figure it out".
2013-09-11
10 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2013-09-11
10 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-09-10
10 Joel Jaeggli
[Ballot discuss]
The secdir review revists the question of default allow/deny policy and the documents non-position, position, on that. I am actually aware of the …
[Ballot discuss]
The secdir review revists the question of default allow/deny policy and the documents non-position, position, on that. I am actually aware of the discussion in the working group and the nuance of the respective arguments having been a contributor to the discussion.

I personally would rather see:

The document declare a lack of consensus with respect to which is more appropriate.

Describe the policy as situationaly appropriate (e.g. there are consensus cases where one model is appropriate or the other model is appropriate).

this is not strongly held but it's worth discussing.
2013-09-10
10 Joel Jaeggli [Ballot Position Update] New position, Discuss, has been recorded for Joel Jaeggli
2013-09-07
10 Spencer Dawkins
[Ballot comment]
This is one big chunk of good work - thanks to the working group for putting it together.

I have some comments, that …
[Ballot comment]
This is one big chunk of good work - thanks to the working group for putting it together.

I have some comments, that I'd appreciate the authors looking at, along with any other comments they consider.

About half of my comments involve name services, and telling a TSV AD to get a clue about DNS might be a reasonable way to address those comments :-)

There are three places in the document where the word "cascaded" to describe NATs. I'm pretty sure I know what you mean, but I didn't see a definition or reference. Could one or both be provided?

In 3.3.4.  Homenet realms and borders

  It is expected that a realm would span at least an entire subnet, and
  thus the borders lie at routers which receive delegated prefixes
  within the homenet.  It is also desirable, for a richer security
                        ^^^^^^^^^^^^^^^^^^^^
  model, that hosts are able to make communication decisions based on
          ^^^^^^^^^^^^^^
  available realm and associated prefix information in the same way
  that routers at realm borders can.

and in 3.6.4.  Device capabilities

  In terms of the devices, homenet hosts should implement their own
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  security policies in accordance to their computing capabilities.
  They should have the means to request transparent communications to
  be able to be initiated to them through security filters in the
  homenet, either for all ports or for specific services.  Users should
  have simple methods to associate devices to services that they wish
  to operate transparently through (CER) borders.

I wonder if the places where you have expectations about hosts could be gathered into a single higher-level section ("considerations for hosts in homenets", or something). In the current version of the draft, they're buried in descriptions about homenets, and I wonder whether the people who need to see them will actually see them. and you don't have very many of them. I wouldn't expect much text to change (the expectations are clearly stated). But even if that higher-level section just pointed to the sections where the material is now ("hosts should do whatever, as described in Section 3.6.4"), I'd expect more people who can influence host implementations to notice.

In 3.7.2.  Assigning names to devices

  Given the large number of devices that may be networked in the
  future, devices should have a means to generate their own unique
  names within a homenet, and to detect clashes should they arise, e.g.
  where a second device of the same type/vendor as an existing device
  with the same default name is deployed, or where two running network
  elements with such devices are suddenly joined.  It is expected that
                                  ^^^^^^^^^^^^^^^
  a device should have a fixed name while within the scope of the
  homenet.

I find myself wondering if anything else might need to take action where two running network elements are suddenly joined - this is the only place in the document where I saw the word "join", although I could easily have missed other mentions using different wording.

In 3.7.3.  Name spaces

  Also, with the introduction of new 'dotless' top level domains, there
  is also potential for ambiguity between, for example, a local host
  called 'computer' and (if it is registered) a .computer gTLD.  Thus
  qualified names should always be used, whether these are exposed to
  the user or not.

Is there a useful reference that could be provided for "dotless"? If there's not a better one, perhaps http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/?

Also in 3.7.3.  Name spaces

  It may be the case that not all devices in the homenet are made
  available by name via an Internet name space, and that a 'split view'
  is preferred for certain devices.

Is there a useful reference that could be provided for "split view" ("split horizon")? I didn't see one during a quick poking-around, but if there's not, perhaps a short definition would be helpful?

In 3.7.4.  The homenet name service

  To protect against attacks such as cache poisoning, it is desirable
  to support appropriate name service security methods, including
  DNSSEC.

Two things here. I'm curious about a useful reference for "cache poisoning", but even more - you were allowing for the preference of "split view" in 3.7.3, and in 3.7.4, you're saying support for DNSSEC is desirable. How well does that work? http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04#section-4.1 (expired) described several ways to do "split view DNSSEC", but each had disadvantages. Is there a requirement for work on DNS in support of what you think homenets will need?

And if you can come up with a reference that's not expired, that would be great ...
2013-09-07
10 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-09-05
10 Ted Lemon Ballot has been issued
2013-09-05
10 Ted Lemon [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon
2013-09-05
10 Ted Lemon Created "Approve" ballot
2013-08-17
10 Ted Lemon State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-08-17
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-08-08
10 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2013-08-08
10 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2013-08-08
10 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-08-08
10 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-homenet-arch-10, which is currently in
Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-homenet-arch-10, which is currently in
Last Call, and has the following comments:

We understand that, upon approval of this document, there are no
IANA Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.
2013-08-08
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sam Weiler
2013-08-08
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sam Weiler
2013-08-03
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2013-08-03
10 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Home Networking Architecture for IPv6) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Home Networking Architecture for IPv6) to Informational RFC


The IESG has received a request from the Home Networking WG (homenet) to
consider the following document:
- 'Home Networking Architecture for IPv6'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-homenet-arch/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-homenet-arch/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-08-03
10 Cindy Morgan State changed to In Last Call from Last Call Requested
2013-08-03
10 Ted Lemon Last call was requested
2013-08-03
10 Ted Lemon State changed to Last Call Requested from Publication Requested
2013-08-03
10 Ted Lemon Ballot writeup was changed
2013-08-03
10 Ted Lemon Ballot writeup was generated
2013-08-03
10 Ted Lemon Ballot approval text was generated
2013-08-03
10 Ted Lemon Last call announcement was generated
2013-08-02
10 Ted Lemon Placed on agenda for telechat - 2013-09-12
2013-08-02
10 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Informational RFC

Q: Why is this the …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Informational RFC

Q: Why is this the proper type of RFC?

A: This is a non-normative architectural document providing design guidelines, not a protocol specification.

Q: Is this type of RFC indicated in the title page header?

A: Yes.

Q: (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.
 
A:  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.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

A: The general architectural principles appear to be well supported and understood.  Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

A: There have been two formal WG last calls, with a number of reviewers.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

A: Ray Bellis, Ted Lemon

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A: Document has been reviewed by a number of individuals, the WG Area Director, 100s of emails exchanged, and 10 versions over 2.5 years.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

A: No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

A: Homenet is widely attended and has a large email subscriber base, but, no, we have not reached out for a community-specific review.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

A: The shepherd has no specific concerns.  The responsible area director has followed this group closely.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A: Written confirmation has been received from all authors.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

A: There have been no disclosures filed against this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

A: The WG chairs believe the consensus on what is in this document is not unanimous, but is solid. Areas of concern have been discussed at length, wordsmithed, and general agreement achieved.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

A: No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

A: Yes - part of the tool submission

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

A: N/A

(13) Have all references within this document been identified as either normative or informative?

A: Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

A: No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No.

(16) Will publication of this document change the status of any existing RFCs?

A: No.

Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

A: N/A

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A: N/A

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A: N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

A: N/A
2013-08-02
10 Cindy Morgan IESG process started in state Publication Requested
2013-08-02
10 (System) Earlier history may be found in the Comment Log for draft-chown-homenet-arch
2013-08-02
10 Ted Lemon Shepherding AD changed to Ted Lemon
2013-08-02
10 Ray Bellis IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2013-08-02
10 Ray Bellis Changed document writeup
2013-08-02
10 Ray Bellis Changed document writeup
2013-08-01
10 Ray Bellis Document shepherd changed to Ray Bellis
2013-08-01
10 Ray Bellis Changed consensus to Yes from Yes
2013-08-01
10 Ted Lemon Changed consensus to Yes from Unknown
2013-08-01
10 Ray Bellis Intended Status changed to Informational from None
2013-08-01
10 Tim Chown New version available: draft-ietf-homenet-arch-10.txt
2013-07-28
09 Ray Bellis IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2013-07-15
09 Tim Chown New version available: draft-ietf-homenet-arch-09.txt
2013-06-03
08 Ray Bellis IETF WG state changed to In WG Last Call from WG Document
2013-06-03
08 Ray Bellis Annotation tag Revised I-D Needed - Issue raised by AD cleared.
2013-06-03
08 Ray Bellis IETF WG state changed to WG Document from In WG Last Call
2013-06-03
08 Ray Bellis Annotation tag Revised I-D Needed - Issue raised by AD set.
2013-05-21
08 Tim Chown New version available: draft-ietf-homenet-arch-08.txt
2013-02-12
07 Ray Bellis IETF state changed to In WG Last Call from WG Document
2013-02-10
07 Tim Chown New version available: draft-ietf-homenet-arch-07.txt
2012-10-22
06 Tim Chown New version available: draft-ietf-homenet-arch-06.txt
2012-10-19
05 Tim Chown New version available: draft-ietf-homenet-arch-05.txt
2012-07-16
04 Tim Chown New version available: draft-ietf-homenet-arch-04.txt
2012-06-29
03 Tim Chown New version available: draft-ietf-homenet-arch-03.txt
2012-03-12
02 Tim Chown New version available: draft-ietf-homenet-arch-02.txt
2012-01-30
01 (System) New version available: draft-ietf-homenet-arch-01.txt
2011-12-10
00 (System) New version available: draft-ietf-homenet-arch-00.txt