-----Original Message-----
From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On
Behalf Of marcelo bagnulo braun
Sent: Wednesday, June 14, 2006 3:03 PM
To: Iljitsch van Beijnum
Cc: shim6-wg
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
Hi Iljitsch,
thanks for your detailed comments...
some replies below...
El 13/06/2006, a las 16:52, Iljitsch van Beijnum escribió:
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.
the point being made in the sentence is that it would be
enough that one of the peers has multiple addresses in order
to be able to use the
shim6 protocol, no matter what those addresses are. In
particular is not strictly required that those addresses come
from different isp (as it is somehow the scenario for which
the shim6 was designed for). It would be possible to use the
shim6 protocol in a host that has multiple interfaces with
one address in each interface and all the addresses with the
same prefix for instance... i guess you know all this
already, but this is what the draft is trying to communicate
(unsuccessfully it seems :-(
would it improve rephrasing it as:
While the Shim6 protocol does not impose any requirements
on the addresses involved in this process
"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.
:-)
will ddo
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.
ok, we can add a definition section and include those two...
is there any other term that you think should be there?
"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.
well, you could send an UPDATE message from the new location
with the new locator and the validation information for it
included in the UPDATe message itself. There is no
fundamental reason why this cannot be done (we would need to
see the actual details of the protocol for this in any case...)
Again my usual dislike of empty lines to skip to the next
"page" for a
new heading.
next one will be a "comptact" version....
" 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...
fundamental reason from the protocol prespective... do you
want us to change something here?
" 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."
ok, will add the reference
"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"
i guess this will be solved with the compact version...
"However, MIPv6 lacks
of failure detection mechanisms"
Grammar.
"In this case, the shim6
protocol wouldn�t be used"
Unicode problem??
i think it is a typo
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.
well, the whole part about interactions with other parts of
the stack seems to belong to this document to me but perhaps
we can hear other opinions...
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.
i don't know...
perhaps unidirectional failures? shim6 can handle a
communication with two unidirectional address pairs.... i
don't know about sctp...
And AFAIK SCTP has no security to speak of.
i don't know....
"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?
:-)
we do what we can....
" 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".
regards, marcelo
Iljitsch