Re: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker

2011-04-26 Thread Arifumi Matsumoto
Mark, On 2011/04/27, at 7:17, Mark Smith wrote: > Hi Arifumi, > > On Tue, 26 Apr 2011 20:15:31 +0900 > Arifumi Matsumoto wrote: > >> Mark, >> >> in your case, policy table should be helpful to manipulate source >> address selection behavior for SLAAC and manually configured >> addresses. >>

Re: Comment on rpl-routing-header draft

2011-04-26 Thread Thomas Narten
If you are purposefully breaking existing Standards Track specifications (which is what it sounds like you are doing) in order to "not require IP in IP tunneling" (a local optimization), you probably won't get much sympathy here. Certainly not from me! Thomas > Since RPL protocol is intended to o

RE: Comment on rpl-routing-header draft

2011-04-26 Thread Reddy, Joseph
Hi Thomas Since RPL protocol is intended to operate in networks with constrained devices and lossy, low-bandwidth links, there is a desire to not require IP-in-IP tunnelling that is usually used for inserting routing headers. This is detailed in the draft http://tools.ietf.org/html/draft-hui-6

Re: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker

2011-04-26 Thread Mark Smith
Hi Arifumi, On Tue, 26 Apr 2011 20:15:31 +0900 Arifumi Matsumoto wrote: > Mark, > > in your case, policy table should be helpful to manipulate source > address selection behavior for SLAAC and manually configured > addresses. > True, although that requires actively changing the default policy

Re: IETF80 6man Minutes

2011-04-26 Thread Bob Hinden
Scott, Thanks, the minutes have been updated. Bob On Apr 22, 2011, at 5:56 PM, Scott Brim wrote: > > On Apr 20, 2011 1:04 PM, "Bob Hinden" wrote: > > > > The minutes for the Prague IETF 6man working group meeting are now online > > at: > > > > http://www.ietf.org/proceedings/80/minutes/6m

Submitted new version of draft-ietf-6man-udpzero

2011-04-26 Thread Magnus Westerlund
Hi, For your information Gorry and I have submitted new versions of https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ There has been no announcement of this due to a bug in the new I-D submission tool that I tried out. The changes in the document are really only editorial. Cheers Magnu

Re: Introducing draft-6man-addresspartnaming

2011-04-26 Thread Jared Mauch
On Apr 26, 2011, at 9:10 AM, wrote: >> -Original Message- >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >> Richard Hartmann >> >> after renaming to draft-hartmann-6man-addresspartnaming, I am still >> waiting for feedback. > > Hi, > > I've been thinking an

RE: Introducing draft-6man-addresspartnaming

2011-04-26 Thread Guillaume.Leclanche
> -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Richard Hartmann > > after renaming to draft-hartmann-6man-addresspartnaming, I am still > waiting for feedback. Hi, I've been thinking and reading about it. I believe that if this doc will

Re: Comment on rpl-routing-header draft

2011-04-26 Thread Thomas Narten
> In the most common usage of this header, the border router inserts a > source routing header with the full set of intermediate nodes before > forwarding it towards the destination within the RPL network. and then. > Yes, we do not use IP-in-IP tunneling and instead simply insert the RH head= >

Re: MLD version for node req. draft

2011-04-26 Thread Thomas Narten
Good clarifications. I have revised the text. Thanks! Thomas Hitoshi Asaeda writes: > Hi Thomas, > >> >> "Nodes that need to join multicast groups SHOULD also implement either > >> >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]." > >> > > >> > Is there a short (less than one page) descri

Re: Suggestion for draft-ietf-6man-rfc3484-revise-02 - use current preferred value as a tie breaker

2011-04-26 Thread Arifumi Matsumoto
Mark, in your case, policy table should be helpful to manipulate source address selection behavior for SLAAC and manually configured addresses. As the final tie breaker, I do not see much sense to use preferred lifetime for that purpose. Indefinite lifetime does not always mean high preference. R