Hi Tony, > While we can't assume that everything is > reasonable in the constrained environment, we also shouldn't > be throwing out capabilities that history has proven useful simply > because they are hard or cost a little more.
I think we'd appreciate more techincal comments on what you thik we got wrong. We've had the draft out for about 9 months, and most of the feedback has been from folks who have been considering how to optimize things. I'm sure we may have over-optimized, so specific recommendations on things are appreciated. Is it useful for us to also discuss the applicability of some of these features (like when & where to use them)? > > => It doesn't. But this is a classical argument > > which essentially says :'if you can't build it > > now, wait for a few years and you'll fit everything > > in'... well, as an engineer I don't have a major > > problem with that, but if I was someone who's > > trying to sell a wide range of products for > > different market segments, and some of those > > need to be limited in many ways to be sellable > > at all, then I would have a problem with this > > logic. > > Product decisions beyond what is technically possible don't belong in > the discussion about standards. My son's 3-year old > calculator has more low-power CPU & memory than the SGI workstation I had 10 > years ago, and it would fit in a package small enough for a 3G handset (and has a > longer battery life than my phone). I have to believe that there are > better options out there now (at least 5 years after that > device design was done), so the fact that a product team doesn't want to > use those for a specific market is not a problem for the IETF. Yeah, but my 4 year-old son's Mac (circa 1988) boots faster, doesn't freeze and the software fits on a floppy - which is much more than I can say about my laptop. Seriously, we are trying to consider IPv6 and ensure that it works, with a minimum amount of configuration, upgrading and a maximum of stability. If you think that specific recommendations we have in our draft are incorrect, please comment. > > => The document does NOT avoid DAD. The document > > is aimed at a generic cellular host, and wherever > > applicable, makes an applicability statement on the > > 3GPP-specific cases. The reason DAD is not needed > > in 3GPP, is that the way an address is allocated > > leaves no room for on-link duplication. And still, > > the document does not say, you MUST NOT do DAD, > > it simply says that in *this* instance of a cellular > > network, DAD is not needed. So if you just want > > to implement it anyway, then go ahead. > > 'A cellular host SHOULD NOT perform Duplicate Address Detection...' > While that is not a MUST NOT, it is a very strong instruction to avoid > it. If it said something like 'A cellular host MAY choose NOT perform > Duplicate Address Detection when it has other means to ensure > uniqueness...' I would be less concerned. That is a good point. > > => This is not a problem and address privacy is already > > supported without the need for DAD. > > The 3gpp-advice draft, the cellular host draft > > and 3GPP TS 23.060 can provide the exact details. > > If there is something specific that makes the statement true, it should > be written here so people don't have to chase around to find it. The > only thing that might make it true is that the router interface on the > subnet will ALWAYS have the 'unique bit' set in an EUI-64 derived > address, and will never use another format. This also presumes that the > handset doesn't provide layer-2 bridging services to other locally > connected devices. If it does that then there is no guarantee > that some device on the allocated subnet will not collide. OK, we'll check into adding text for this. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
