Re: 6MAN WG Last Call:

Suresh, >> - section 1 bullet b. couldn't you argue that turning off periodic RAs is a >> configuration error? > > Not sure. It is commonly used in several WLAN and datacenter networks > to reduce the amount of multicast traffic. ack. >> - section 1 bullet c. If a link isn't multicast capable,

RE: 6MAN WG Last Call:

Hi Ole, Thanks for your comments. Please find responses inline. > -Original Message- > From: Ole Troan [mailto:otr...@employees.org] > Sent: September-03-13 10:03 AM > To: Suresh Krishnan > Cc: 6man WG > Subject: Re: 6MAN WG Last Call: > > [resending] >

Re: 6MAN WG Last Call:

[resending] all, short and sweet document; a few comments if I may. - this new behaviour is supposed to be implemented by all hosts, right? shouldn't this document then update rfc4861? - "AP" isn't defined section 1. - section 1 bullet b. couldn't you argue that turning off periodic RAs is a c

Re: 6MAN WG Last Call:

Hi Tim, - Original Message - > From: Tim Chown > To: Fernando Gont > Cc: Mark ZZZ Smith ; "6man-cha...@tools.ietf.org > Chairs" <6man-cha...@tools.ietf.org>; 6man WG > Sent: Friday, 23 August 2013 8:56 PM > Subject: Re: 6MAN WG Last Call: > >

Re: 6MAN WG Last Call:

On 22 Aug 2013, at 22:58, Fernando Gont wrote: > On 08/19/2013 08:19 AM, Mark ZZZ Smith wrote: >> >> Going by the title, it seems my comment was missed about not implying >> that this address generation technique is limited to SLAAC slack >> scenarios, but could be useful with any address config

Re: 6MAN WG Last Call:

all, short and sweet document; a few comments if I may. - this new behaviour is supposed to be implemented by all hosts, right? shouldn't this document then update rfc4861? - "AP" isn't defined section 1. - section 1 bullet b. couldn't you argue that turning off periodic RAs is a configuration

Re: 6MAN WG Last Call:

Hi Fernando, - Original Message - > From: Fernando Gont > To: Mark ZZZ Smith > Cc: Ole Troan ; 6man WG ; > "6man-cha...@tools.ietf.org Chairs" <6man-cha...@tools.ietf.org> > Sent: Friday, 23 August 2013 7:58 AM > Subject: Re: 6MAN WG Last Call: >

Re: 6MAN WG Last Call:

On 08/19/2013 08:19 AM, Mark ZZZ Smith wrote: > > Going by the title, it seems my comment was missed about not implying > that this address generation technique is limited to SLAAC slack > scenarios, but could be useful with any address configuration method > (i.e, SLAAC, DHCPv6, static, +future.)

Re: 6MAN WG Last Call:

- Original Message - > From: Mikael Abrahamsson > To: Erik Kline > Cc: 6man WG > Sent: Wednesday, 21 August 2013 3:35 PM > Subject: Re: 6MAN WG Last Call: > > On Tue, 20 Aug 2013, Erik Kline wrote: > >> To support this scheme as I understand

RE: 6MAN WG Last Call:

boun...@ietf.org] On Behalf Of > Ronald Bonica > Sent: Tuesday, August 20, 2013 9:34 AM > To: C. M. Heard; IPv6 > Subject: RE: 6MAN WG Last Call: 04> > > Hi Mike, > > Thanks for your review of all three documents. The following is some > gentle pushback. > > At

RE: 6MAN WG Last Call:

Then 0 it is! Ron > -Original Message- > From: C. M. Heard [mailto:he...@pobox.com] > Sent: Wednesday, August 21, 2013 12:01 PM > To: Ronald Bonica > Cc: Ole Troan; IPv6 > Subject: RE: 6MAN WG Last Call: chain-04> > > Works for me. > > //cmh

RE: 6MAN WG Last Call:

