Hi Erik,
Thanks for the review. I would like to clarify for your comments on [3.1-4]. The link to 3GPP TR23.853 is a technical report for a R11 work item. The work item is not finished due to time limits of R11 in 3GPP. You may see that there are 3 scenarios agreed and documented in the TR. This draft refers the TR for the *Scenario* justification. On the *solution mechanism*, the TR listed some related work which includes this draft. The references are not circular since they are from different aspects. Regards, Tao On Mon, Mar 26, 2012 at 2:31 AM, Erik Kline <e...@google.com> wrote: > >> Motivation and uses cases are now significant part of this draft > >> itself. If the group believes that it would be cleaner, it may be > >> split into separate draft. But please, don't use this possibility as > >> a way to delay this work. There are many networks that want this > >> option deployed asap. > > With respect to motivations...I think we need to weed out all the > specious ones first, to what's really left and worthy of interest. > IMHO, most, if not all, are specious. (And I suspect that Suresh's > Line-ID may be useful to address whatever else is left.) > > [3.1-1] > > "and the Service Provide would like to avoid routing on the CPE, there > is a need to provision static route entries on RGs/CPEs" > > I read this as "we don't want to do routing so here's how we're going > to do routing". If it's dynamic versus static, then saying that might > be more clear. > > [3.1-2] > > Is there an external source for this claim? It is not at all the case > for the two large IPv6 deployments with which I've been directly > involved. Furthermore, the current deployments to O(millions) of > existing IPv6 users make it seem like this isn't actually an issue. > > [3.1-4] > > Perhaps this has been discussed elsewhere, and I'm out of my depth, > but I thought DHCPv6 wasn't really spec'd until R10, and even then > only DHCPv6-PD. > > It looks to me like the 3GPP link goes to a draft for R11. > Additionally, this 3GPP draft seems to reference this MIF draft. This > makes it look like the references are circular (you can't cite IDs), > which is a bad justification. > > [3.1-6] > > The thing about these walled-garden arguments is that they seem to > imply that deployments don't want to give a route to a walled-garden > network to non-customers. But surely the existence of a route is not > alone sufficient for valid access? > > IOW, is there harm if a non-customer has a route a walled-garden > network of which they are not a customer? Unless the walled-garden is > advertising a default route, I wonder what the real harm is. > > But a potentially more important consideration is why walled garden > arguments appear anywhere within a Motivation section. Quoting from > the IAB in 2000, section 4.2.1 of RFC3002 > (http://tools.ietf.org/html/rfc3002#section-4.2): > > """ > It was strongly recommended that independent of the ubiquity of the > "walled garden" deployment scenario that protocols and architectural > decisions should not target this model. To continue the success of > Internet protocols at operating across a highly diverse and > heterogeneous environment the IETF must continue to foster the > adoption of an "open model". IETF protocol design must address > seamless, secure, and scalable access. > """ > > In the spirit of the above, I would like to see all discussion > pertaining to walled gardens unequivocally removed. This removes at > least use cases 1, 6, and 8. > > [3.1-7] > > Do you have any metrics on the support situation WRT 4191? Both > DHCPv6 and RIOs are SHOULDs in the IPv6 Node Requirements RFC (6434), > and both are pretty old by now (from 2005?). > > [3.1-10] > > s/home network with/home networks/, I think > > I think the "solve the rogue RA problem" is not a valid argument. > You're just trading a rogue RA problem for a rogue DHCPv6 server > problem. You can claim some security association with the DHCPv6 > server, but you can equally claim some security association with the > router(s) (e.g., SEND). > > Also, I think this is specious: > > "forced to run two protocols increasing complexity and > troubleshooting, where we have proof of concept in IPv4 that only one > protocol (DHCP) should be needed." > > In networks where you want run reliable IPv4, you still need 2 > protocols: DHCPv4 and VRRP. Just because they're operated by two > different groups doesn't mean you don't need them both. > > [3.1-11] > > If this is a use case that is not "investigated further" then I would > question why it's needed at all in what is fundamentally a > "Motivation" discussion. It also seems circular to propose as a > motivation that the option be used to break a tie when the option is > coexisting with RAs. > > [3.1-12] > > I'm not sure that a "different failure mode" is much of a motivation. > > I would take exception with a claim like a "rogue DHCP server will > cause no immediate harm". If someone gives me different DNS servers > they can still hijack all my traffic. Only in this case I think it's > even worse: I am aware of no provision in DHCP for the real server to > send out messages that can nullify the bad information. Once a host > is misconfigured that's pretty much it until the lease lifetime is up > or a network change event happens. > > [3.1-concluding paragraphs] > > I disagree with the assertion "It is better to have a generic option > then [sic] a bunch of competing vendor options". *IF* the decision of > the IETF is that this constitutes a "You're Doing It Wrong (TM)" > situation, then NO, a standardized option is not better; it would in > fact send the opposite message. Also, like Microsoft's RADIUS > extension for DNS servers, I don't think you would see multiple > competing definitionsーthe first to publish would become the de facto > standard. > > Fundamentally, I think the core issue to be decided is whether there > should be a standardized way for hosts on the same network to learn > different routes from their neighbors. I would think this constitutes > a fundamental architectural change, and therefore ought to be > considered in 6man (regardless of history and charters). > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif >
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
