Re: Transition status
- Original Message - From: John C Klensin [EMAIL PROTECTED] To: Dan York [EMAIL PROTECTED]; Michael Thomas [EMAIL PROTECTED] Cc: Bill Fenner [EMAIL PROTECTED]; IETF discussion list ietf@ietf.org Sent: Friday, February 22, 2008 11:05 PM Subject: Re: Transition status (was Re: ISO 3166 mandatory?) --On Friday, 22 February, 2008 15:17 -0500 Dan York [EMAIL PROTECTED] wrote: I'll agree, too. We had some challenges getting the RUCUS mailing list up and running and then getting the web archives of the list up and running but the support folks were great to work with and got things sorted out rapidly. Folks, what I said was How much more of this will it take before you conclude that we have a problem?. That is a question, not an assertion that things are hopelessly snafued (or anything equivalent to that). I even accept Bill's proposed answer of A lot. Like several others, I've been very favorably impressed with how quickly AMS has gotten on top of problems and gotten them resolved once they are identified. I am concerned that insufficient resources were allocated to manage and test for what Bill describes as hundreds of things to manage. Some of that is due to an accident of bad timing that was presumably under no one's control: a cutover of the secretariat and web sites after, as Russ pointed out, registrations for IETF71 had already started. But I do believe that, if we ever recompete secretariat services again, the IAOC at the time should be sure they understand the risks and be sure that adequate investments are made to, at least, avoid repeating the types of problems that have been uncovered this time. That doesn't necessarily imply that we (or AMS) should be doing anything different now --again, I've been very impressed by the diligence with with problems have been addressed and the speed of recovery from them. It does imply that we should not be saying well, these things happen. In particular, it implies that the IAOC needs to be sure that there is institutional memory about things we are learning from this transition (and even from the CRNI-Neustar one) so that we are better prepared for next time. That is all, really. I think that there have been rather more problems in areas that are less in the public view, supporting the more private parts of the operation. But, I see the IAOC as culpable, at least in part, in that there seems to be no, or at least no adequate, specification of just what the system is. John's point about institutional memory is a good one, but to be effective, it has to be coupled with change control, so that all the changes that have taken place since the previous transition - and they seem to me to be numerous - are known and can be passed on to the incoming operators as and when there is a next transition. My sense is of AMS doing a grand job, but finding out after the event that there are a number - perhaps lots - of functions that they were not told about, that run by virtue of scripts tucked away in some dark corner that depend on a non-standard, locally-modified platform. Tom Petch john ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: Gen-art review of draft-ietf-netlmm-proxymip6-10.txt
Hi Elwyn, Thanks for the detailed review. Appreciate it. The latest draft that we published (-11) should address your comments. Please see inline. Regards Sri -Original Message- From: Elwyn Davies [mailto:[EMAIL PROTECTED] Sent: Monday, February 18, 2008 3:11 PM To: General Area Review Team Cc: Mary Barnes; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; IETF Discussion Subject: Gen-art review of draft-ietf-netlmm-proxymip6-10.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-netlmm-proxymip6-10.txt Reviewer: Elwyn Davies Review Date: 18 Feb 2008 IETF LC End Date: 20 Feb 2008 IESG Telechat date: 21 Feb 2008 Summary: This document is well written and is in fairly good shape for submission to the IESG. There are a number of minor issues which ought to be fixed. I think that for a more general reader there are a number of points that are fully covered in the detail but when reading the introduction and protocol overview questions arise which aren't answered until later in the document, and I was left thinking whether the problem had been addressed until much later. I have noted these items in the comments. I believe it would only take a few sentences to lay these issues to rest and make the document easier to understand for those who are not immersed in netlmm. Comments: s3, paras just after fig 2: The para after fig 2 claims that the LMA sets up the bidir tunnel; then the next para claims that the MAG 'establishes' the (same) tunnel. Be clear which one has responsibility. There are two parts to it. Each end point setting up its own part of the tunnel. Clarified the language. s3, p12: The local mobility anchor, being the topological anchor point for the mobile node's home network prefix, receives any packets that are sent by any correspondent node to the mobile node. I think it should be made clear (assuming I understand correctly what is going on) that this 'correspondent' node does not require any of the MIPv6 correspondent functionality and will not see any specialized MIPv6 messages. It is difficult to think of an alternative term, but this could be confusing. Replaced the word correspondent with node, still implying the LMA as the topological anchor point. s5.3.4, item 2: Whether the tunnel is deleted is surely an implementation issue. The LMA and MAG could agree to maintain the tunnel even if there are no MNs active on the MAG to save on setup costs. I think this could be a MAY, leaving it up to implementers to optimize if desired. (This is actually discussed later in s5.6.1.. a forward pointer is needed here) Yes. Clarified this to suggest, its only for dynamically created tunnels. s6.1, bullet 2: Does this make any assumptions about commonality of IID between addresses used by the interface? Its just talking about the L2 idenfier. s6.5: I thought it was said earlier that checking that the MN is entitled to mobility services was a MUST. Does the SHOULD refer to the means of authenticating? yes. s8.2: The (M) flag is not added to the Binding Ack message by RFC 4140 (only to the Binding Update msg). Fixed. Thanks s10: The new registry for the Handoff Indicator values is not specified in the IANA Considerations. Thanks. Good catch. Fixed Areas where some earlier explanation would make life easier for the general reader: 3: I think it would be useful to explain how the LMA knows that the MN that has moved from p-MAG to n-MAG is the same MN.. and hence gets the same prefix somewhere here (the MN_identity, auth and policy I think). Rephrased it to imply the LMA identifies the BCE associated with the request. s5.1, last para: (it turns out that s5.2 and s6.3 give most of the answers but I was left worrying) States that the mobile node's address prefix would normally be the key for the binding cache entry. This implies that it will be a unique key and hence every MN requires a different address prefix. I think this is sort of implied earlier, but I think it could be stressed at the outset. This raises a couple of more significant issues in my mind: - A MAG using stateless address config will be advertising one prefix per attached MN: if there are lots of them the RA's will be very large. Is this an issue? (not if everything is a pt2pt link, but - How does the MN know which prefix to use if it isn't a pt2pt link? [s5.2 does not address these issues although it clarifies that the prefix per MN mode is used] s6.3 states that it is assumed
Re: Transition status
Tom.Petch wrote: I think that there have been rather more problems in areas that are less in the public view, supporting the more private parts of the operation. This community has been moving relentlessly towards a complete loss of any sense of propriety. So I guess it was inevitable that we would have to suffer through references to the IETF's private parts. I cringe at the possible application of that discussion framework to the details of IETF anatomy and performance. The latter, in particular, engenders much anxiety. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. Sam, most of the changes are results of the allocation experiment that was conducted. The working group was fully aware of them and the changes made to the document see: http://psg.com/lists/namedroppers/namedroppers.2007/msg00190.html While it may well the be case that MOST of the changes resulted from the experiment and were called out to the WG, the change I cited (re: creating IANA registries using templates) was neither a result of the experiment (having been made before the experiment), nor called out. As for the WG being fully aware of the changes resulting from the experiment, I note that between the end of WGLC in November 2006 and the start of IETF last call a year later (which included the time of the experiment), the namedroppers list appears to have seen fourteen posts about 2929bis. The post-experiment discussion of these changes was minimal at best. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? This is an excellent IETF wide question it is outside the DNSEXT WG expertize to judge this issue. At this point there is no specific guidance to the expert(s) on what to do in this case. I'm glad you agree that it is an excellent question. I suspect it's one of the things IANA plans to weigh in on. -- Sam ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-mipshop-3gfh (Mobile IPv6 Fast Handovers for 3G CDMA Networks) to Informational RFC
The IESG has received a request from the Mobility for IP: Performance, Signaling and Handoff Optimization WG (mipshop) to consider the following document: - 'Mobile IPv6 Fast Handovers for 3G CDMA Networks ' draft-ietf-mipshop-3gfh-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-03-15. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mipshop-3gfh-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14650rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org http://www.ietf.org/mailman/listinfo/ietf-announce
71st IETF - Hotels and Social Event
71st IETF Meeting Philadelphia, PA, USA March 9-14, 2008 Host: Comcast The Marriott still has a limited number of rooms available at the group rate but is currently sold out on the night of Thursday, March 13. The Doubletree Hotel is currently sold out. Please note that the Marriott will have a large number of people checking out on Sunday, March 9 which will mean rooms will not be available to check into until the hotel’s 4:00pm check-in time. We have secured an additional block of rooms at the Hilton Garden Inn, which is approximately three blocks from the Marriott. The Garden Inn is holding this block at the IETF group rate of $189 until Friday, February 29, 2008. Additional information on the Garden Inn can be found at: http://www.ietf.org/meetings/71-hotels.html The social event is currently sold out. If you have already registered and paid for your IETF registration and would like to be put on a waiting list for social event tickets, you can do so at: https://www.amsl.com/ietf/socialwaitlist.py For those who need visas, don't forget to request your letter of invitation. Information can be found at: http://www.ietf.org/meetings/71-invite_letter.html Only 13 days until the Philadelphia IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/71-IETF.html ___ IETF-Announce mailing list IETF-Announce@ietf.org http://www.ietf.org/mailman/listinfo/ietf-announce
