Joel, Writing as an interested party, not a reviewer:
On 2012-02-19 09:12, Joel M. Halpern wrote: > 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. Yes, the point is that PI doesn't scale to ten million sites, but shim6 does. That should be clarified. > > > 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. It's a fact. In fact, it's a fact that seriously impacts shim6 deployability, according to the experience of a student of mine. Getting the appropriate locator pair out of a host, through the appropriate edge router and ISP link, and through the firewall at the far end, and doing the whole thing again in the reverse direction, is a significant configuration challenge. Brian > > 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 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
