> => That's a bit inaccurate, there is a major difference > > that is due to the BW contraints of the air link. > > I see your points about size and memory, but it would > > be good if we identify the parts related to size > > and memory in which the draft deviates from IPv6 > > standards and distinguish them from the BW and > > l2-specific impacts. > > Let's not go there. Those of us with lots of grey recall > the days when > half the 3G bandwidth cost in the 6 figure range a month, > with loss and > latencies were about the same as the 3G link. Yes it is a > constrained > environment relative to other options today, but there is nothing > inherent in the BW, loss, latency, cost that limits the > potential for > use as a packet network. 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.
=> OK, there is no point in arguing this particular point without pointing out the relevant parts of the draft. After all we want to get feedback that will improve the quality of the draft. > 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. => OK, same comment as above. > > Again, to be able to improve the quality of the > > draft, we need to point out *exactly* where > > the relevant problems are. Margaret did some > > of this already and it is being discussed. > > I only had time for a quick pass this morning, and don't > expect to get > much more this month. Not that my personal time should drive a WG > schedule, but if Margret raised several questions, and my quick pass > found fundamental issues, I would argue that this doc is > not even close > to ready for last call. => Maragret's comments are being discussed and we should definitely discuss your concerns as well. But my point is, if the draft is not ready we need some concrete reasons to be able to improve it. Experience also shows that ignoring other organisations' reasons or business models will not help in developing the Internet that we'd like to see. I'm not suggesting that you're ignoring it, but I want to highlight the importance of participating in the work. > > > > > => 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. => You're quoting a section written specifically for _3GPP_cellular_hosts. As I tried to explain in *this* particular cellular network DAD is not useful at all, it just wastes BW. But this statement was not made for *all* cellular hosts. > > > Keep in mind > > > that doing so precludes the use of RFC3041 addresses, so the > > > applications where anonymity is most valuable (as one moves > > > around and > > > doesn't movement traced) are precluded. > > > > => 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. => Appendix B of the draft explains this, and so does the advice draft. 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. => Well, bridging is not the only/best way of connecting other devices to the cellular network. The mobile terminal can also be a router or an MLSN. Bridging will introduce a lot of other complexities in the current 3GPP architecture. If you're interested we can discuss it offline because it's very specific and will probably bore everyone else. > > A non-zero probability of > > > collision requires a mechanism to resolve duplicates, and > > DAD is the > > > currently defined one. If another one exists that makes > > > more sense over > > > a lossy air-link, we should consider replacing DAD > because it will > > > probably be more reliable in the general case as well. > > > > => It doesn't make sense if a host gets a /64 > > prefix that can not be used by anyone else on > > the cellular interface. > > See previous comment about L2 bridging by the > handset/embedded device in > a laptop ... => I don't know why you need it if you have the /64. But anyway if you want bridging it can work when simply running a PPP link between the phone and other devices behind it. Hesham > > Tony > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
