Thanks for the comments; please see my responses below:
Fred [EMAIL PROTECTED]
Ralph Droms wrote:
Here are my comments on draft-hain-templin-ipv6-limitedrange-02.txt...
Global organization - as I read the doc (others' reactions may differ), I
feel like I'm reading a document that is based on some assumptions about the
solution before describing the problem. In particular, the first sentence
in the second paragraph of the Introduction:
There is a perceived need for an addressing scheme that supports local communications within sites.
seems to me to conclude, without explicit support for the conclusion, that
something like site-local addresses is required. Even the title, "Goals for
an Addressing Scheme to Support Local Communications within Sites" suggests
the outcome. I suggest renaming the doc to "Goals for Local Communication
within Sites".
As I also responded to Brian Haberman, a title change seems appropriate and your suggestion looks good.
Any other suggestions for a new title?
It turns out that you do have support for the "perceived need" in section 4.
So my suggestion would be to swap sections 3 and 4, and add a sentence in
the introduction:
There is a perceived need for an addressing scheme that supports local communications within sites. The next section gives several scenarios in which local communications within a site are required.
Then, the goals can be justified by reference to the scenarios.
The section-swap sounds like a very reasonable suggestion for the next draft version.
Comments about scenarios:
4.2 Why would an organization ever have to expose the internal networks being deployed and what office is coordinating the effort?
4.3 Is this test network connected to the Internet?
I believe these are best for Tony to answer.
4.4 I think this scenario would be clearer if it were labelled "Static
Configuration with Addresses" or some such. The problem is really static
configuration of an address rather than caching an address learned through
some other process.
Agree with the comment as a reasonable suggestion for the next draft version.
4.6 What about a completely disconnected ad-hoc network (not necessarily mobile)? I'm thinking of 5 guys in a bar using an ad hoc network with no Internet connection...
This scenario seems to be covered already in section 4.6.1, but please let us know if you think text changes are needed.
4.8 I'm afraid I couldn't understand this scenario at all. When the two sites connect, do they essentially merge into a single, multi-homed site?
I believe the answer to this is yes, and I believe Brian Haberman also expressed concerns about such scenarios since they touch on site multi-homing. (My answer to Brian is that we are not trying to re-create RFC 3582 in this document.) What you would suggest in terms of this block of text?
Is the "local traffic" between hosts within the merged A/B site?
Essentially, yes. Again, the disposition of this block of text probably warrants further discussion.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
