Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

Sorry for the late comment.

Major comment:

Section 4 says at the end of the first paragraph "simple and easy".
I think we should replace this with "secure and robust" or
add all the motherhood and apple pie.

My point is that by only including two motherhood words and not others
an attempt to use this document to evaluate potential solutions might be
slanted towards "easy" instead of "good".
I suspect the WG needs to discuss this aspect of the spec.


Section 3 makes a, in my opinion artificial, distinction between "p2p"
and "server" and then goes on to conclude that server is out of scope
due to the difficulty with DNS updates. This distinction seems a bit
artificial since the p2p aspect (that the same nodes both initiate and
respond to traffic) doesn't preclude that DNS is used.
So I'd think the document should capture that DNS updates might have issues
when the network is unmanaged that is independent of the types of applications
in section 3.

Minor things:
Per the rfc-editor the abstract and introduction should not be identical.

Section 2:
I'm assuming (but the document isn't clear) that if somebody figures
out how to autoconfigure a set of routers ("zerouter") that a network
with multiple links would be in scope.
Or is the intent that such networks always be out of scope?
It would be good to make this clear.

Section 3.2:
Is outbound SIP calls an example of a client application?
The reason I think it makes sense to make this explicit is because
the current examples are those that trivially work across a NAT box
and if this is the definition of "client application" it would make
sense to make it clear, and if the definiting is something different
(an entity that initiates communication) it would make sense
to make that clear.

Section 4.1 says:
   The security of local applications is enhanced if these applications
   can be effectively isolated from the global Internet.
Seems orthogonal to this document and a distraction.

Section 5.1.2 says "have to involve tunneling over UDP"
but in general using PPP over TCP works over NAT as well.
If you are trying to capture some specific requirement that excludes
PPP/TCP that needs to be explicit (and I suspect some folks will disagree
with such a requirement).

Section 5.2.3 talks about
   There must be a way to resolve the name of local hosts to their IPv4
   or IPv6 addresses.
Why isn't this a requirement in section 5.1.3 as well?

Section 6 says:
   -	the guarantee that local applications are only used locally,

I fail to see what this has to do with the coexistence between IPv4 and IPv6.
*If* there is such a requirement wouldn't that requirement exist today
in IPv4 and wouldn't it exist in IPv6 even after IPv4 goes away?
If this is the case I don't think the requirement belongs in this document
but in a document for "requirements on home networks" or something like
that.

  Erik