----- Original Message ----- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: ipv6@ietf.org <ipv6@ietf.org> Sent: Mon Sep 22 15:00:08 2008 Subject: ipv6 Digest, Vol 53, Issue 7
Send ipv6 mailing list submissions to ipv6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ipv6 or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6 digest..." Today's Topics: 1. Re: [EMAIL PROTECTED] Mailing list (Marshall Eubanks) 2. RE: [EMAIL PROTECTED] Mailing list (Dan Wing) 3. Re: [EMAIL PROTECTED] Mailing list (Jari Arkko) 4. Re: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational RFC (Lars Eggert) 5. Fwd: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt" (hyunwook cha) ---------------------------------------------------------------------- Message: 1 Date: Tue, 16 Sep 2008 12:53:50 -0400 From: Marshall Eubanks <[EMAIL PROTECTED]> Subject: Re: [EMAIL PROTECTED] Mailing list To: Jeroen Massar <[EMAIL PROTECTED]> Cc: Brian Haberman <[EMAIL PROTECTED]>, Internet Area <[EMAIL PROTECTED]>, ipv6@ietf.org, [EMAIL PROTECTED], Dan Wing <[EMAIL PROTECTED]>, 'IPv6 Operations' <[EMAIL PROTECTED]>, Behave WG <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Is there going to be a audio broadcast and jabber room for this interim ? If so, how to join ? If not, aren't these aids now part of the "open participation" required of IETF interims ? Regards Marshall On Sep 16, 2008, at 5:01 AM, Jeroen Massar wrote: > Mark Townsley wrote: >> We have setup an email list for discussion leading up to the interim >> v4v6 coexistence meeting on October 1-2, 2008 in Montr?al, Canada. If >> you are registered to attend the meeting, you should already be on >> the list. >> >> The list is open, please subscribe and begin using it for all interim >> meeting related discussion (technical as well as >> administrative/logistical). > > For people, like me, who are not going to the meeting, but do want to > follow the discussions and possibly contribute to them, the list, > signup > and archives can be found here: > > https://www.ietf.org/mailman/listinfo/v4v6interim > > I couldn't find a reference to it from those URL's posted, might be > good > to put the ref there too. > > Greets, > Jeroen > ------------------------------ Message: 2 Date: Tue, 16 Sep 2008 11:12:30 -0700 From: "Dan Wing" <[EMAIL PROTECTED]> Subject: RE: [EMAIL PROTECTED] Mailing list To: "'Marshall Eubanks'" <[EMAIL PROTECTED]>, "'Jeroen Massar'" <[EMAIL PROTECTED]> Cc: 'Brian Haberman' <[EMAIL PROTECTED]>, 'Internet Area' <[EMAIL PROTECTED]>, ipv6@ietf.org, [EMAIL PROTECTED], 'IPv6 Operations' <[EMAIL PROTECTED]>, 'Behave WG' <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Marshall Eubanks [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 16, 2008 9:54 AM > To: Jeroen Massar > Cc: Mark Townsley; ipv6@ietf.org; 'IPv6 Operations'; Internet > Area; Behave WG; [EMAIL PROTECTED]; Brian Haberman; Jari > Arkko; Dan Wing > Subject: Re: [EMAIL PROTECTED] Mailing list > > Is there going to be a audio broadcast and jabber room for this > interim ? At this time, we are not sure of the audio broadcast capabilities that are available in the meeting room. > If so, how to join ? Such specifics will be announced on the [EMAIL PROTECTED] mailing list. -d > If not, aren't these aids now part of the "open participation" > required of IETF interims ? > > Regards > Marshall > > On Sep 16, 2008, at 5:01 AM, Jeroen Massar wrote: > > > Mark Townsley wrote: > >> We have setup an email list for discussion leading up to > the interim > >> v4v6 coexistence meeting on October 1-2, 2008 in Montr?al, > Canada. If > >> you are registered to attend the meeting, you should > already be on > >> the list. > >> > >> The list is open, please subscribe and begin using it for > all interim > >> meeting related discussion (technical as well as > >> administrative/logistical). > > > > For people, like me, who are not going to the meeting, but > do want to > > follow the discussions and possibly contribute to them, the list, > > signup > > and archives can be found here: > > > > https://www.ietf.org/mailman/listinfo/v4v6interim > > > > I couldn't find a reference to it from those URL's posted, > might be > > good > > to put the ref there too. > > > > Greets, > > Jeroen > > > ------------------------------ Message: 3 Date: Tue, 16 Sep 2008 22:32:22 +0300 From: Jari Arkko <[EMAIL PROTECTED]> Subject: Re: [EMAIL PROTECTED] Mailing list To: Marshall Eubanks <[EMAIL PROTECTED]> Cc: Brian Haberman <[EMAIL PROTECTED]>, Internet Area <[EMAIL PROTECTED]>, [EMAIL PROTECTED], ipv6@ietf.org, [EMAIL PROTECTED], Dan Wing <[EMAIL PROTECTED]>, 'IPv6 Operations' <[EMAIL PROTECTED]>, Behave WG <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Marshall, Several people have indeed indicated desire to participate remotely, and we are doing everything we can to make that possible. I think we will at least have a voice stream coming out of the meeting, jabber scribing (participants, please volunteer to scribe!), and possibility for questions from jabber. But we are still organizing those services and I don't want to promise anything more at this stage. See also some additional information below, copied from Mark's e-mail to the v4v6interim list. And this discussion should probably continue on that list as well :-) By the way -- if there is someone who has not registered for the physical meeting yet but plans to come, please try to register before Saturday, September 20th. Jari Mark Townsley wrote: > The ADs are working with the meeting host to see what can be done based > on what the facility has to offer. Cisco has offered webex hosting so > that remote participants can at least see what is being presented on the > projector and what is being said into a microphone, accessible over a > web and/or PSTN interface for voice (with recording of all this for > later viewing). But, without good microphones and discipline to use > them, the experience might be limited. Same for folks that want to chime > in over the phone, its nice to have some level of "floor control" to > help moderate the interaction. We could setup a camera as well, but > without real funding or exceptional volunteer efforts (not to mention > lending of equipment and good connectivity outside the building), I'm > not all that optimistic. We will do the best we can with the resources > available, wish I could say more - perhaps Suresh can jump in and give > more insight. ------------------------------ Message: 4 Date: Thu, 18 Sep 2008 14:40:14 +0200 From: Lars Eggert <[EMAIL PROTECTED]> Subject: Re: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational RFC To: ext Jari Arkko <[EMAIL PROTECTED]> Cc: 'IPv6 Operations' <[EMAIL PROTECTED]>, IETF IPv6 Mailing List <ipv6@ietf.org>, [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi, the second last call has ended, but I didn't see a review from the v6 community. (But maybe I missed it in the pile of unread email that built up during my vacation.) Are the v6 folks OK with this document? If yes, I'd like to move this forward after the gen-art review has been addressed. Thanks, Lars On 2008-8-13, at 10:00, ext Jari Arkko wrote: > 6MAN and V6OPS WGs, > > This informational document suggests changes to how > TCP deals with certain classes of ICMP errors. This affects > behavior in a number situations, including what happens > to dual stack nodes when they attempt to connect to hosts > that have both IPv4 and IPv6 addresses. > > The document seems reasonable, but I would like to see some > review from the IPv6 community to ensure that nothing has > been missed. Please take the time to review this during the > last call period which ends on August 26th. > > Thanks, > > Jari > > Begin forwarded message: > >> From: "ext The IESG" <[EMAIL PROTECTED]> >> Date: August 12, 2008 17:13:11 GMT+03:00 >> To: IETF-Announce <[EMAIL PROTECTED]> >> Cc: [EMAIL PROTECTED] >> Subject: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's >> Reaction to Soft Errors) to Informational RFC >> Reply-To: [EMAIL PROTECTED] >> >> The IESG has received a request from the TCP Maintenance and Minor >> Extensions WG (tcpm) to consider the following document: >> >> - 'TCP's Reaction to Soft Errors ' >> <draft-ietf-tcpm-tcp-soft-errors-08.txt> as an Informational RFC >> >> This is the second IETF last call for this document, to give the IPv6 >> community >> sufficient time to review how this document interacts with dual-stack >> hosts. >> >> 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-08-26. 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-tcpm-tcp-soft-errors-08.txt > > ------------------------------ Message: 5 Date: Fri, 19 Sep 2008 12:08:39 +0900 From: "hyunwook cha" <[EMAIL PROTECTED]> Subject: Fwd: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt" To: [EMAIL PROTECTED], ipv6@ietf.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Thomas, I would like to add a few comments as below. > > ------- Original Message ------- > Sender : Thomas Narten<[EMAIL PROTECTED]> > Date : 2008-09-18 22:01 (GMT+09:00) > Title : Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt" > > HYUN WOOK CHA <[EMAIL PROTECTED]> writes: > >> > > First of all, I would like to give a brief summary for the draft. >> > >> > > Existing specification (RFC2462) does not give a method on how to >> > > revoke DHCPv6 clients once they were invoked by the M or O flags of >> > > RA messages. >> > >> > Personally, I do not believe this is wrong or a problem. IMO, it is >> > just fine that there is no way to revoke an earlier hint that DHC is >> > available and clients should use it. (DHC has its own ways for dealing >> > with unresponsive servers -- clients will retransmit at a very low >> > rate, in such a way that such retransmissions do not cause operational >> > problems.) >> > >> >> Perhaps this point might be a major conflict. As we both know, >> consecutive DHCPv6 SOLICIT messages are sent exponentially >> back-offed if no valid replies are received within timeouts. Since >> this always holds, I would like to ask you why M/O flags should not >> be deprecated. > > Because the WG doesn't feel that the flags were so problematic that > they needed to be deprecated? There certainly has been concern that > existing implementations that do support the M&O bits should not > become non-complient through deprecation of the M&O flags. > > IMO, if we were to start over knowing what we know today, I'd be in > favor of not having the M&O bits at all. But we are not starting from > scratch... > I am not sure that M&O bits has no value. At this moment, I simply do not want to enter long debates for this topic. According to the RFC4861 and 4862, we have freedom to choose handling of M&O bits in RA. Specification in the RFC 2462 may be considered as an option, which has been implemented and practiced widely by many vendors. In this option, we found out the issue that there is no method to revoke DHCPv6 clients once invoked by RA M/O bits. Thus, we devised our proposal to address the issue clearly. >> IMO, revocation of DHCPv6 clients has also benefits if invocation of >> DHCPv6 clients should be guided by RA flags. > > On this point, I have seen little indication that the WG agrees with > you. > >> > Your proposal would differ and (from what I can tell) cause DHC to be >> > enabled/disabled/enabled/disabled/etc/ over and over again. This seems >> > like a bad solution in this case. >> > >> >> This is not true. Please refer to the section 4 in our draft. > > OK. Sorry for not reviewing this point in advance. > >> 4. An Algorithm for the Management of Internal State Variables >> >> We introduce an algorithm for the management of the internal state >> variables as follows. In this algorithm, two timers (M-timer and >> O-timer) are used, lifetimes of which is chosen to be 3 times of >> MaxRtrAdvInterval in [RFC4861]. When an RA is received that has the >> M flag set, ManagedFlag is set to TRUE and the M-timer is started or >> restarted. When an RA is received that has the O flag set, the >> OtherConfigFlag is set to TRUE and O-timer is strarted or restarted. >> If the M-timer goes off, the ManagedFlag is set to FALSE. If the >> O-timer goes off, OtherConfigFlag is set to FALSE. Thus, once >> ManagedFlag or OtherConfigFlag is set to TRUE, it can only be changed >> into FALSE after no RA is received with the bit set within lifetime >> of timers. Thus, state variables can be managed consistently even >> when a host is connected to multiple routers sending conflicting RA >> messages, because the RA messages with the bit set will overrule the >> ones with the bit clear. > > Sure, this would work. Though one can question whether the additional > implementation complexity is worth the benefit. > >> If you can not agree with our problem statement, I just hope that >> you have only the reasons mentioned above. > > Right. I just don't see the problem as particularly significant, and I > don't believe the WG will be able to agree on changing the definition > of the M&O flags (given past discussions). > I agree that the issue itself is not significant. However, we believe that the issue is a missing part which should be handled clearly so that implementors may be guided well and our proposal can be applicable for this. > If your real concern is that DHC continues to be invoked forever (even > when no DHC servers are available), wasting network resources, IMO, > the better place to make changes is in the DHC specification. I.e., > the DHC client should backoff more aggressively and "poll" for the > appearance of a new server very infrequently. > > This would be appear to be as simple as changing the value of SOL_MAX_RT: > > Parameter Default Description > ------------------------------------- > SOL_MAX_RT 120 secs Max Solicit timeout value > > See Section 17.1.2 in RFC 3315. > > Thomas > > > I do not think that your suggestion is right approach. Why do not you simply allow to revoke DHCPv6 clients by RA flags through which they are invoked? Joseph ------------------------------ _______________________________________________ ipv6 mailing list ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 End of ipv6 Digest, Vol 53, Issue 7 *********************************** -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------