I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-garcia-shim6-applicability-03
Applicability Statement for the Level 3 Multihoming Shim Protocol
(Shim6)
Reviewer: Joel M. Halpern
Review Date: 18-Feb-2012
IETF LC End Date: 14-March-2012
IESG Telechat date: N/A
Summary: This document is almost ready for publication as an information rfc
Major issues:
The third paragraph of the introduction makes assertions about PI
based multihoming being "not generally available to end sites due to a
strict policy of route aggregation in the DFZ." As far as I know, this
is simply not the case. RIRs sell IPv6 PI for reasonable fees. Most
operators accept PI advertisements from customers. And those
advertisements are passed on to other ISP, and accepted. I would
recommend removal of the first sentence of this paragraph. Instead, it
needs to be noted that PI based multihoming can be done with IPv6, and
then point to the scaling concerns.
Moderate Issues:
I am unable to understand the sentence "Shim6 has no means to
enforce neither host nor network forwarding for a given locator to be
used as source address." I presume that what it is intended to
communicate is simply a fact about shim6. Please rewrite.
If I am reading section 7.1.1 on MobileIPv6/Shim6 interaction, it
looks like you are describing a scenario in which the mobile node uses
multiple HOAs as locators with a correspondent node. I would suggest
that this section would be clearer if the communicating parties were
identified. I suspect that the intended behavioral assumption is that
the mobile node will register its CoA multiple times, once with each
home address. But this does not seem to be stated explicitly.
Minor issues:
In th long comparative paragraph in the introduction, "The Shim6
approach is thought to have better scaling properties with respect to
the state held in the DFZ than the IPv approach." Could "IPv 4 approach
be replaced with "PI approach"?
In section 7.7 on the interaction with NPT66, I think it would be
helped by a bit more discussion of when certain shim6 messages are
exchanged, and which fields are validated. Specifically, I can not tell
if it is ever possible to get a shim6 ULID-pair option through an NPT66
which is rewriting the one of the addresses prefixes in the packet. I
suspect not. If indeed it just won't work, this needs to be stated MUCH
more clearly.
Yours,
Joel M. Halpern
Nits/editorial comments:
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