dnesday, August 21, 2013 10:56 AM > > To: Ronald Bonica > > Cc: C.M.Heard; IPv6 > > Subject: Re: 6MAN WG Last Call: > chain-04> > > > > > This works, too. But now we have three participants in the discussion > > and three opinions! > > > > > &g

RE: 6MAN WG Last Call:

I am happy to set the pointer field to 0 if Mike agrees. Ron > -Original Message- > From: Ole Troan [mailto:otr...@employees.org] > Sent: Wednesday, August 21, 2013 10:56 AM > To: Ronald Bonica > Cc: C.M.Heard; IPv6 > Subject: Re: 6MAN WG La

Re: 6MAN WG Last Call:

ipv6-boun...@ietf.org] On Behalf Of >> Ole Troan >> Sent: Wednesday, August 21, 2013 10:37 AM >> To: C.M.Heard >> Cc: IPv6 >> Subject: Re: 6MAN WG Last Call: > chain-04> >> >>> The reason I didn't suggest pointing at the Fragment Header is >

RE: 6MAN WG Last Call:

e Troan > Sent: Wednesday, August 21, 2013 10:37 AM > To: C.M.Heard > Cc: IPv6 > Subject: Re: 6MAN WG Last Call: chain-04> > > > The reason I didn't suggest pointing at the Fragment Header is > because > > it would carry the same information that it would

RE: 6MAN WG Last Call:

M > To: IPv6 > Subject: RE: 6MAN WG Last Call: chain-04> > > The reason I didn't suggest pointing at the Fragment Header is because > it would carry the same information that it would in a correctly > fragmented packet, namely M=1 and Fragment Offset=0 (the signature of >

Re: 6MAN WG Last Call:

> The reason I didn't suggest pointing at the Fragment Header is > because it would carry the same information that it would in a > correctly fragmented packet, namely M=1 and Fragment Offset=0 (the > signature of an initial fragment). The Payload Length field is what > indicates that the frag

RE: 6MAN WG Last Call:

The reason I didn't suggest pointing at the Fragment Header is because it would carry the same information that it would in a correctly fragmented packet, namely M=1 and Fragment Offset=0 (the signature of an initial fragment). The Payload Length field is what indicates that the fragment is to

RE: 6MAN WG Last Call:

Mike, Good point! The pointer field in the ICMPv6 Parameter Problem Message needs to carry some value. My first guess would be to point at the first byte of the Fragment Header, because the packet is improperly fragmented. I would not point at the Payload Length in the IPv6 header, because the

Re: 6MAN WG Last Call:

On Wed, 21 Aug 2013, Brian E Carpenter wrote: > Hi Ron, > > On 21/08/2013 01:33, Ronald Bonica wrote: > > Hi Mike, > > > > Thanks for your review of all three documents. The following is some gentle > > pushback. > > ... > > > There is no real solution to the long header problem. The best >

Re: 6MAN WG Last Call:

On Tue, 20 Aug 2013, Erik Kline wrote: To support this scheme as I understand it, the Linux kernel ipv6 code would need to take some module parameters at boot or load time, so as to force it to not do link-layer-derived link-local autoconfig but instead load up the required parameters from non

Re: 6MAN WG Last Call:

Hi, Erik, On 08/20/2013 05:55 AM, Erik Kline wrote: >>> I agree that this all seems fine in theory. Are we collectively >>> convinced this will not lead to tragically (IPv6-)orphaned machines in >>> certain scenarios? >> >> Sorry, what are the scenarios you have in mind? > > Well, I guess first

Re: 6MAN WG Last Call:

Hi Ron, On 21/08/2013 01:33, Ronald Bonica wrote: > Hi Mike, > > Thanks for your review of all three documents. The following is some gentle > pushback. ... > There is no real solution to the long header problem. The best that we can do > is to put a stake in the ground, saying that implemen

RE: 6MAN WG Last Call:

