From nobody Wed May 20 12:50:19 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214CA1A9045 for ; Wed, 20 May 2015 12:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSyP7MWzYGfW for ; Wed, 20 May 2015 12:50:11 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6221A9042 for ; Wed, 20 May 2015 12:50:11 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id A2171DA009C; Wed, 20 May 2015 19:50:10 +0000 (UTC) Received: from [10.0.20.182] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 20 May 2015 12:50:10 -0700 MIME-Version: 1.0 (1.0) From: Ted Lemon Content-Type: text/plain; charset="us-ascii" X-Mailer: iPad Mail (12F69) Message-ID: Date: Wed, 20 May 2015 15:50:08 -0400 Content-Transfer-Encoding: quoted-printable To: "" , "" X-Originating-IP: [71.233.43.215] Archived-At: Cc: draft-ietf-dhc-dhcpv6-active-leasequery@tools.ietf.org, Sheng Jiang Subject: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:50:17 -0000 I am an assigned INT directorate reviewer for draft-ietf-dhc-dhcpv6-active-l= easequery-02.txt. These comments were written primarily for the benefit of t= he Internet Area Directors. Document editors and shepherd(s) should treat t= hese comments just as they would treat comments from any other IETF contribu= tors and resolve them along with any other Last Call comments that have been= received. For more details on the INT Directorate, see: http://www.ietf.o= rg/iesg/directorate.html Major issues: The specification of TLS negotiation in section 8.2 allows for an MiTM attac= k: the man in the middle simply has to respond negatively to the STARTTLS me= ssage, and the communication will occur in the clear. This could be addres= sed by requiring that if the DHCP server is configured to use TLS, it will n= ot allow a connection to proceed without successfully completing the TLS han= dshake. In this case, an MiTM attack would simply prevent the connection f= rom completing. I guess this change would actually be made in section 9.1:= if the requestor doesn't request TLS, and the server is configured to requi= re it, then it will drop the connection. I don't think support for STARTTLS should be optional, hence handling cases w= here it is not supported should be unnecessary. Section 8.2 and 9.1 also do not talk about TLS cert validation, so it amount= s to opportunistic encryption, and is still subject to MiTM attacks since th= e attacker can simply use a different key than the DHCP server. To enable T= LS support to actually provide security, it would be necessary for the reque= stor to use a client cert that the server validates, and for the server to u= se a cert that the requestor validates. If the requestor's cert doesn't va= lidate, the connection is dropped; if the server's cert doesn't validate, th= e requestor drops the connection. In section 8.4, if the connection is terminated while an active leasequery i= s in the catch-up state, I don't think the current recommendation for sendin= g OPTION_LQ_BASE_TIME is adequate. In this case the requestor will likely h= ave to retry from the same starting time it had used previously. Minor issues: Section 2, definition for "Absolute Time", is the 32-bit quantity signed or u= nsigned? Definition for "binding change/update", aren't "DHCPv6 binding state" and "d= ata stored on the DHCPv6 server related to binding" synonyms? If so, perha= ps what you really need here is an additional definition for "DHCPv6 binding= state" which is "data stored on the DHCPv6 server relating to binding." I= don't think this is a big deal, but might be a nice edit for clarity. Similarly, why not split "catch-up information" and "catch-up phase" into tw= o separate definitions? Last paragraph of section 3 says "The messages sent by the server in respons= e to an Active Leasequery request SHOULD be identical to the messages sent b= y the server to a Bulk Leasequery request regarding the way the data is enco= ded into the Active Leasequery responses. In addition, the actions taken by= the Active Leasequery requestor to interpret the responses to an Active Lea= sequery request SHOULD be identical to the way that the requestor interprets= the responses to a Bulk Leasequery request." What is the purpose of the n= ormative SHOULDs here? Are there exceptional cases where this normative ad= vice would not be followed? Is this text really intended to be normative? Section 4 paragraph 2 says "applications which employ Active Leasequery ... w= ill usually use an initial Bulk Leasequery ..." What are the exceptions wh= ere this would not happen? Or is this just the flow you expect Leasequery r= equestors to follow, but they could just do an Active Leasequery starting at= T=3D0 or something? I don't think this is going to cause an interop probl= em, but for clarity it might be worth figuring out what you mean here by "us= ually." If you really just mean that this is how it is done, then you shou= ld probably say so more affirmatively. The organization of 6.2 is a bit odd: the first message is in 6.2, and subse= quent messages are in 6.2.1 and 6.2.2. This definitely isn't going to caus= e interop problems, but it might make the table of contents look nicer if yo= u put LEASEQUERY-REPLY in its own 6.2.x subhead. In section 9.4, why all the text about multiple queries over the same connec= tion? If the recommendation is to use two connections, why not just requir= e that? This seems like needless complexity. In 9.5, why does it make sense for the server to finish processing outstandi= ng requests _after_ it has determined that the requestor end of the connecti= on has been closed? If you mean that the requestor has shut down transmiss= ion but is still receiving, then wouldn't this mean for an active leasequery= that the server would continue sending updates indefinitely after that? In 10, I don't think you need to talk about SYN flood attacks: this is somet= hing that's typically dealt with in the stack. When you say that servers should restrict connections to certain requestors,= you don't say how those requestors are identified. I would suggest that y= ou use the client cert, or a local-CA-cert signing the client cert, as that m= echanism. Otherwise I think you're relying on IP addresses, which would be= a PITA to configure. Which I suppose means I'm suggesting that you not bo= ther with this other than for TLS-secured connections. Aside from this modest set of comments, LGTM! :) From nobody Tue May 26 12:23:55 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746221B3045; Tue, 26 May 2015 12:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh_FUlE36iC3; Tue, 26 May 2015 12:23:52 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662BC1B3048; Tue, 26 May 2015 12:23:49 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 449D6880F4; Tue, 26 May 2015 12:23:49 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8D42613682AA; Tue, 26 May 2015 12:23:48 -0700 (PDT) Message-ID: <5564C840.2070908@innovationslab.net> Date: Tue, 26 May 2015 15:23:44 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ted Lemon , "" , int-ads@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xFjfvRLaiHHR5AdlR2XkfxbaVEFxIvdim" Archived-At: Cc: draft-ietf-dhc-dhcpv6-active-leasequery@ietf.org, Sheng Jiang Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:23:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xFjfvRLaiHHR5AdlR2XkfxbaVEFxIvdim Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ted, Thanks for the review! Authors, I would like you to respond to these so that we can determine the best way forward. Regards, Brian On 5/20/15 3:50 PM, Ted Lemon wrote: > I am an assigned INT directorate reviewer for > draft-ietf-dhc-dhcpv6-active-leasequery-02.txt. These comments were > written primarily for the benefit of the Internet Area Directors. > Document editors and shepherd(s) should treat these comments just as > they would treat comments from any other IETF contributors and > resolve them along with any other Last Call comments that have been > received. For more details on the INT Directorate, see: > http://www.ietf.org/iesg/directorate.html >=20 > Major issues: >=20 > The specification of TLS negotiation in section 8.2 allows for an > MiTM attack: the man in the middle simply has to respond negatively > to the STARTTLS message, and the communication will occur in the > clear. This could be addressed by requiring that if the DHCP server > is configured to use TLS, it will not allow a connection to proceed > without successfully completing the TLS handshake. In this case, an > MiTM attack would simply prevent the connection from completing. I > guess this change would actually be made in section 9.1: if the > requestor doesn't request TLS, and the server is configured to > require it, then it will drop the connection. >=20 > I don't think support for STARTTLS should be optional, hence handling > cases where it is not supported should be unnecessary. >=20 > Section 8.2 and 9.1 also do not talk about TLS cert validation, so it > amounts to opportunistic encryption, and is still subject to MiTM > attacks since the attacker can simply use a different key than the > DHCP server. To enable TLS support to actually provide security, it > would be necessary for the requestor to use a client cert that the > server validates, and for the server to use a cert that the requestor > validates. If the requestor's cert doesn't validate, the connection > is dropped; if the server's cert doesn't validate, the requestor > drops the connection. >=20 > In section 8.4, if the connection is terminated while an active > leasequery is in the catch-up state, I don't think the current > recommendation for sending OPTION_LQ_BASE_TIME is adequate. In this > case the requestor will likely have to retry from the same starting > time it had used previously. >=20 > Minor issues: >=20 > Section 2, definition for "Absolute Time", is the 32-bit quantity > signed or unsigned? >=20 > Definition for "binding change/update", aren't "DHCPv6 binding state" > and "data stored on the DHCPv6 server related to binding" synonyms? > If so, perhaps what you really need here is an additional definition > for "DHCPv6 binding state" which is "data stored on the DHCPv6 server > relating to binding." I don't think this is a big deal, but might > be a nice edit for clarity. >=20 > Similarly, why not split "catch-up information" and "catch-up phase" > into two separate definitions? >=20 > Last paragraph of section 3 says "The messages sent by the server in > response to an Active Leasequery request SHOULD be identical to the > messages sent by the server to a Bulk Leasequery request regarding > the way the data is encoded into the Active Leasequery responses. In > addition, the actions taken by the Active Leasequery requestor to > interpret the responses to an Active Leasequery request SHOULD be > identical to the way that the requestor interprets the responses to a > Bulk Leasequery request." What is the purpose of the normative > SHOULDs here? Are there exceptional cases where this normative > advice would not be followed? Is this text really intended to be > normative? >=20 > Section 4 paragraph 2 says "applications which employ Active > Leasequery ... will usually use an initial Bulk Leasequery ..." > What are the exceptions where this would not happen? Or is this > just the flow you expect Leasequery requestors to follow, but they > could just do an Active Leasequery starting at T=3D0 or something? I > don't think this is going to cause an interop problem, but for > clarity it might be worth figuring out what you mean here by > "usually." If you really just mean that this is how it is done, > then you should probably say so more affirmatively. >=20 > The organization of 6.2 is a bit odd: the first message is in 6.2, > and subsequent messages are in 6.2.1 and 6.2.2. This definitely > isn't going to cause interop problems, but it might make the table of > contents look nicer if you put LEASEQUERY-REPLY in its own 6.2.x > subhead. >=20 > In section 9.4, why all the text about multiple queries over the same > connection? If the recommendation is to use two connections, why > not just require that? This seems like needless complexity. >=20 > In 9.5, why does it make sense for the server to finish processing > outstanding requests _after_ it has determined that the requestor end > of the connection has been closed? If you mean that the requestor > has shut down transmission but is still receiving, then wouldn't this > mean for an active leasequery that the server would continue sending > updates indefinitely after that? >=20 > In 10, I don't think you need to talk about SYN flood attacks: this > is something that's typically dealt with in the stack. >=20 > When you say that servers should restrict connections to certain > requestors, you don't say how those requestors are identified. I > would suggest that you use the client cert, or a local-CA-cert > signing the client cert, as that mechanism. Otherwise I think > you're relying on IP addresses, which would be a PITA to configure. > Which I suppose means I'm suggesting that you not bother with this > other than for TLS-secured connections. >=20 > Aside from this modest set of comments, LGTM! :) >=20 > _______________________________________________ Int-dir mailing list=20 > Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir >=20 --xFjfvRLaiHHR5AdlR2XkfxbaVEFxIvdim Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZMhAAAoJEBOZRqCi7goq6agIAMxme3eUsjJj86G465neA13F gImoNXyJGxCQ0HrxdEy7yBh75SD9W6X/4lLz+Dr9HEZYGjbM87EV1mDdhyQnTfLQ 8opfJD1tOd/8oTUzJKLy6h9vHLti5uLqezT4b9OrK0eHzwPN5p1XOzKmSNTPtA52 QdwRkhaV+8D6sgqnr3bL9depR0vqtuJktf+2X226fjhUSBNL/JsaNiNhN0omRjD3 HG+iBt6Eh73PqstwOsXrxlh36YG2tG7h6EKTb1VUOpnKg4LPOf99jtxscQJ1O/uU MfdyBpQLN/97GxtYsW/toDXQ+syvSw4tn0cAI6ROFYLgjLmqVf3ot8I0yOc4IaE= =QBTd -----END PGP SIGNATURE----- --xFjfvRLaiHHR5AdlR2XkfxbaVEFxIvdim-- From nobody Tue May 26 12:35:06 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E101ACE26; Tue, 26 May 2015 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVo2mXrcEypd; Tue, 26 May 2015 12:30:58 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB11B1ACDB7; Tue, 26 May 2015 12:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6454; q=dns/txt; s=iport; t=1432668659; x=1433878259; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nzWKnSQcQeNSuaCWHQUlPA7cuNdUeWQMpUgV2nmMU7I=; b=PsIJ8rHlvZO/VFP176yhVCvUPDZzpYGvI7APi2u+lFrpgS2dxqIIgrez 1eGfFxGG/pTwyBAAnOk4PPaRZDOGAhI1Uwg8uFORpDYXvO0W1BW6sraz6 wGANEABsEgFPeaIcrAzpekhBPLp+SIgDTgkRSsjaZTfcFrZdGRDzL7imS A=; X-IronPort-AV: E=Sophos;i="5.13,500,1427760000"; d="scan'208";a="515888538" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 26 May 2015 19:30:57 +0000 Received: from [161.44.70.131] ([161.44.70.131]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4QJUraV010906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 May 2015 19:30:54 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kim Kinnear In-Reply-To: <5564C840.2070908@innovationslab.net> Date: Tue, 26 May 2015 15:31:10 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5564C840.2070908@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1878.6) X-Authenticated-User: kkinnear Archived-At: X-Mailman-Approved-At: Tue, 26 May 2015 12:35:05 -0700 Cc: draft-ietf-dhc-dhcpv6-active-leasequery@ietf.org, int-ads@ietf.org, "" , Ted Lemon , Kim Kinnear , Sheng Jiang Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:31:01 -0000 Brian, We'll get back to you in a few days, after we have had a chance to digest and discuss these comments. Regards -- Kim On May 26, 2015, at 3:23 PM, Brian Haberman wrote: > Ted, > Thanks for the review! > > Authors, > I would like you to respond to these so that we can determine the > best way forward. > > Regards, > Brian > > > On 5/20/15 3:50 PM, Ted Lemon wrote: >> I am an assigned INT directorate reviewer for >> draft-ietf-dhc-dhcpv6-active-leasequery-02.txt. These comments were >> written primarily for the benefit of the Internet Area Directors. >> Document editors and shepherd(s) should treat these comments just as >> they would treat comments from any other IETF contributors and >> resolve them along with any other Last Call comments that have been >> received. For more details on the INT Directorate, see: >> http://www.ietf.org/iesg/directorate.html >> >> Major issues: >> >> The specification of TLS negotiation in section 8.2 allows for an >> MiTM attack: the man in the middle simply has to respond negatively >> to the STARTTLS message, and the communication will occur in the >> clear. This could be addressed by requiring that if the DHCP server >> is configured to use TLS, it will not allow a connection to proceed >> without successfully completing the TLS handshake. In this case, an >> MiTM attack would simply prevent the connection from completing. I >> guess this change would actually be made in section 9.1: if the >> requestor doesn't request TLS, and the server is configured to >> require it, then it will drop the connection. >> >> I don't think support for STARTTLS should be optional, hence handling >> cases where it is not supported should be unnecessary. >> >> Section 8.2 and 9.1 also do not talk about TLS cert validation, so it >> amounts to opportunistic encryption, and is still subject to MiTM >> attacks since the attacker can simply use a different key than the >> DHCP server. To enable TLS support to actually provide security, it >> would be necessary for the requestor to use a client cert that the >> server validates, and for the server to use a cert that the requestor >> validates. If the requestor's cert doesn't validate, the connection >> is dropped; if the server's cert doesn't validate, the requestor >> drops the connection. >> >> In section 8.4, if the connection is terminated while an active >> leasequery is in the catch-up state, I don't think the current >> recommendation for sending OPTION_LQ_BASE_TIME is adequate. In this >> case the requestor will likely have to retry from the same starting >> time it had used previously. >> >> Minor issues: >> >> Section 2, definition for "Absolute Time", is the 32-bit quantity >> signed or unsigned? >> >> Definition for "binding change/update", aren't "DHCPv6 binding state" >> and "data stored on the DHCPv6 server related to binding" synonyms? >> If so, perhaps what you really need here is an additional definition >> for "DHCPv6 binding state" which is "data stored on the DHCPv6 server >> relating to binding." I don't think this is a big deal, but might >> be a nice edit for clarity. >> >> Similarly, why not split "catch-up information" and "catch-up phase" >> into two separate definitions? >> >> Last paragraph of section 3 says "The messages sent by the server in >> response to an Active Leasequery request SHOULD be identical to the >> messages sent by the server to a Bulk Leasequery request regarding >> the way the data is encoded into the Active Leasequery responses. In >> addition, the actions taken by the Active Leasequery requestor to >> interpret the responses to an Active Leasequery request SHOULD be >> identical to the way that the requestor interprets the responses to a >> Bulk Leasequery request." What is the purpose of the normative >> SHOULDs here? Are there exceptional cases where this normative >> advice would not be followed? Is this text really intended to be >> normative? >> >> Section 4 paragraph 2 says "applications which employ Active >> Leasequery ... will usually use an initial Bulk Leasequery ..." >> What are the exceptions where this would not happen? Or is this >> just the flow you expect Leasequery requestors to follow, but they >> could just do an Active Leasequery starting at T=0 or something? I >> don't think this is going to cause an interop problem, but for >> clarity it might be worth figuring out what you mean here by >> "usually." If you really just mean that this is how it is done, >> then you should probably say so more affirmatively. >> >> The organization of 6.2 is a bit odd: the first message is in 6.2, >> and subsequent messages are in 6.2.1 and 6.2.2. This definitely >> isn't going to cause interop problems, but it might make the table of >> contents look nicer if you put LEASEQUERY-REPLY in its own 6.2.x >> subhead. >> >> In section 9.4, why all the text about multiple queries over the same >> connection? If the recommendation is to use two connections, why >> not just require that? This seems like needless complexity. >> >> In 9.5, why does it make sense for the server to finish processing >> outstanding requests _after_ it has determined that the requestor end >> of the connection has been closed? If you mean that the requestor >> has shut down transmission but is still receiving, then wouldn't this >> mean for an active leasequery that the server would continue sending >> updates indefinitely after that? >> >> In 10, I don't think you need to talk about SYN flood attacks: this >> is something that's typically dealt with in the stack. >> >> When you say that servers should restrict connections to certain >> requestors, you don't say how those requestors are identified. I >> would suggest that you use the client cert, or a local-CA-cert >> signing the client cert, as that mechanism. Otherwise I think >> you're relying on IP addresses, which would be a PITA to configure. >> Which I suppose means I'm suggesting that you not bother with this >> other than for TLS-secured connections. >> >> Aside from this modest set of comments, LGTM! :) >> >> _______________________________________________ Int-dir mailing list >> Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir >> > From nobody Thu May 28 09:12:27 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198CD1B2C07 for ; Thu, 28 May 2015 09:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPAmI2usnsPt for ; Thu, 28 May 2015 09:12:25 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293F41B2C0F for ; Thu, 28 May 2015 09:12:25 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 11E7D880F5 for ; Thu, 28 May 2015 09:12:25 -0700 (PDT) Received: from brians-mbp.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C84E613682AB for ; Thu, 28 May 2015 09:12:24 -0700 (PDT) Message-ID: <55673E64.8020406@innovationslab.net> Date: Thu, 28 May 2015 12:12:20 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "" Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eTJIuA5jNp6BuSeo987DNxpoDVroGFoRJ" Archived-At: Subject: [Int-dir] INT Dir review: draft-ietf-6tisch-architecture X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:12:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eTJIuA5jNp6BuSeo987DNxpoDVroGFoRJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Could I get one or two folks to review the 6tisch architecture document? https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ Regards, Brian --eTJIuA5jNp6BuSeo987DNxpoDVroGFoRJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZz5lAAoJEBOZRqCi7goqph4H/27/8LKykqNIYYuZQ1jkM5xy 90P3cHFztKzYXuAcIzPqUvsXYVAJCxzPwQ981NcC45xSc4He7e7zZU1yJ2R6yw+1 pIEoBJlVgo77G2a3jPfbrjK1Zejzl44CN3+FYIhZ7uQEDKTM3cGra+KRch52hKbU UdYq1VPbyXG5aPR6Gmi7axgHbKxNsvs5hENcUobNVNs6ahCG0Zd8vxAHEJq4UVPR y9hoJ1cScUT3MeUHm3lIoxXwYBsAmD/N44wel79XRlYXt9HEDceyVeIlcRvOkjee e8vYwI9J6CB/69flnwCcNeW8jL9ArSsX5ml2QDKyukedeyHlssztf4vSnGtZCq4= =iFCd -----END PGP SIGNATURE----- --eTJIuA5jNp6BuSeo987DNxpoDVroGFoRJ-- From nobody Thu May 28 10:53:41 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E21A1A40; Thu, 28 May 2015 10:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amK2M3LAQpv9; Thu, 28 May 2015 10:51:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF351A86E6; Thu, 28 May 2015 10:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12453; q=dns/txt; s=iport; t=1432835516; x=1434045116; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oX0o47Nit6mgzzI9W61YuJ/BrjXVeun9j9AdCn2W810=; b=cW53xPOZak5BjihPjVEVVW8Y0qLRi5qUuvCVj9kAYgKj9lSTwn3G/XyJ O3dGeZphlNzd1WLYc9dSuDIWeCWy9wV63mDmkQi3aUNKNTzDafvOKPa/M R7nXZKs1Qlb8xeVWUdDVHw7oZI4AE1NUc2lxHmyuf3A4bBE0Xm0B77oG6 o=; X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="scan'208";a="500597782" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 28 May 2015 17:51:54 +0000 Received: from [161.44.70.131] ([161.44.70.131]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4SHppnE021125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 May 2015 17:51:52 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Kim Kinnear In-Reply-To: <5564C840.2070908@innovationslab.net> Date: Thu, 28 May 2015 13:52:15 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> References: <5564C840.2070908@innovationslab.net> To: Brian Haberman , Ted Lemon X-Mailer: Apple Mail (2.1878.6) X-Authenticated-User: kkinnear Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 10:53:40 -0700 Cc: Sheng Jiang , "" , draft-ietf-dhc-dhcpv6-active-leasequery@ietf.org, int-ads@ietf.org, Kim Kinnear Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 17:52:00 -0000 Brian, Ted, Here are our comments regarding Ted's review, inline below... I believe that we need a new revision of the draft to include these changes (and the corresponding DHCPv4 draft, which has almost the same words in the same places). That said, I don't believe that any of this requires a new WGLC, as we aren't really changing the intent of what we were trying to say in any really significant way. The only substantive change is removing the multiple messages per connection, which *is* a change, but isn't a big deal in my view. I say this in part because nobody had any comments about that as we were working this with the DHC WG. I think the only person who cared was Bernie, and I've already checked with him and he's ok with it. But that's just my opinion... Regards -- Kim On May 26, 2015, at 3:23 PM, Brian Haberman wrote: > Ted, > Thanks for the review! > > Authors, > I would like you to respond to these so that we can determine the > best way forward. > > Regards, > Brian > > > On 5/20/15 3:50 PM, Ted Lemon wrote: >> I am an assigned INT directorate reviewer for >> draft-ietf-dhc-dhcpv6-active-leasequery-02.txt. These comments were >> written primarily for the benefit of the Internet Area Directors. >> Document editors and shepherd(s) should treat these comments just as >> they would treat comments from any other IETF contributors and >> resolve them along with any other Last Call comments that have been >> received. For more details on the INT Directorate, see: >> http://www.ietf.org/iesg/directorate.html >> >> Major issues: >> >> The specification of TLS negotiation in section 8.2 allows for an >> MiTM attack: the man in the middle simply has to respond negatively >> to the STARTTLS message, and the communication will occur in the >> clear. This was not what we were trying to say in the document. Ultimately, we expect that either the client or the server can be configured in one of three distinct ways regarding TLS: 1. Require TLS for all communication with the partner. 2. Support TLS if requested to do so by the partner, but allow communications in the clear if TLS is not requested by the partner. 3. Not support TLS at all. If the partner requires TLS, it won't be communicating with us. Period. The intent in section 8.2 for the client is that if the DHCP server doesn't want to support TLS for this connection, then the client will respond based on how it is configured. If it is configured as in #1, above, then it will not communicate with this server. If it is configured as in #2 then it will continue with communications in the clear. If the client was configured as in #3, it would not have sent the STARTTLS message. We will add words in section 8.2 to make that clearer. >> This could be addressed by requiring that if the DHCP server >> is configured to use TLS, it will not allow a connection to proceed >> without successfully completing the TLS handshake. That is what we were trying to say, though we have a slightly nuanced interpretation of "use TLS". Again, referring to the three configuration possibilities regarding TLS above: 1. Require TLS for all communication with the partner. 2. Support TLS if requested to do so by the partner, but allow communications in the clear if TLS is not requested by the partner. 3. Not support TLS at all. If the partner requires TLS, it won't be communicating with us. Period. If the server is configured as in #1, the server will do exactly what Ted is requesting: the server will not allow the connection to proceed without completing the TLS handshake. >> In this case, an >> MiTM attack would simply prevent the connection from completing. I >> guess this change would actually be made in section 9.1: if the >> requestor doesn't request TLS, and the server is configured to >> require it, then it will drop the connection. Yes, we will put some words in section 9.1 to make these three possibilities (and their implications) hopefully much clearer. >> >> I don't think support for STARTTLS should be optional, hence handling >> cases where it is not supported should be unnecessary. We never intended that the STARTTLS message support itself was to be optional, but I can see where it might look like it was. We will fix that. >> >> Section 8.2 and 9.1 also do not talk about TLS cert validation, so it >> amounts to opportunistic encryption, and is still subject to MiTM >> attacks since the attacker can simply use a different key than the >> DHCP server. To enable TLS support to actually provide security, it >> would be necessary for the requestor to use a client cert that the >> server validates, and for the server to use a cert that the requestor >> validates. If the requestor's cert doesn't validate, the connection >> is dropped; if the server's cert doesn't validate, the requestor >> drops the connection. Yes, and we left implicit our intent here, which was probably a mistake. We expect that a client or a server can be configured (or implemented directly) in one of two modes regarding TLS connections: a) Require TLS certificate validation (ensuring that you are talking to the partner to whom you believe you are talking to). b) Do not require TLS certificate validation (ensuring only that your conversation cannot be eavesdropped on, but not ensuring that you are talking to the correct partner). We will make explicit these two possibilities, and describe the downsides of (b). >> >> In section 8.4, if the connection is terminated while an active >> leasequery is in the catch-up state, I don't think the current >> recommendation for sending OPTION_LQ_BASE_TIME is adequate. In this >> case the requestor will likely have to retry from the same starting >> time it had used previously. Yes, we completely agree! I'm delighted that you got it! Unfortunately, We think we said this explicitly at least three times, including: > > Prior to the completion of the > catch-up phase, if the connection should go away or if the requestor > receives a LEASEQUERY-DONE message, then when it reconnects it MUST > use the base-time value from the previous connection and not any > base-time value received from the recently closed connection. and: > Therefore, until > the catch-up phase is complete, the latest base-time value received > from a DHCPv6 server processing an Active Leasequery request cannot > be reset from the incoming messages (and used in a subsequent Active > Leasequery's query-start-time option), because to do so would > compromise the ability to recover lost information if the Active > Leasequery were to terminate prior to the completion of the catch-up > phase. and: > The updates sent by the DHCPv6 server during the catch-up phase are > not in the order that the lease state data was updated. Therefore, > the OPTION_LQ_BASE_TIME option from messages during this phase MUST > NOT be saved and used to compute the subsequent ACTIVELEASEQUERY > message's OPTION_LQ_START_TIME option. so ... either I don't understand your concern, or we are really not able to communicate this information in a way that makes any sense. >> >> Minor issues: >> >> Section 2, definition for "Absolute Time", is the 32-bit quantity >> signed or unsigned? Good catch, unsigned is the DHCPv6 approach, which is from RFC 3315: > The time value is the time that the DUID is > generated represented in seconds since midnight (UTC), January 1, > 2000, modulo 2^32. >> Definition for "binding change/update", aren't "DHCPv6 binding state" >> and "data stored on the DHCPv6 server related to binding" synonyms? >> If so, perhaps what you really need here is an additional definition >> for "DHCPv6 binding state" which is "data stored on the DHCPv6 server >> relating to binding." I don't think this is a big deal, but might >> be a nice edit for clarity. Sure, no problem. >> >> Similarly, why not split "catch-up information" and "catch-up phase" >> into two separate definitions? Ok, sure. >> >> Last paragraph of section 3 says "The messages sent by the server in >> response to an Active Leasequery request SHOULD be identical to the >> messages sent by the server to a Bulk Leasequery request regarding >> the way the data is encoded into the Active Leasequery responses. In >> addition, the actions taken by the Active Leasequery requestor to >> interpret the responses to an Active Leasequery request SHOULD be >> identical to the way that the requestor interprets the responses to a >> Bulk Leasequery request." What is the purpose of the normative >> SHOULDs here? Are there exceptional cases where this normative >> advice would not be followed? Is this text really intended to be >> normative? Somehow I'm always kind of iffy when it comes to the difference between SHOULD and should. MUST and must, I've got that, but SHOULD and should -- they challenge me. In this case, SHOULD seemed stronger than should, which I wanted, but I wasn't up for MUST since I think that there might be exceptions of which I am unaware and I didn't want to needlessly constrain folks. I'll drop the normative language and just say "should" and move on here. >> >> Section 4 paragraph 2 says "applications which employ Active >> Leasequery ... will usually use an initial Bulk Leasequery ..." >> What are the exceptions where this would not happen? Or is this >> just the flow you expect Leasequery requestors to follow, but they >> could just do an Active Leasequery starting at T=0 or something? I >> don't think this is going to cause an interop problem, but for >> clarity it might be worth figuring out what you mean here by >> "usually." If you really just mean that this is how it is done, >> then you should probably say so more affirmatively. Ok, we'll be more affirmative, but not normative. >> >> The organization of 6.2 is a bit odd: the first message is in 6.2, >> and subsequent messages are in 6.2.1 and 6.2.2. This definitely >> isn't going to cause interop problems, but it might make the table of >> contents look nicer if you put LEASEQUERY-REPLY in its own 6.2.x >> subhead. We did it this way because we are not defining a new message in 6.2 -- LEASEQUERY-REPLY is already defined in RFC5007. But we'll put that paragraph in its own section since you feel it will be clearer. >> >> In section 9.4, why all the text about multiple queries over the same >> connection? If the recommendation is to use two connections, why >> not just require that? This seems like needless complexity. Ok, we'll take it out. One connection per query. >> >> In 9.5, why does it make sense for the server to finish processing >> outstanding requests _after_ it has determined that the requestor end >> of the connection has been closed? If you mean that the requestor >> has shut down transmission but is still receiving, then wouldn't this >> mean for an active leasequery that the server would continue sending >> updates indefinitely after that? Hmmm. Well, yes, I suppose that it does. I'll remove that last sentence. >> >> In 10, I don't think you need to talk about SYN flood attacks: this >> is something that's typically dealt with in the stack. Always happy to remove stuff. Its gone! >> >> When you say that servers should restrict connections to certain >> requestors, you don't say how those requestors are identified. I >> would suggest that you use the client cert, or a local-CA-cert >> signing the client cert, as that mechanism. Otherwise I think >> you're relying on IP addresses, which would be a PITA to configure. >> Which I suppose means I'm suggesting that you not bother with this >> other than for TLS-secured connections. Ok, we'll take that out too. >> >> Aside from this modest set of comments, LGTM! :) >> >> _______________________________________________ Int-dir mailing list >> Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir >> > From nobody Fri May 29 05:06:11 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8381A036B; Fri, 29 May 2015 05:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsPGY0orrTyA; Fri, 29 May 2015 05:06:09 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2BA1A0368; Fri, 29 May 2015 05:06:09 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 881D1DA0085; Fri, 29 May 2015 12:06:08 +0000 (UTC) Received: from [10.0.20.186] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 29 May 2015 05:06:08 -0700 References: <5564C840.2070908@innovationslab.net> <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> MIME-Version: 1.0 (1.0) In-Reply-To: <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <5922EB55-A078-432C-A151-E416671B99AE@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Fri, 29 May 2015 08:06:07 -0400 To: Kim Kinnear X-Originating-IP: [71.233.43.215] Archived-At: Cc: Brian Haberman , "" , "" , "" , Ted Lemon , Sheng Jiang Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 12:06:10 -0000 On May 28, 2015, at 1:52 PM, Kim Kinnear wrote: > 2. Support TLS if requested to do so by the partner, but allow > communications in the clear if TLS is not requested by the > partner. This is what I am objecting to. The only time it makes sense to use TLS is i= f there is a risk of confidential data being snooped. If such a risk exists,= then you can't allow the client to negotiate no TLS, because in so doing it= will be exposing the confidential data. So if the server is configured to d= o TLS, it's not okay for the client to insist on operating in the clear. Th= is is equivalent to the SMTP STARTTLS vulnerability that made the news about= a month ago.=20 If you have clients that do not support TLS, then the server should just be c= onfigured not to use TLS. But personally I think you should just make TLS MT= I. That way the server administrator has the freedom to configure it or not,= without worrying about downgrade attacks. Back in the day we might have tho= ught that making TLS MTI was too much to ask, but I don't think it is anymor= e.=20= From nobody Fri May 29 05:14:22 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DC81A03F9; Fri, 29 May 2015 05:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3YQmsQJUgTt; Fri, 29 May 2015 05:14:20 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AE81A0397; Fri, 29 May 2015 05:14:20 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id E332FDA0085; Fri, 29 May 2015 12:14:19 +0000 (UTC) Received: from [10.0.20.186] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 29 May 2015 05:14:13 -0700 References: <5564C840.2070908@innovationslab.net> <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> MIME-Version: 1.0 (1.0) In-Reply-To: <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Fri, 29 May 2015 08:14:13 -0400 To: Kim Kinnear X-Originating-IP: [71.233.43.215] Archived-At: Cc: Brian Haberman , "" , "" , "" , Ted Lemon , Sheng Jiang Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 12:14:21 -0000 On May 28, 2015, at 1:52 PM, Kim Kinnear wrote: >=20 > b) Do not require TLS certificate validation (ensuring only > that your conversation cannot be eavesdropped on, but not > ensuring that you are talking to the correct partner). This ensures that your conversation can only be intercepted by an active att= ack, not a passive attack. A man in the middle can still eavesdrop. I wonde= r if there's some security area document you could refer to that explains th= e options here. What I said in my review is a lot more detailed and nuanced t= han you're repeating back to me, and while I'm sympathetic to the desire to k= eep it simple, I think the text change you've proposed is arguably too simpl= e, because it advocates for only one of the use cases I described in my comm= ent. I think the most useful mode of operation here is the one you are leaving ou= t. Nobody wants to pay a CA to sign certs for all their infrastructure serve= rs, but having a local CA and just installing the local CA as a trusted root= would work fine for this application; indeed you probably don't want to con= figure leasequery partners to accept the standard set of CA roots.=20= From nobody Fri May 29 05:16:17 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C11A0397; Fri, 29 May 2015 05:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1z40TPpoI-4; Fri, 29 May 2015 05:16:15 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB491A0383; Fri, 29 May 2015 05:16:15 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 04949DA0085; Fri, 29 May 2015 12:16:15 +0000 (UTC) Received: from [10.0.20.186] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 29 May 2015 05:16:14 -0700 References: <5564C840.2070908@innovationslab.net> <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> MIME-Version: 1.0 (1.0) In-Reply-To: <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Fri, 29 May 2015 08:16:14 -0400 To: Kim Kinnear X-Originating-IP: [71.233.43.215] Archived-At: Cc: Brian Haberman , "" , "" , "" , Ted Lemon , Sheng Jiang Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 12:16:16 -0000 On May 28, 2015, at 1:52 PM, Kim Kinnear wrote: >> Prior to the completion of the >> catch-up phase, if the connection should go away or if the requestor >> receives a LEASEQUERY-DONE message, then when it reconnects it MUST >> use the base-time value from the previous connection and not any >> base-time value received from the recently closed connection. I did indeed miss this. Glad to see it's accounted for! From nobody Fri May 29 05:21:07 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2D51A1A73; Fri, 29 May 2015 05:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRGIfGLoosbR; Fri, 29 May 2015 05:21:04 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9803E1A049A; Fri, 29 May 2015 05:20:58 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 82D12DA0085; Fri, 29 May 2015 12:20:58 +0000 (UTC) Received: from [10.0.20.186] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 29 May 2015 05:20:51 -0700 References: <5564C840.2070908@innovationslab.net> <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> MIME-Version: 1.0 (1.0) In-Reply-To: <9B1081A5-A515-4606-B9F3-4656D474D834@cisco.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <6748CD02-EF8C-4FAA-9C9E-C74190DCD743@nominum.com> X-Mailer: iPad Mail (12F69) From: Ted Lemon Date: Fri, 29 May 2015 08:20:51 -0400 To: Kim Kinnear X-Originating-IP: [71.233.43.215] Archived-At: Cc: Brian Haberman , "" , "" , "" , Ted Lemon , Sheng Jiang Subject: Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 12:21:05 -0000 Thanks for the quick response to my comments! Sorry for replying with a flu= rry of messages=E2=80=94I'm still doing email on my iPad, so long replies ar= e difficult.=20= From nobody Fri May 29 09:51:09 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEE41A8BBE for ; Fri, 29 May 2015 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD7bYPjgo_iH for ; Fri, 29 May 2015 09:51:05 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030EE1A89A7 for ; Fri, 29 May 2015 09:51:05 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so19027484igb.0 for ; Fri, 29 May 2015 09:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EQDkNRsma4Yfh5gvRQNWcxrHjeXvPbpFnIDkf1maVt8=; b=QGXPzxcDD+AsD9prHws4ayTku+AsnLpzzJH9kx8Byqf3gg7+z36WuPY/IszmJH8qvL ttJZLlnVhpmVweVNu62yc0cCvH9vIyN+MMmls9JuqAfH6g1QCEFHvfGo1IpadAp3Gf0b 2aUd74SlYvckHhV1QSCfNq1okecdBXO8uh0W4fItsZUKRrCD2i4+6Vi/3k2ca3R8bqXy bkDEYHaarsdCydirbokWW2mR+yo/1m8BDsKcScX0r/uO+X8Gp5/w1FTY6Yu/j5judTPm pRjEEf1Ye9N0f9mIRoz6DyGq3Yz5qopN++VUaFGoSM7Pe25DOmwIhL3im2gX5tJqUNqE k7ng== MIME-Version: 1.0 X-Received: by 10.50.30.138 with SMTP id s10mr5203096igh.3.1432918264551; Fri, 29 May 2015 09:51:04 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.50.80 with HTTP; Fri, 29 May 2015 09:51:04 -0700 (PDT) In-Reply-To: <55673E64.8020406@innovationslab.net> References: <55673E64.8020406@innovationslab.net> Date: Fri, 29 May 2015 09:51:04 -0700 X-Google-Sender-Auth: H2b-grxrGrsvhg2yl4eY27cee3g Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Brian Haberman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [Int-dir] INT Dir review: draft-ietf-6tisch-architecture X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 16:51:06 -0000 At Thu, 28 May 2015 12:12:20 -0400, Brian Haberman wrote: > Could I get one or two folks to review the 6tisch architecture document? > > https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ I'm not familiar with topics specific to low-power networks, but if there's no other volunteer I'll try to review it to see if I can provide any useful feedback. (If someone familiar with this area already volunteered off-list, I'd simply let that person(s) review it). -- JINMEI, Tatuya From nobody Fri May 29 10:19:34 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D386B1A1A75 for ; Fri, 29 May 2015 10:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K71u5CYBvvmg for ; Fri, 29 May 2015 10:19:31 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F0A1ACE8E for ; Fri, 29 May 2015 10:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1432919882; x=1434129482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rmiQuINOveTm4m144YnunAxTQlLMprjT++HrEE4Z4Ro=; b=cIcxjeBpBmmEmxdAFZf2PsRaq76HsTxKBh6LgMcLwE4Rjr0fgo1OqPMr QRy8ExIXnlLDPSacPFfXxuoiBJtuhMSG5/wMzab8a4AOkF/u+QIsZ5GW2 W1urZN72LFxCTptNhKfh6YQHrrANtG2OhK9fNMX/hxqqDP31PiQw32VG+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AwAsnmhV/4cNJK1cgxBUXgaDGLsICYFQCoV3AoFHOBQBAQEBAQEBgQqEIgEBAQMBAQEBHgFMCwUHBAIBCBEBAwEBAgMGHQIDAicLFAMGCAIEAQ0FCIgdCA2UD50UAaQBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBHoolhDceMQcGgl8ygRYBBJMKhDWIBoNxkhgjYYMXb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,518,1427760000"; d="scan'208";a="154614072" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2015 17:18:02 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4THI1Uw012946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 17:18:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.169]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 29 May 2015 12:18:01 -0500 From: "Bernie Volz (volz)" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Brian Haberman Thread-Topic: [Int-dir] INT Dir review: draft-ietf-6tisch-architecture Thread-Index: AQHQmi+m+yE6qpLSZUumUzfCiCPbuJ2TMc0g Date: Fri, 29 May 2015 17:18:00 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CAF99A0@xmb-rcd-x04.cisco.com> References: <55673E64.8020406@innovationslab.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.1.200] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [Int-dir] INT Dir review: draft-ietf-6tisch-architecture X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:19:33 -0000 Hi: I've assigned Ralph and Sheng to do the review; Ralph agreed to do it. I ha= ven't heard from Sheng. Give Sheng a few more days, and if I don't hear from him by Monday, I can a= ssign you. FYI - You are always free to review any document, so if you have an interes= t please proceed whether assigned or not. The more eyes, the better. - Bernie -----Original Message----- From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of ???? Sent: Friday, May 29, 2015 12:51 PM To: Brian Haberman Cc: Subject: Re: [Int-dir] INT Dir review: draft-ietf-6tisch-architecture At Thu, 28 May 2015 12:12:20 -0400, Brian Haberman wrote: > Could I get one or two folks to review the 6tisch architecture document? > > https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ I'm not familiar with topics specific to low-power networks, but if there's= no other volunteer I'll try to review it to see if I can provide any usefu= l feedback. (If someone familiar with this area already volunteered off-li= st, I'd simply let that person(s) review it). -- JINMEI, Tatuya _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir From nobody Fri May 29 13:17:51 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C761A8740 for ; Fri, 29 May 2015 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9dpH5qwXlCR for ; Fri, 29 May 2015 13:17:49 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCB21A1B78 for ; Fri, 29 May 2015 13:17:49 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so71492551iec.1 for ; Fri, 29 May 2015 13:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DIslNT9lDuFfSPqc1k1pi/lM+WSA5rlZc3pC5hMJYwo=; b=OVY4KgBVJRfNCnJoDk9SSPI2SKSu+gJBfuBLMdNdBfr/PBJpRhs+AWAq9ivJzZwwmF 5RaR8q/Hw3OAiFOH5wNJiCni5bmoeEMO4j6TxZnkmfhOWi9XngIuqlhauVn1mst6tcXy IYTC0uX5IweYjHKAInsAUm0wkWZX0i0n+mBOp6qZkGwvZ/1/o603SXv+iuxE5zbg4PP4 su/Djw/OxSrAd7ZqpsUD0GftcaCDWDcy0MahDGxYPnzlfSnMMQXjgUGCe0PvyZwsKIQy iPygdzAdVeLvwRZmsSZYHUiMF2hq3D9vSdf/2YOszPbwxpx+cVLeV2M5h85/PcD7CDbi p4hA== MIME-Version: 1.0 X-Received: by 10.107.155.81 with SMTP id d78mr12341935ioe.29.1432930669220; Fri, 29 May 2015 13:17:49 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.50.80 with HTTP; Fri, 29 May 2015 13:17:49 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CAF99A0@xmb-rcd-x04.cisco.com> References: <55673E64.8020406@innovationslab.net> <489D13FBFA9B3E41812EA89F188F018E1CAF99A0@xmb-rcd-x04.cisco.com> Date: Fri, 29 May 2015 13:17:49 -0700 X-Google-Sender-Auth: Sm5P1yzpEoiS4MlqnZ9e8Gnz1r4 Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Haberman , "" Subject: Re: [Int-dir] INT Dir review: draft-ietf-6tisch-architecture X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 20:17:50 -0000 At Fri, 29 May 2015 17:18:00 +0000, "Bernie Volz (volz)" wrote: > I've assigned Ralph and Sheng to do the review; Ralph agreed to do it. I haven't heard from Sheng. > > Give Sheng a few more days, and if I don't hear from him by Monday, I can assign you. Ah, okay. In that case I'll just hold off until/unless I'm explicitly asked for a review. -- JINMEI, Tatuya