[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
On 8-jun-2006, at 1:28, Geoff Huston wrote:
This document discusses the applicability of the Shim6 IPv6 protocol
element and associated support protocols to provide site
multihoming
capabilities in IPv6.
Comments:
"While the Shim6 protocol does not impose any requirements on the
disposition of the locators involved in this process"
I don't understand what the authors are getting at here. I would
strongely suggest actually mentioning the requirements that aren't
imposed.
"In the scenario illustrated in Figure 1 host H communicates with some
remote host H'."
My understanding of using a ' to differentiate between two things is
that it generally means that the two things are very similar, or
represent two stages of the same thing. In this case, that doesn't
apply so it's confusing. Please use another letter for the second host.
In general, the document seems to assume understanding of inter-
domain routing. It is not explained what a locator is except that on
second use it says "locator (address)" which implies that the two are
the same thing. ULID isn't explained.
"The Shim6 protocol has other potential applications beyond site
multi-homing. For example, since Shim6 is a host-based protocol, it
can also be used to support session mobility between interfaces on a
multi-homed host."
I disagree because shim6 isn't built to support jumping to a
previously unknown address, it is assumed that the addresses to be
used after a failure are known before the failure.
Again my usual dislike of empty lines to skip to the next "page" for
a new heading.
" The Shim6 protocol is defined only for IPv6. However, there is no
fundamental reason why a Shim6-like approach could not support IPv4
addresses as locators, either to provide multi-homing support to
IPv4-numbered sites"
We're already running out of IPv4 addresses with ONE address per host...
" The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
encoding information in the lower 64 bits of locators. This imposes
the requirement on address assignment to Shim6-capable hosts that
all
interface addresses should be able to accommodate 64-bit interface
identifiers. This requirement is also imposed by CGA [RFC3972]."
Not to mention RFC 3513:
" For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format."
"4. Shim6 Capabilities
4.1. Fault Tolerance
4.1.1. Establishing Communications After an Outage"
Having headers without any text under them is considered bad style.
" managed centrally."
A single line on a new "page" is a "widow" and considered
undesirable. Simarly, the following line is an "orphan":
" So, in this configuration, the shim6 protocol is used to provide"
"However, MIPv6 lacks
of failure detection mechanisms"
Grammar.
"In this case, the shim6
protocol wouldn�t be used"
Unicode problem??
Extra space after each sentence.
Altough I feel there are way too many RFCs already, it might make
more sense to move the shim6/MIPv6 interactions to a separate
document because this part just doesn't seem to feel at home here.
Inconsistent use of "Shim6" and "shim6".
"It is
recommended that Shim6 is not used for SCTP sessions, and that path
maintenance is provided solely by SCTP."
Hm, I suspect that there are failure modes that aren't handled well
by SCTP that shim6 can handle. And AFAIK SCTP has no security to
speak of.
"In this case, the shim6 protocol would be associated to the
tunnel interface"
Missing period.
"6. Security considerations
This section will be completed before publication is requested."
How about completing it before review is requested?
" 2. Application
scenarios . . . . . . . . . . . . . . . . . . . . 4
3. Address
Configuration . . . . . . . . . . . . . . . . . . . . 6"
Inconsistent capitalization, happens in multiple places.
Choice of American/British spelling MAY be inconsistent, I spotted
"behaviour" and "optimization".
Iljitsch