August 19, 2013 8:58 PM > To: IPv6 > Subject: Re: 6MAN WG Last Call: chain-04> > > Greetings, > > My main question is why this draft is not better integrated with > draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, > which have overlapping or at leas

Re: 6MAN WG Last Call:

On 19 August 2013 18:57, Fernando Gont wrote: > Erik, > > On 08/19/2013 06:40 AM, Erik Kline wrote: >> I pre-apologize, as always, for my ignorance, but...is there an >> implementation of this? Specifically, I'm mildly concerned about this >> for link-local addresses. >> >> Compliant implementati

Re: 6MAN WG Last Call:

On 20/08/2013 16:02, Fernando Gont wrote: > Hi, Mike > > On 08/19/2013 09:58 PM, C. M. Heard wrote: >> My main question is why this draft is not better integrated with >> draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, >> which have overlapping or at least related subject mat

Re: 6MAN WG Last Call:

Hi, Mike On 08/19/2013 09:58 PM, C. M. Heard wrote: > > My main question is why this draft is not better integrated with > draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, > which have overlapping or at least related subject matter. Because what's in draft-ietf-6man-oversize

Re: 6MAN WG Last Call:

Greetings, My main question is why this draft is not better integrated with draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, which have overlapping or at least related subject matter. The thrust of draft-ietf-6man-oversized-header-chain is to require that all extension heade

Re: 6MAN WG Last Call:

Hi, Going by the title, it seems my comment was missed about not implying that this address generation technique is limited to SLAAC slack scenarios, but could be useful with any address configuration method (i.e, SLAAC, DHCPv6, static, +future.) There seemed to be some support for decoupling t

Re: 6MAN WG Last Call:

Erik, On 08/19/2013 06:40 AM, Erik Kline wrote: > I pre-apologize, as always, for my ignorance, but...is there an > implementation of this? Specifically, I'm mildly concerned about this > for link-local addresses. > > Compliant implementations cannot even begin any IPv6 link-local > operations u

Re: 6MAN WG Last Call:

I pre-apologize, as always, for my ignorance, but...is there an implementation of this? Specifically, I'm mildly concerned about this for link-local addresses. Compliant implementations cannot even begin any IPv6 link-local operations until the secret key has been loaded from stable storage. They

Re: 6MAN WG Last Call:

On Jul 31, 2013, at 14:03 , Brian E Carpenter wrote: > > I suppose, if the MAC layer actually delivers the clashing packet to the ND > layer. Alas, the presence of Neighbor Discovery proxy can disrupt that mechanism. -- james woodyatt core os networking

Re: 6MAN WG Last Call:

Ole, On 31/07/2013 20:22, Ole Troan wrote: > Brian, > > (participant hat) > >>> I found the last statements in section 4 slightly confusing: >>> There is no algorithm >>> for determining whether this case has arisen, rather than a genuine >>> MAC address collision. Implementers should car

Re: 6MAN WG Last Call:

Brian, (participant hat) >> I found the last statements in section 4 slightly confusing: >> There is no algorithm >> for determining whether this case has arisen, rather than a genuine >> MAC address collision. Implementers should carefully consider the >> consequences of continuing IPv6

Re: 6MAN WG Last Call:

Roland, On 30/07/2013 01:41, Roland Bless wrote: > Hi, > On 19.07.2013 00:11, Bob Hinden wrote: >> http://tools.ietf.org/html/draft-ietf-6man-ug-01 >> >> as a Proposed Standard. Substantive comments and statements of support for >> advancing this document should be directed to the mailin

Re: 6MAN WG Last Call:

Hi, On 19.07.2013 00:11, Bob Hinden wrote: > http://tools.ietf.org/html/draft-ietf-6man-ug-01 > > as a Proposed Standard. Substantive comments and statements of support for > advancing this document should be directed to the mailing list. Editorial > suggestions can be sent to the auth

Re: 6MAN WG Last Call:

