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

Re: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt



On Tue, Feb 10, 2004 at 16:06:11 -0500, Internet-Drafts@ietf.org wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-01.txt

section 3.1:

**Note To V6ops WG: Would a network topology map be useful here?

I don't think this is necessary in either one of the three scenarios.

What would be useful is to better define "parallel" in scenario 1.
E.g., what is the difference with "re-structuring" in scenario 3?
Does "parallel" mean different links and routers or does it mean
dual-stack (or both)?

section 3.2:
I think the term "address ownership" should be avoided.

section 3.3:
Is "Network A" an example of scenario 1, "Network B" of scenario 2
and "Network C" of scenario 3? If so, this could be made more clearly.

section 4.3:
**Note to V6ops WG: Should we discuss porting of applications too in
the legacy section?

I don't think so. Maybe just a reference to:
draft-shin-v6ops-application-transition-02.txt

section 5.1:
**Note to V6ops WG: Should we get into other DNS issues?

The sentence is quite terse, but I think it includes all issues.

section 5.2:
**Note to V6ops WG: Above is example of additional text we could add
  to each component we list here.  Are there other Routing issues?

The ISP draft has some nice text about IS-IS and OSPF with regard
to one or two processes. But maybe that's something for the analysis
document.

section 5.3:
**Note to V6ops WG: Should we get into other autoconfiguration
  issues?

IPv6 statefull autoconfiguration does not give all information
(e.g. DNS, NTP, etc servers). Maybe add what things should/could
be autoconfigured. But maybe this is also something for the
analysis draft.

In v4 part of a /24 is sometimes used in ACLs. E.g., the upper
/28 of a /24 is used for BOFHs by giving that /28 access to
services. With autoconf you cannot do that.

section 5.4:
**Note to V6ops WG: Should we get into other security issues?
The document describes the main requirements. More details could
go in the analysis document.

section 5.5:
**Note to V6ops WG: Should we get into other application issues?
Some applications cannot be ported (e.g., no source code).

section 5.6:
**Note to V6ops WG: Should we get into other Management issues?
People need to be trained.

section 5.7
**Note to V6ops WG: Should we get into other Address Planning issues?

Maybe add that IPv6 has /48 and /64 defaults. Especially the /64 is
quite different from v4, where one link can have a /24 and another
a /28.

**Note to V6ops WG: What other components are we missing?
I think you have quite some items already. I think the focus should
go now to the analysis draft.

	rvdp