Hi Margaret, Thanks for the comments, I've been a bit concerned about the lack of interest/comments so far. I didn't think that we did a perfect job :) My comments below. BTW, these are comments/questions for all, hopefully we can get more feedback.
> I do think that this document includes interesting and useful > information about the perspective of cellular handset vendors, > and the technical requirements and issues for cellular handsets. > Within the IETF, therefore, it might be useful to publish this > document as an Informational RFC. => OK. > >I don't know if someone already answered this, > >but I believe the agreement in SLC was to progress > >the cellular host draft independantly, mainly because > >of the very close 3GPP deadline. > > How are we expecting the 3GPP to use this document? Why is > it needed for a 3GPP deadline? => Because they would use it as a reference for UMTS handsets implementors. > > Will outside groups believe that this document represents a > consensus of the IPv6 WG regarding what the minimal requirements > actually are for an IPv6 cellular host? => Yes. If so, I don't think that > we should publish this document without a more significant > discussion > within the WG. => Then let's begin the discussions. The only reason for standardising the draft in the IPv6 WG was to make sure that we're doing the right thing. Otherwise an informational RFC wouldn't have to go through the IPv6 WG or could have been replaced by a 3GPP spec. But since the competence is here, it is crucial that we get feedback. > It is not my impression that the WG has reached consensus on some > of the issues raised in this document, specifically: > > - Forbidding the use of DAD on some links => DAD is not needed if address duplication is not possible. Since each terminal gets a unique /64 (as per the advice draft), and since all terminals are on p2p links, DAD would be a waste of BW. But please have a closer look and let us know if something was missed. > - Situation where IP Security should be optional/disabled > (and the who distinction between "Core IP" and > "IP Security") => The distinction between IP security and core IP is merely an editorial distinciton. For example you can see that in 'core IP' we list all the IPv6 WG RFCs. As to whether IP security (I assume you mean IPsec) should be mandated or not, we can discuss that. But some questions that we would need to answer: - By 'mandated' do we mean implementation or use? - What should be mandated? - Why should it be mandated? > - Making ND optional on point-to-point links => RFC 2461 MUST be implemented, the exceptions are things like the Link layer suboption which is not relevant for these links. Did we miss something else? > - Making IPv6 autoconfiguration optional on hosts (rather > than mandatory on hosts and turned on/off for the > link in router advertisements) => You mean 2462 shoud be a SHOULD/MUST? That's possible for the generic cellular case, but for 3GPP, since there is a separate 'autoconfig' mechanism, this RFC is not needed. Would a SHOULD/MUST for the general case, and a 'not needed' for 3GPP be staisfactory? > Also, some of the comments in this document might best be handled > as "applicability" portions of other documents (i.e. use of 6to4 > over a cellular link), rather than as specific requirements for > a class of hosts. > > I do think that the WG will need to do some work on defining the > official contents of IPv6, including the minimal requirements for > IPv6 nodes (or hosts and routers), but this will probably require > a considerable effort, and a good deal of negotiation within the > WG and with the IESG. > > I am concerned that we may bypass this effort, to our later > detriment, > by publishing a document now that is mistakenly interpretted as a > standards-track host requirements document by outside groups. > > Does anyone else share this concern? What are our options to > ensure that this doesn't happen? > => I think you're making valid points and, as I said, our intention (since the London meeting) was to try to get as much feedback as possible. Very few comments were made, I assumed due to lack of interest/time. But, since the draft has been out for a long time now, it would be good to get these comments ASAP. Rushing the draft to become RFC is not good, but delaying it for too long can be just as detrimental to deployment. I hope more WG members would comment on this. Cheers, Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