On Jul 24, 2013, at 11:07 PM, Brian E Carpenter wrote: > On 25/07/2013 04:31, Jouni Korhonen wrote: >> I think the document is ready to go. Good that we finally can >> close the eternal u & g bit mess. >> >> For the open issue in Section 7. I am also in favour >> of retaining the reserved IID

Re: 6MAN WG Last Call:

On 25/07/2013 04:31, Jouni Korhonen wrote: > I think the document is ready to go. Good that we finally can > close the eternal u & g bit mess. > > For the open issue in Section 7. I am also in favour > of retaining the reserved IID registry. > > Then one or two nits. In Section 5. where changes t

Re: 6MAN WG Last Call:

I think the document is ready to go. Good that we finally can close the eternal u & g bit mess. For the open issue in Section 7. I am also in favour of retaining the reserved IID registry. Then one or two nits. In Section 5. where changes to RFC4291 are listed I wonder why those new pieces of te

Re: 6MAN WG Last Call:

On 23/07/2013 20:14, Ralph Droms wrote: > I have reviewed the document; in my opinion it is ready to be sent to the > IESG. > > I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along with > draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may be extended > to a set of

Re: 6MAN WG Last Call:

On 23/07/2013 18:32, JINMEI Tatuya / 神明達哉 wrote: > At Tue, 23 Jul 2013 13:09:50 +1200, > Brian E Carpenter wrote: > >>> I have one comment that may improve the clarity of the document: the >>> latter half of Section 4 is not very understandable to me: >>> >>>There is one case in RFC 4862 that

Re: 6MAN WG Last Call:

I have reviewed the document; in my opinion it is ready to be sent to the IESG. I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along with draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may be extended to a set of links." For completeness, RFC 6775 could be cited a

Re: 6MAN WG Last Call:

At Tue, 23 Jul 2013 13:09:50 +1200, Brian E Carpenter wrote: > > I have one comment that may improve the clarity of the document: the > > latter half of Section 4 is not very understandable to me: > > > >There is one case in RFC 4862 that requires additional consideration: > > > >"On th

Re: 6MAN WG Last Call:

Hi Brian, - Original Message - > From: Brian E Carpenter > To: Mark ZZZ Smith > Cc: IPv6 IPv6 List > Sent: Tuesday, 23 July 2013 8:00 AM > Subject: Re: 6MAN WG Last Call: > > On 23/07/2013 09:12, Mark ZZZ Smith wrote: >> Hi, >>      >> >

RE: 6MAN WG Last Call:

Hi All, I support to move forward this draft. Cheers Yu -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Bob Hinden Sent: Friday, July 19, 2013 6:11 AM To: IPv6 IPv6 List Cc: Bob Hinden Subject: 6MAN WG Last Call: All, This message starts

Re: 6MAN WG Last Call:

On 23/07/2013 12:28, JINMEI Tatuya wrote: > At Thu, 18 Jul 2013 15:11:00 -0700, ... > I think this draft is generally well written and good to be advanced > (although I personally don't have a strong opinion on what's proposed > in the draft). > > I have one comment that may improve the clarity o

Re: 6MAN WG Last Call:

At Thu, 18 Jul 2013 15:11:00 -0700, Bob Hinden wrote: > This message starts a two week 6MAN Working Group on advancing: > > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename: draf

Re: 6MAN WG Last Call:

On 23/07/2013 09:12, Mark ZZZ Smith wrote: > Hi, > > Firstly, I support advancing this draft. > > Some suggested changes: > > " This has no known harmful effect as long as the >replicated MAC addresses and IIDs are used on different layer 2 >links. If they are used on the same link, of

Re: 6MAN WG Last Call:

- Original Message - > From: Brian E Carpenter > To: 6man > Cc: > Sent: Tuesday, 23 July 2013 6:41 AM > Subject: Re: 6MAN WG Last Call: > >T he draft contains one open issue, in section 7: > >>     OPEN ISSUE: Alternatively, we could de

