[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-hain-templin-ipv6-limitedrange-02.txt

Hello Ralph,

Thanks for the comments; please see my responses below:


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
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6