[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Some Enterprise Scenarios comments
Hi Pekka,
We will fix all edits below. Thank you for this extensive review of our
spec.
All your input below is valid.
Thank You,
/jim
>
>
> Terminology
>
> ==> several important wordsmithing fixes in editorial section, below.
>
> Critical issues for each:
>
> PMTUD : Support for discovery vs. traditional
> ICMP aversion
>
> ==> Is PMTUD really a critical approach? Without
> elaboration, it may be
> that some other word might be more appropriate, or this should be
> considered a bit..
The operational issue the user has to consider for IPv6 packets in their
network is they are now only fragmented e2e, if at all, and this can
affect an enterprise like a discrete engineering operation that sends
MBs of data modeling across the network or a financial institution bulk
wire transfer updates, etc etc. PMTUD is important to be used. I think
PMTUD is the correct word and later needs more discussion in the follow
on text. What other word would be better, to point out this in a
listing of bullets?
>
> Trust system between host & network management teams:
>
> Dual-stack vs. IPv6-only
> IPv6-only is a restricted capability subset
> Routing
> Architectural concept of tunneling over foo vs. native service
>
> ==> "Trust system ..." ??! I've no idea how these relate to
> trust, so more
> elaboration or rewording is definitely needed!
Agreed. WHen I keyed this in as editor I knew someone would ding us on
this one for sure. The idea is to get some crisp bullets of where the
core trust beliefs can be shattered in the minds of the users defining
how to adopt IPv6. Some of the ones I hear, as a note, are fallacy and
not reality, and some are completely missing. But yes this needs major
wordsmithing.
>
> Scenario #6
>
> A new Enterprise providing location based services for over a wide
> geography enables mobile devices for their Account Teams to access
> network data and services. Set D.
>
> ==> compared to other scenarios, this strikes me as being
> perhaps a bit
> too specific ("account teams", etc.)?
We can fix that yes.
>
>
> Editorial:
> ----------
>
> V6ops Working Group Enterprise Network Scenarios Design Team
>
> INTERNET-DRAFT: draft-ietf-v6ops-entnet-scenarios-00.txt
> OBSOLETES : draft-pouffary-v6ops-ent-v6net-03.txt
>
> Yanick
> Pouffary (Chair)
> Jim Bound (Editor)
> Enterprise Networks Scenarios
> Design Team
> See
> Acknowledgements Section
>
>
> February 2003
>
> ==> the header is quite unconventional: I'd just make it like:
>
> V6ops Working Group Yanick
> Pouffary (Chair)
> Internet Draft Jim
> Bound (Editor)
> Expiration Date: Aug 2003 Enterprise Networks Scenarios
> Design Team
I will look at this as editor. I followed templates/current-wisdom the
IETF points me to as a note though.
>
>
> February 2003
>
> 1. Introduction
>
> IPv6 will be deployed in Enterprise networks. This scenario has
> requirements for the adoption of IPv6. This document will
> focus upon
> and define: a set of technology scenarios that shall exist for the
> enterprise network, the set of transition variables, transition
> methods, and tools required by different scenarios. The document
> using these definitions will define the points of transition for an
> Enterprise network.
>
> ==> same issues as with abstract
We hear you.
>
> The audience for this document is the enterprise network team
>
> ==> if you can find, I'd personally prefer another word to "audience".
We will review ok.
>
> accomplishing the business goal, IPv6 provides strong
> motivations to
> move.
>
>
> ==> reword or expand "to move" (for a change?)
We will review ok.
>
> Enterprise Network - An Enterprise Network is a network
> that has multiple links, a router
> conection to a Provider,
> and is activel
> managed by a network
> operations entity.
>
> ==> formatting: must not exceed 72 chars (also elsewhere in
> the document).
Hmmmm. NROFF did it correct it got munged by peoples mailers on the
team. Will fix.
>
> ==> s/conection/connection/
Thanks.
>
> Provider - A Provider is an entity
> that provides
> services and
> connectivity to the Internet
> or other private
> external networks for
> the Enterprise Network.
>
> ==> "Internet or _other_ private external networks" must be reworded;
> Internet is not a private external network :-)
ACK.
>
> Edge - The Edge is the ingress
> and egress points
> connecting to the
> Internet, Extranet, or
> to another private
> external network.
>
> ==> is the assumption so that the egress point = always
> ingress point?
> The plurality of the sentence is ambiguous.
Not necessarily esp. multi-site enterprise. Will reword.
>
> Administrative Domain - An Administrative Domain are the
> ingress and egress
> points connecting
> nodes across the Enterprise
> Network, behind the Edges.
>
> ==> same consideration about points (in "are" applies here). It also
> strikes me that the defininion could be simpler (drop out
> egress/ingress
> points completely, Edges covers that already).
That fixes the issue above too. Thanks.
>
> Extranet - An Extranet is any
> Enterprise Network
> owned network components
> at the Edge, but
> not part of the
> Administrative Domain.
>
> ==> "any EN owned components" ? I'm having trouble parsing
> the sentence,
> minor rewording.
ACK.
>
> Border Router - An Enterprise Network
> Border Router is a
> a router that is
> configured at the Edges.
>
> ==> I recommend using another word than "configured" --
> typically it has some other connotations.
ACK.
>
> Points of Transtion - An Enterprise Network Point of
>
> ==> s/Transtion/Transition/
>
> Every node that can be addressed by another node must be in a
> registered name service, managing this name service is a
>
> ==> s/,/, and/
Thanks.
>
> (multi-Party) require globally consistent addresses for peer-to-
>
> ==> s/P/p/
Thanks
>
> - Routers
> - Non Router Nodes
>
> ==> why just not say "Hosts" :-)
I agree. I think we were practicing valuing differences :--)
>
> solutions. A set of suggested solutions will be provided
> in a follow
> on document to this work.
>
> ==> s/follow on/follow-up/?
Thanks
>
> V5: IPv6 software upgrades are not available for existing
> routers and nodes.
>
> ==> s/available/available or possible/
Thanks
>
> V6: Source code for applications have been lost or cannot be
>
>
> ==> s/have/has/
Thanks
>
> V7: New business function being defined and can exist without
>
> ==> s/being/is being/, s/can/it can/
Thanks
>
> This point on the graph will be an transtion strategy. After the
>
> ==> s/transtion/transition/
Thanks
>
> Mobility : Requirements for nodes
>
> ==> s/Requirements/Mobility requirements/
Thanks
>
> Scenario #6 (subset of all scenarios)
>
> ==> s/6/7/ ?
Thanks
>
> The Enterprise network will have varying points of transition that
> will require different points of interoperability with
> IPv6 and IPv4.
>
> ==> reword "different points of interoperability"
ACK.
>
> but an IPv4 Internal Router is between them. These
> nodes could also
> be Mobile nodes too and in a remote location.
>
> ==> s/ too and/, or/
THanks
>
> 1. A Dual Stacked IPv4/IPv6 node wants to communicate
> to a legacy IPv4
> service and is on a Native IPv6 link and Routing
> Domain. Enterpise
>
> ==> "Routing Domain" (upper case) is not defined, I think?
>
> 2. A Dual Stacked IPv4/IPv6 node wants to communicate
> to a legcy IPv4
>
> ==> s/node /node /
> ==> s/legcy/legacy/
>
>
> This Point of Transition exists for the following conditions:
>
>
> 1. A Dual Stacked IPv4/IPv6 node wants to communicate
> with a legacy IPv4
>
> ==> kill the extra empty line
>
> security, applications, and remove some benefits from the IPv6
> protocol.
>
> 1. The Design Team highly recommends that network not adopt the
> policy
> in reference "1" above.
> 2. IPv6 ONLY nodes should not be deployed in a network
> until they
> will
> not require access to any legacy IPv4. This means that
> applications
> and infrastructure has been ported or moved to IPv6.
> Until that
> time nodes for transition should be Dual Stacked
> IPv4/IPv6 nodes.
> This means networks that want to use IPv6 ONLY nodes will be
> required
> to move applications and infrastructure to IPv6 first.
>
> ==> the 1., 2., list starts out of empty air, so I'm assuming
> there should
> be some kind of text there.
>
> addresses to nodes. Though DHCPv6 can be used to administrate
> addresses that are assigned to nodes.
>
> ==> s/Though/However,/ (or some other wordsmithing, looks
> funny that way)
>
> When preforming stateless autoconfiguration, an EUI-64 is generated
>
> ==> s/pre/per/
>
> bit IPV6 address. The EUI-64 is derived from the MAC
> address of the
> interface that being autoconfigured. This mechanism proves a large
>
> ==> s/IPV6/IPv6/
> ==> s/that/that's/
> ==> s/proves/provides/
>
> token should be considered when establishing an address plan."
>
> ==> s/"//
>
> This section will identify the tools requirements for an EN
> transitioning to IPv6 so the configuration issues for the EN are
>
> ==> s/EN/Enterprise Network/
>
> 12. Security Section
>
> ==> is this Security Section or Security Considerations? :-)
>
> Acknowledgments
>
> ==> this section is typically numbered, too.
>
> Design Team' Addresses
>
> Send email to ent-v6net@viagenie.qc.ca to contact the design
> team and send
> comments on the draft to v
>
> Authors contact info will be provided in a future draft.
>
> ==> s/Team'/Team's/
> ==> overlong line
> ==> s/Authors/Authors'/
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>
>