Re: 6MAN WG Last Call:

Hi, Firstly, I support advancing this draft. Some suggested changes: "  This has no known harmful effect as long as the    replicated MAC addresses and IIDs are used on different layer 2    links.  If they are used on the same link, of course there will be a    problem, to be detected by duplica

Re: 6MAN WG Last Call:

The draft contains one open issue, in section 7: >OPEN ISSUE: Alternatively, we could decide to close the reserved IID >registry completely ... Absent other opinions, my proposal is that we do not close the registry. The rest of the section sets a high bar for new entries, which is probab

Re: 6MAN WG Last Call:

> This message starts a two week 6MAN Working Group on advancing: > > Title : Significance of IPv6 Interface Identifiers > Author(s) : Brian Carpenter > Sheng Jiang > Filename: draft-ietf-6man-ug-01.txt > Pages : 1

Re: 6MAN WG Last Call:

On 22/07/2013 23:41, Bernie Volz (volz) wrote: > Perhaps you've argued this before, but per rfc 4291, u=1, g=0 is what an IID > that was formed from a MAC address uses, not u=0. The IEEE mac bits are u=0, > g=0. In the context below, perhaps best to be clear ... Use IEEE "u" = "g" = > 0? Or IID

Re: 6MAN WG Last Call:

On 23/07/2013 04:31, Templin, Fred L wrote: > Hi, > > This looks good, but may want to include 1-2 sentences on ISATAP > [RFC5214] which is another variant on modified EUI-64. Yes, we can add that for completeness. (In 6over4, RFC2529, we forced u=g=0, but that is operationally irrelevant.) Tha

RE: 6MAN WG Last Call:

Hi, This looks good, but may want to include 1-2 sentences on ISATAP [RFC5214] which is another variant on modified EUI-64. Thanks - Fred fred.l.temp...@boeing.com > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Bob Hinden > Sent: Thursday

Re: 6MAN WG Last Call:

Perhaps you've argued this before, but per rfc 4291, u=1, g=0 is what an IID that was formed from a MAC address uses, not u=0. The IEEE mac bits are u=0, g=0. In the context below, perhaps best to be clear ... Use IEEE "u" = "g" = 0? Or IID "u" = 1 and "g" = 0. (It is also a bit odd that 2nd s

RE: 6MAN WG Last Call:

Hi, WG Support for advancing. Best regards, Bing > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Bob Hinden > Sent: Friday, July 19, 2013 6:11 AM > To: IPv6 IPv6 List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: > > All, > > This mess

Re: 6MAN WG Last Call:

Magnus is correct, the second document should have said "Proposed Standard". The last call can continue. Bob On Mar 1, 2013, at 12:23 AM, Magnus Westerlund wrote: > Hi, > > Just a correction on the intended status. > > On 2013-02-26 00:57, Bob Hinden wrote: >> All, >> >> This message starts

Re: 6MAN WG Last Call:

Hi, Just a correction on the intended status. On 2013-02-26 00:57, Bob Hinden wrote: > All, > > This message starts a one week 6MAN Working Group on advancing: > > Title : IPv6 and UDP Checksums for Tunneled Packets > Author(s) : Marshall Eubanks >

Re: 6MAN WG Last Call:

I have read this draft and support the work. The intention is good. The detail is thorny. Substantive Comment: I think you're going to be asked lots of questions about what constitutes an "IPv6 header chain," and to provide a tighter specification of where it ends. I'm sure there are people who

Re: 6MAN WG Last Call:

I believe the draft needs one more spin in order to be precise about the number of bytes included in the upper layer header. Consider that in addition to the common transport headers, and ICMPv6, any protocol number defined in the IANA registry that is not an extension header might in theory occur

Re: 6MAN WG Last Call:

Understood. No objection from here. Yours, Joel On 1/17/2013 5:27 AM, Magnus Westerlund wrote: On 2012-12-12 09:44, Magnus Westerlund wrote: Thanks for the Review, On 2012-12-12 02:02, Joel M. Halpern wrote: This (and the companion document draft-ietf-6man-udpzero) seem ready for publication

