Last Call Review of draft-ietf-homenet-arch-10
review-ietf-homenet-arch-10-genart-lc-davies-2013-09-07-00

Request Review of draft-ietf-homenet-arch
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-08-17
Requested 2013-08-08
Draft last updated 2013-09-07
Completed reviews Genart Last Call review of -10 by Elwyn Davies (diff)
Secdir Last Call review of -10 by Samuel Weiler (diff)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-homenet-arch-10-genart-lc-davies-2013-09-07
Reviewed rev. 10 (document currently at 17)
Review result Ready
Review completed: 2013-09-07

Review
review-ietf-homenet-arch-10-genart-lc-davies-2013-09-07

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< 

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-homenet-arch-10.txt
Reviewer: Elwyn Davies
Review Date: 6 September 2013
IETF LC End Date:
IESG Telechat date: 12 September 2013

Summary:
Apologies for missing the last call review of this document.  I was up a
volcano....
Essentially ready.  A few very minor points and nits.  Generally an
excellent analysis.. but it shows there is a long way to go to get a
zero config IPv6 homenet!

Major issues:

Minor issues:
s2.4:  Should this section mention that the border router at the
connection(s) to the homenet's ISP(s) SHOULD be set up to filter packets
with ULA source/destination addresses? (diiscussed later in para 5 of
s3.4.2 - a forward ref would help).

s3.7.3, last para:  Should this mention mail services?  As I have
discovered, failing to have a reverse DNS entry for a mail source can
lead to the mail being rejected.  There might be other
protocols/applications that need reverse DNS also.

s3.3.4, last para:  May not be possible to override policies defined by
ISP at external border.

s3.7.3, para 7: dotless domains - I'm not sure exactly whether these
will really be coming?  not quite reality yet - still subject to
discussion/challenge?  In any case probably need to define 'dotless
domains'.

Nits/editorial comments:
General: s/i.e./i.e.,/g, s/e.g./e.g.,/g

s1, p5:
OLD:
   as well as a better
   result than if the IETF had not given this specific guidance.

This sounds a little patronizing.

Perhaps something along the lines of 
NEW:
   as well as aiming at a more consistent solution that addresses 
   as many of the identified requirements as possible.

s1.1: Does WPA2 need a reference?

s2.4, p2:
> Depending upon circumstances beyond the scope of homenet,....
This sounds like a reference to the homenet working group which is
probably not what was meant.  Maybe something like:
   Depending on circumstances beyond the control of the owner of the
homenet,...

s3.3.2, p2:  s/subdivide itself to/subdivide itself into/

s3.3.3 Can you give examples of relevant protocols?

s3.3.4: Grid network?  Not sure what is meant here.

s3.4.1, p4: Expand DHCP-PD and provide ref.  Also make consistent with
s3.4.3, last para.

s3.5, para 3:  Uses PHY (twice) - needs expanding/explaining or use
'physical interface' as in previous sections.

s3.5, last para: s/participate the same way/participate in the same way/

s3.6: s/direct towards them./directed towards them./

s3.7.4, last para: Expand DNSSEC and give ref.

s3.7.6: CoAP needs a ref.

s3.7.8: Should devices roaming *to* the homenet be discussed?

s3.8.1: Link QoS to Quality of Service explicitly.

s3.8.1, para 2: s/drowning/overloading/ (drowning is slang).