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

From: "Bound, Jim" <[email-masked]>
Date: Wed, 11 Feb 2004 11:38:57 -0500

just a question?  these notes were in the previous draft I am confused.
just checking.
Questions still valid.  
/jim

> -----Original Message-----
> From: Ronald van der Pol [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2004 10:36 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-v6ops-ent-scenarios-01.txt
> 
> 
> On Tue, Feb 10, 2004 at 16:06:11 -0500, 
> [email-masked] 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
>

---

From: Ronald van der Pol <[email-masked]>
Date: Wed, 11 Feb 2004 23:45:05 +0100

> just a question?  these notes were in the previous draft I am confused.

Very interesting. I don't know what happened there. I got an old version,
but I am quite sure I looked at the -01 version. Anyway, the URL now
points to a version without ***Notes. I will read it tomorrow and comment
on it. Sorry for the confusion.

	rvdp

---

From: Ronald van der Pol <[email-masked]>
Date: Thu, 12 Feb 2004 14:38:53 +0100

On Wed, Feb 11, 2004 at 23:45:05 +0100, Ronald van der Pol wrote:

> I will read it tomorrow and comment

General:

I find it hard to comment in detail. Basically, the document is an
extensive (and good) list of all the issues that must be handled
when introducing IPv6 in an enterprise. However, many items are not
"the business of the IETF". There are also few requirements written
down. Much depends on how the analysis document handles all the
issues. I think the focus should go now to the analysis.

section 3.2:

s/IPv6 address ownership/IPv6 address assignment/

In the 'Network Infrastructure Component 3" is says:
 - Other services (e.g. NTP, etc.........)
Those ..... look like something to be filled in. Please remove in
final version.

section 3.3:
_maybe_
s/Example Network A:/Example Network A (base scenario 1):/
etc.

sections 4.1 to 4.3 seem to be analysis instead of requirements.
I would like to see a preference for dual-stack and v4-in-v6
tunnels instead of translation, but this is something for the
analysis document. Maybe sections 4.1 to 4.3 could mention
the cases: node is v4-only, dual stack or v6-only and network
is v4-only, dual stack or v6-only?

section 5.8
Has also quite some analysis already. An interesting point would
be: is there a requirement for v4-v6 multicast interoperability?
If so, that could be a recommendation to the IETF.

I miss thing like: renumbering, stable addresses and things like
that. I thought ipv6 is working on non-routable unique addresses
because of the strong demand from enterprises. Maybe a section
about this could be added. (yes, I know; easier said than done :-)

	rvdp