Re: 6MAN WG Last Call:

On 2012-12-12 09:44, Magnus Westerlund wrote: > Thanks for the Review, > > On 2012-12-12 02:02, Joel M. Halpern wrote: >> This (and the companion document draft-ietf-6man-udpzero) seem ready for >> publication to me. >> >> I do have a minor questions. It is sufficiently minor that if necessary >>

Re: 6MAN WG Last Call:

Yes, thanks. Regards Brian Carpenter On 18/12/2012 14:53, Fernando Gont wrote: > On 12/18/2012 11:35 AM, Brian E Carpenter wrote: >>> Agreed. What I meant in my response to Hosnieh is that these addresses >>> behave (in terms of lifetimes) in the same way as traditional slaac >>> addresses, bu

Re: 6MAN WG Last Call:

On 12/18/2012 11:35 AM, Brian E Carpenter wrote: >> Agreed. What I meant in my response to Hosnieh is that these addresses >> behave (in terms of lifetimes) in the same way as traditional slaac >> addresses, but do not vary over time as RFC4941-addresses. >> >> So it's not clear to me what's the c

Re: 6MAN WG Last Call:

On 18/12/2012 14:40, Ole Troan wrote: >> The concern is that we are still mainly ignoring the renumbering >> problem, and in some years time this will be serious for users. >> But if you add "From the point of view of renumbering, these addresses >> behave like RFC4941 addresses" the point is cover

Re: 6MAN WG Last Call:

> The concern is that we are still mainly ignoring the renumbering > problem, and in some years time this will be serious for users. > But if you add "From the point of view of renumbering, these addresses > behave like RFC4941 addresses" the point is covered. ... behave like RFC4862 addresses. c

Re: 6MAN WG Last Call:

On 18/12/2012 14:13, Fernando Gont wrote: > On 12/18/2012 10:55 AM, Ole Troan wrote: > Nobody even suggested that. For instance, if these addresses had a > lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the > first place. I suggest that you add a discussion of

Re: 6MAN WG Last Call:

On 12/18/2012 10:55 AM, Ole Troan wrote: Nobody even suggested that. For instance, if these addresses had a lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the first place. >>> >>> I suggest that you add a discussion of site renumbering considerations. >>> The pr

Re: 6MAN WG Last Call:

>>> Nobody even suggested that. For instance, if these addresses had a >>> lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the >>> first place. >> >> I suggest that you add a discussion of site renumbering considerations. >> The problems described in draft-ietf-6renum-static-p

RE: 6MAN WG Last Call:

Hello, I have one question regarding this draft What is the main difference of your approach with RFC 3972 and 4941? As explained in section 3 of this draft, F() is a cryptography algorithm. In both ,privacy extension and RFC 3972 (if sec value is 0), discussed almost the same approach as you des

Re: 6MAN WG Last Call:

Thanks for the Review, On 2012-12-12 02:02, Joel M. Halpern wrote: > This (and the companion document draft-ietf-6man-udpzero) seem ready for > publication to me. > > I do have a minor questions. It is sufficiently minor that if necessary > it may be ignored so publication can proceed. > > I se

Re: 6MAN WG Last Call:

Bob and WG, This is no longer intended as an Informational RFC, it is supposed to be a Standards Track Applicability Statement. I have notified the ADs and the Chairs. But I would recommend everyone to please review this document as a Standards Track last call. Cheers Magnus On 2012-12-11 17:5

Re: 6MAN WG Last Call:

This (and the companion document draft-ietf-6man-udpzero) seem ready for publication to me. I do have a minor questions. It is sufficiently minor that if necessary it may be ignored so publication can proceed. I section 5, bullet 3 talks about "tunnel protocol will not significantly increas

Re: Re: 6MAN WG Last Call:

