Subject: Re: ipv6 Digest, Vol 53, Issue 7

From: <[email-masked]>
Date: Mon, 22 Sep 2008 16:00:58 -0400

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Mon Sep 22 15:00:08 2008
Subject: ipv6 Digest, Vol 53, Issue 7

Send ipv6 mailing list submissions to
	[email-masked]

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-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ipv6 digest..."

Today's Topics:

   1. Re: [email-masked] Mailing list (Marshall Eubanks)
   2. RE: [email-masked] Mailing list (Dan Wing)
   3. Re: [email-masked] 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-masked]>
Subject: Re: [email-masked] Mailing list
To: Jeroen Massar <[email-masked]>
Cc: Brian Haberman <[email-masked]>,	Internet Area
	<[email-masked]>, [email-masked],	[email-masked], Dan Wing
	<[email-masked]>,	'IPv6 Operations' <[email-masked]>, Behave WG
	<[email-masked]>
Message-ID: <[email-masked]>
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-masked]>
Subject: RE: [email-masked] Mailing list
To: "'Marshall Eubanks'" <[email-masked]>,	"'Jeroen Massar'"
	<[email-masked]>
Cc: 'Brian Haberman' <[email-masked]>,	'Internet Area'
	<[email-masked]>, [email-masked],	[email-masked], 'IPv6
	Operations' <[email-masked]>,	'Behave WG' <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="iso-8859-1"

> -----Original Message-----
> From: Marshall Eubanks [mailto:[email-masked]] 
> Sent: Tuesday, September 16, 2008 9:54 AM
> To: Jeroen Massar
> Cc: Mark Townsley; [email-masked]; 'IPv6 Operations'; Internet 
> Area; Behave WG; [email-masked]; Brian Haberman; Jari 
> Arkko; Dan Wing
> Subject: Re: [email-masked] 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-masked] 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-masked]>
Subject: Re: [email-masked] Mailing list
To: Marshall Eubanks <[email-masked]>
Cc: Brian Haberman <[email-masked]>,	Internet Area
	<[email-masked]>, [email-masked],	[email-masked],
	[email-masked], Dan Wing <[email-masked]>,	'IPv6 Operations'
	<[email-masked]>, Behave WG <[email-masked]>
Message-ID: <[email-masked]>
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-masked]>
Subject: Re: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's
	Reaction to	Soft Errors) to Informational RFC
To: ext Jari Arkko <[email-masked]>
Cc: 'IPv6 Operations' <[email-masked]>,	IETF IPv6 Mailing List
	<[email-masked]>,	[email-masked]
Message-ID: <[email-masked]>
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-masked]>
>> Date: August 12, 2008 17:13:11 GMT+03:00
>> To: IETF-Announce <[email-masked]>
>> Cc: [email-masked]
>> Subject: Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's  
>> Reaction  to  Soft Errors) to Informational RFC
>> Reply-To: [email-masked]
>>
>> 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-masked] mailing lists by 2008-08-26. Exceptionally,
>> comments may be sent to [email-masked] 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-masked]>
Subject: Fwd: Re: Request for Advices on the draft
	"draft-cha-ipv6-ra-mo-00.txt"
To: [email-masked], [email-masked], [email-masked], [email-masked]
Message-ID:
	<[email-masked]>
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-masked]>
> 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-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ipv6

End of ipv6 Digest, Vol 53, Issue 7
***********************************
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------