Ray, > Suggested text for Section 4.2 > > s/When the information from the DHCP server goes stale, the policy > received form the DHCP server should be removed and the default policy > should be restored./When the information from the DHCP server goes > stale, the policy received from the DHCP serv

RE: 6MAN WG Last Call:

List Subject: Re: 6MAN WG Last Call: Hemant, Thanks for your comments. On 9/9/12 2:43 PM, Hemant Singh (shemant) wrote: > I support this document - it's important work and the document is really > close to ship to the IESG. > > I thought this document should be on Standa

Re: 6MAN WG Last Call:

Tina, Thank you for your comments. Hi Erik and Igor, The draft is well explained in regards to the case when there is no alternative default router in the lest of default routers. I wanted some clarification in the content below: In the draft, The recommended behavior is to have 5 attempts,

Re: 6MAN WG Last Call:

Hemant, Thanks for your comments. On 9/9/12 2:43 PM, Hemant Singh (shemant) wrote: I support this document - it's important work and the document is really close to ship to the IESG. I thought this document should be on Standards Track but the document does not say anything about the Intende

Re: Re: 6MAN WG Last Call:

Tim Chown wrote: > On 22 Oct 2012, at 10:00, Arifumi Matsumoto wrote: > >> 2012/10/17 Ray Hunter : >>> It's really a question of if we need to further clarify what is meant by >>> "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt-06. >>> >>> Is it the manually configured node-spec

Re: 6MAN WG Last Call:

On 22 Oct 2012, at 10:00, Arifumi Matsumoto wrote: > > 2012/10/17 Ray Hunter : >> >> It's really a question of if we need to further clarify what is meant by >> "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt-06. >> >> Is it the manually configured node-specific default, or

Re: 6MAN WG Last Call:

On 22 Oct 2012, at 10:08, Arifumi Matsumoto wrote: > Brian, > > 2012/10/16 Brian E Carpenter : >> Hi, >> >> I support this draft but have a couple of comments. >> >>> A: Automatic Row Addition flag. This flag toggles the Automatic >>>Row Addition flag at client hosts, which is de

Re: 6MAN WG Last Call:

Brian, 2012/10/16 Brian E Carpenter : > Hi, > > I support this draft but have a couple of comments. > >>A: Automatic Row Addition flag. This flag toggles the Automatic >> Row Addition flag at client hosts, which is described in the >> section 2.1 in RFC 6724 [RFC6724]. If t

Re: 6MAN WG Last Call:

Hi, I received the following e-mail directly. Let me add Cc to the list. 2012/10/17 Ray Hunter : > inline. >> >> Arifumi Matsumoto >> 16 October 2012 10:53 >> >> Ray, >> thank you for review and comments. >> >> Responses below. >> >> 2012/10/10 Ray Hunter: >>> >>> I sup

Re: 6MAN WG Last Call:

This should be removed. Thanks. 2012/10/19 t.petch : > s.7 IANA considerations request the allocation of a code for > OPTION_ADDRSEL_ZONE > Is this the now removed > OPTION_ZONE_INDEX ? > If not, what? > > s.2 "POLICY TABLE OPITONS" > > Tom Petch > > > - Original Message - > From: "Ole Trø

Re: 6MAN WG Last Call:

s.7 IANA considerations request the allocation of a code for OPTION_ADDRSEL_ZONE Is this the now removed OPTION_ZONE_INDEX ? If not, what? s.2 "POLICY TABLE OPITONS" Tom Petch - Original Message - From: "Ole Trøan" To: Cc: <6man-cha...@tools.ietf.org> Sent: Wednesday, October 10, 2012

Re: 6MAN WG Last Call:

Hi, I support this draft but have a couple of comments. >A: Automatic Row Addition flag. This flag toggles the Automatic > Row Addition flag at client hosts, which is described in the > section 2.1 in RFC 6724 [RFC6724]. If this flag is set to 1, it > does not chan

Re: 6MAN WG Last Call:

Ray, thank you for review and comments. Responses below. 2012/10/10 Ray Hunter : > I support this work. > > Discussion > == > > Section 4.2 > s/the default policy should be restored/the previously active policy should > be restored/ ? It is assumed that the configuration will be either u

Re: 6MAN WG Last Call:

Hi, - Original Message - > From: Rui Paulo > To: "ipv6@ietf.org Mailing List" > Cc: > Sent: Wednesday, 10 October 2012 6:25 AM > Subject: Re: 6MAN WG Last Call: > > On 4 Oct 2012, at 14:53, Bob Hinden wrote: > >> All, >> >>

Re: 6MAN WG Last Call:

On 10 Oct 2012, at 01:28, Ole Trøan wrote: > This message starts a two week 6MAN Working Group on advancing: > > Title : Distributing Address Selection Policy using DHCPv6 > Author(s): A. Matsumoto, T. Fujisaki, T. Chown > Filename: draft-ietf-6man-addr-select-

Re: 6MAN WG Last Call:

I support this work. Discussion == Section 4.2 s/the default policy should be restored/the previously active policy should be restored/ ? Nits & clarification = Section 2 s/A address selection option contains/An Address Selection option contains/ s/Multiple policy table

Re: 6MAN WG Last Call:

On 4 Oct 2012, at 14:53, Bob Hinden wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Security Implications of the Use of IPv6 Extension > Headers with IPv6 Neighbor Discovery > Author(s) : Fernando Gont > Filename

Re: 6MAN WG Last Call:

On Oct 4, 2012, at 14:53 , Bob Hinden wrote: > > This message starts a two week 6MAN Working Group on advancing: > > Title : Security Implications of the Use of IPv6 Extension > Headers with IPv6 Neighbor Discovery > Author(s) : Fernando Gont > Filename

Re: 6MAN WG Last Call:

Support. Bob Hinden wrote: All, This message starts a two week 6MAN Working Group on advancing: Title : Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery Author(s) : Fernando Gont Filename: draft-ietf-6man-n

Re: 6MAN WG Last Call:

Here u go. Tina On Sep 13, 2012, at 9:58 PM, "Bob Hinden" wrote: > Tina, > > Please copy the w.g. mailing list when you comment on drafts in w.g. last > call. It's good that the whole working group sees the comments and > discussion. > > Thanks, > Bob > > On Sep 14, 2012, at 1:50 AM, Tina

RE: 6MAN WG Last Call:

Read and support. Thanks, Wes > -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Bob Hinden > Sent: Tuesday, September 04, 2012 1:28 PM > To: ipv6@ietf.org Mailing List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: > > All, > > This messag

RE: 6MAN WG Last Call:

I support this document - it's important work and the document is really close to ship to the IESG. I thought this document should be on Standards Track but the document does not say anything about the Intended Status of the document. Please fix that so that document includes Intended Status.

Re: 6MAN WG Last Call:

have read. support. randy IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

Re: 6MAN WG Last Call:

I think this is an important change, and I think our work on the problem side of the things underscores that. As a contributor I am in favor of advancing this document. That said I'd also like to hear from implementers that this is a reasonable fix with few if any negative consequences (someth

Re: 6MAN WG Last Call:

See inline On 2012-05-21 20:01, Marshall Eubanks wrote: > Dear Magnus; > > On Tue, May 8, 2012 at 3:29 AM, Magnus Westerlund > wrote: >> Hi, >> >> I know the WG last call has closed. But I reviewed it anyway and I have >> found some nits and things which the WG chairs anyway will stumble on in >

Re: 6MAN WG Last Call:

Dear Magnus; On Tue, May 8, 2012 at 3:29 AM, Magnus Westerlund wrote: > Hi, > > I know the WG last call has closed. But I reviewed it anyway and I have > found some nits and things which the WG chairs anyway will stumble on in > their ID checklist processing of the document. I also have some more

  1   2   3   >