From nobody Mon Nov 2 21:24:43 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 82E0E1B2C88; Mon, 2 Nov 2015 19:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=0.001, 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 9RRF-C44ofiQ; Mon, 2 Nov 2015 19:54:25 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 BFA141B2C7B; Mon, 2 Nov 2015 19:54:24 -0800 (PST) Received: by wmec75 with SMTP id c75so76197027wme.1; Mon, 02 Nov 2015 19:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cvtt14+4rZKh0/IbPgNHhiaa3GuSiEZZR+D/65m4FOo=; b=GacYSxwqGLXZkwlSQ3dZLuFs8ZIZtg43WzqApiFqQNhCVIbvVptzbmVs8vZr1fpYYW lFRF+ouy25RjBafLuARmYBVWQ3W3baD5UjFBRpwaiUi6g53LW3AaStGmrpAPkeZejfuE DEQZJzD3cxauP/JgX533T9YGQhfIkFn8bfDy5vCI8o6CZjkF0wDpgaTnhcI6B8lby8rB 1lEYAZspkdvrgjyerz20vwNUQQaHq5uPJ3fbSzhKInKBkMx7ncH9hZuqNmu4X3wk//sp dOqhBZ6Ua5aLbsZm8QUAGUM1+/PWkvUJcutzdg41QWjWFxCMdSvb5CU4WRhw29x7KDOA QKGg== X-Received: by 10.28.18.194 with SMTP id 185mr15986773wms.44.1446522863212; Mon, 02 Nov 2015 19:54:23 -0800 (PST) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.27.136.198 with HTTP; Mon, 2 Nov 2015 19:54:03 -0800 (PST) In-Reply-To: References: From: Thomas Watteyne Date: Tue, 3 Nov 2015 12:54:03 +0900 X-Google-Sender-Auth: RWltU2dbrUMrsiGaFIdWnMi5rCU Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a11469f6a6be15105239ad903 Archived-At: X-Mailman-Approved-At: Mon, 02 Nov 2015 21:24:42 -0800 Cc: "draft-ietf-6tisch-minimal.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT DIR review of draft-ietf-6tisch-minimal-12.txt 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, 03 Nov 2015 03:54:26 -0000 --001a11469f6a6be15105239ad903 Content-Type: text/plain; charset=UTF-8 Suresh, A quick note to thank you for the detailed review! We have been discussing your comments with the editors of the draft, and will come back with a response. I assume you have no problem with us discussing your comments on the 6TiSCH ML and/or during the 6TiSCH WG meeting in Yokohama. Please let me konw if you do. Thomas On Thu, Oct 22, 2015 at 1:01 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > I am an assigned INT directorate reviewer for > . These comments were written primarily > for > the benefit of the Internet Area Directors. Document editors and > shepherd(s) > should treat these comments just like 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. > > Summary: The draft is almost ready for publication but I have two comments > that you may want to address. > > Major > ===== > > * Intended Status: > > This looks more like a recommended set of network configuration parameters > than a new protocol definition. Has the wg considered whether the Proposed > Standard status is appropriate (as opposed to Info or BCP)? > > * Section 10.1.1 > > I have a question about the Sp computation. Looks like the Sp value needs > to > be between 1 and 9. In my view, the recommended method (3*ETX)-2 yields > values between 1 and 10. This needs to be fixed. > > This is how I see it. > > On a very high quality link, if there are no retransmissions required ETX > will be 1/1 => 1. Sp will be (3*1)-2 => 1 > > On a very poor quality link where the packet only gets through after the > full > 3 retries ETX will be 4/1 => 4. Sp will be (3*4)-2 => 10. > > Is my calculation correct? > > Editorial > ========= > > Section 3.2 > > s/maintin/maintain/ > > Section 3.3 > > s/if none is/if none are/ > > Thanks > Suresh > --001a11469f6a6be15105239ad903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suresh,
A quick note to thank you for the detailed rev= iew!
We have been discussing your comments with the editors of th= e draft, and will come back with a response.
I assume you hav= e no problem with us discussing your comments on the 6TiSCH ML and/or durin= g the 6TiSCH WG meeting in Yokohama. Please let me konw if you do.
Thomas

On Thu, Oct 22, 2015 at 1:01 PM, Suresh Krishnan <<= a href=3D"mailto:suresh.krishnan@ericsson.com" target=3D"_blank">suresh.kri= shnan@ericsson.com> wrote:
= I am an assigned INT directorate reviewer for
<draft-ietf-6tisch-minimal-12.txt>. These comments were written prima= rily for
the benefit of the Internet Area Directors. Document editors and shepherd(s= )
should treat these comments just like 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,<= br> see http://www.ietf.org/iesg/directorate.html.

Summary: The draft is almost ready for publication but I have two comments<= br> that you may want to address.

Major
=3D=3D=3D=3D=3D

* Intended Status:

This looks more like a recommended set of network configuration parameters<= br> than a new protocol definition. Has the wg considered whether the Proposed<= br> Standard status is appropriate (as opposed to Info or BCP)?

* Section 10.1.1

I have a question about the Sp computation. Looks like the Sp value needs t= o
be between 1 and 9. In my view, the recommended method (3*ETX)-2 yields
values between 1 and 10. This needs to be fixed.

This is how I see it.

On a very high quality link, if there are no retransmissions required ETX will be 1/1 =3D> 1. Sp will be (3*1)-2 =3D> 1

On a very poor quality link where the packet only gets through after the fu= ll
3 retries ETX will be 4/1 =3D> 4. Sp will be (3*4)-2 =3D> 10.

Is my calculation correct?

Editorial
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Section 3.2

s/maintin/maintain/

Section 3.3

s/if none is/if none are/

Thanks
Suresh

--001a11469f6a6be15105239ad903-- From nobody Mon Nov 2 22:33:01 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 CA6A51B2CBA for ; Mon, 2 Nov 2015 22:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 JnKlV7aH7JsX for ; Mon, 2 Nov 2015 22:32:58 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4CF1B2BC7 for ; Mon, 2 Nov 2015 22:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6439; q=dns/txt; s=iport; t=1446532378; x=1447741978; h=from:to:subject:date:message-id:mime-version; bh=ZDZcFqa7claC9wm7kkFE3jvDHwglco9QLGRfoztv3yA=; b=I2lsC6Vao3QavBS7XqAvJs5ExemyCpllu0rzQ+kIw9heJz7k6a+tEBfB vmPyj/SlU+iLE7mbLqjmjhX972APa/wBdor3DOnHYe2G5Kg1Z3bPbuD5+ Neq/JK2vW57qOyuky+ol+BHaohV27YiRwfpqsRpugKkNeGVkWuAqXE5vh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQD9UzhW/4YNJK1egm5NU28Grl6QZ?= =?us-ascii?q?QENgVohhXiBMjgUAQEBAQEBAYEKhDwtXgE1SyYBBBuIKA2gNaB0AQEBAQEBBAE?= =?us-ascii?q?BAQEBAQEci3WCGoJxEoQjBZZDAYUciAGBYEiDd4hKjVgBHwEBQoQEcgGEdoEHA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.20,237,1444694400"; d="scan'208,217";a="203892574" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Nov 2015 06:32:57 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tA36WvSh030621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Nov 2015 06:32:57 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 00:32:56 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 00:32:56 -0600 From: "Bernie Volz (volz)" To: "" Thread-Topic: FYI - Some changes - tooling Thread-Index: AdEWAXPeCoOe53DLT8qnU2Qls5D8vw== Date: Tue, 3 Nov 2015 06:32:56 +0000 Message-ID: <46d76c4d1228496db40a55077820db20@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.41] Content-Type: multipart/alternative; boundary="_000_46d76c4d1228496db40a55077820db20XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Int-dir] FYI - Some changes - tooling 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, 03 Nov 2015 06:33:00 -0000 --_000_46d76c4d1228496db40a55077820db20XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: We are looking into setting up tooling for Int Area Directorate reviews (us= ing the gen-art tooling). If you do receive some odd emails from the tool (likely related to account = set up), please ignore them for now. Once we've set up the tool and are ready to go, we'll send out more details= (some of you may already be using these tools if involved in some of the o= ther directorates, such as Gen-Art). Note also that a new tool should be developed in the future (see https://to= ols.ietf.org/html/draft-sparks-genarea-review-tracker) to replace the curre= nt arts.tools.ietf.org. - Bernie --_000_46d76c4d1228496db40a55077820db20XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

We are looking into setting up tooling for Int Area = Directorate reviews (using the gen-art tooling).

 

If you do receive some odd emails from the tool (lik= ely related to account set up), please ignore them for now.

 

Once we’ve set up the tool and are ready to go= , we’ll send out more details (some of you may already be using these= tools if involved in some of the other directorates, such as Gen-Art).

 

Note also that a new tool should be developed in the= future (see https://tools.ietf.org/html/draft-sparks-genarea-review-tracker) to re= place the current arts.tools.ietf.org.

 

-     &= nbsp;    Bernie

--_000_46d76c4d1228496db40a55077820db20XCHALN003ciscocom_-- From nobody Tue Nov 3 01:11:13 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 8B9971B3083; Tue, 3 Nov 2015 01:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 eb5JJ3EZJLoq; Tue, 3 Nov 2015 01:11:09 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331201B306D; Tue, 3 Nov 2015 01:11:09 -0800 (PST) X-AuditID: c6180641-f792c6d00000686a-f0-56380ccb28d3 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8F.FD.26730.BCC08365; Tue, 3 Nov 2015 02:24:28 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 04:11:07 -0500 From: Suresh Krishnan To: Thomas Watteyne Thread-Topic: INT DIR review of draft-ietf-6tisch-minimal-12.txt Thread-Index: AdEMflKoUczlhpT5TGOloxikuM9L1A== Date: Tue, 3 Nov 2015 09:11:07 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPgu4ZHoswg8P9TBaHZ8xltnh0pZvF YvaLTcwOzB6HO76weyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PAvE7Ggi+iFbtWbWZuYHwq0MXI ySEhYCKx8cw5VghbTOLCvfVsILaQwBFGiVtLvLoYuYDsZYwSz168ZARJsAE1bNj5mQnEFhEw kGi4NJUFpIhZoIFRYt2DqWCThAXsJdZt3cMGUeQgce3pbRYIW0/izJxXYDUsAioStw5tArI5 OHgFfCX+/5SBWDaFUWL3lbXsIDWMQBd9P7UGbBmzgLjErSfzmSAuFZBYsuc8M4QtKvHy8T+o D5Qk5ry+xgxRryOxYPcnNghbW2LZwtdgcV4BQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUV I0dpcWpZbrqR4SZGYGQck2Bz3MG44JPlIUYBDkYlHl4DJ/MwIdbEsuLK3EOMEhzMSiK8BYEW YUK8KYmVValF+fFFpTmpxYcYpTlYlMR55824HyokkJ5YkpqdmlqQWgSTZeLglAKG59S8/6m/ juxzXCnZ+KiGxXbtwv2bQ+R6rs2MS889Zzyv9sFW1dnuH+f2LFmkYD99rq3XsVYH1sVidUY+ qtv3vy+Pim00d5tk9vXGdjUN4d6vc04ppvBKvDmzP2nvx9ed/XnfP8/Pup0Xxvbs4QSOmBWn 0i7+CTvz6/xK2z3vGXx3zUo2MTMKV2Ipzkg01GIuKk4EAI+TipeIAgAA Archived-At: Cc: "draft-ietf-6tisch-minimal.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT DIR review of draft-ietf-6tisch-minimal-12.txt 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, 03 Nov 2015 09:11:11 -0000 Hi Thomas,=0A= Thanks for your response. I have no issue with you sharing the comments = on =0A= the 6tisch mailing list. I will look forward to your response.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 11/03/2015 12:54 PM, Thomas Watteyne wrote:=0A= > Suresh,=0A= > A quick note to thank you for the detailed review!=0A= > We have been discussing your comments with the editors of the draft, and = will=0A= > come back with a response.=0A= > I assume you have no problem with us discussing your comments on the 6TiS= CH=0A= > ML and/or during the 6TiSCH WG meeting in Yokohama. Please let me konw if= you do.=0A= > Thomas=0A= >=0A= > On Thu, Oct 22, 2015 at 1:01 PM, Suresh Krishnan=0A= > > wrot= e:=0A= >=0A= > I am an assigned INT directorate reviewer for=0A= > . These comments were written prima= rily for=0A= > the benefit of the Internet Area Directors. Document editors and shep= herd(s)=0A= > should treat these comments just like they would treat comments from = any=0A= > other IETF contributors and resolve them along with any other Last Ca= ll=0A= > comments that have been received. For more details on the INT Directo= rate,=0A= > see http://www.ietf.org/iesg/directorate.html.=0A= >=0A= > Summary: The draft is almost ready for publication but I have two com= ments=0A= > that you may want to address.=0A= >=0A= > Major=0A= > =3D=3D=3D=3D=3D=0A= >=0A= > * Intended Status:=0A= >=0A= > This looks more like a recommended set of network configuration param= eters=0A= > than a new protocol definition. Has the wg considered whether the Pro= posed=0A= > Standard status is appropriate (as opposed to Info or BCP)?=0A= >=0A= > * Section 10.1.1=0A= >=0A= > I have a question about the Sp computation. Looks like the Sp value n= eeds to=0A= > be between 1 and 9. In my view, the recommended method (3*ETX)-2 yiel= ds=0A= > values between 1 and 10. This needs to be fixed.=0A= >=0A= > This is how I see it.=0A= >=0A= > On a very high quality link, if there are no retransmissions required= ETX=0A= > will be 1/1 =3D> 1. Sp will be (3*1)-2 =3D> 1=0A= >=0A= > On a very poor quality link where the packet only gets through after = the full=0A= > 3 retries ETX will be 4/1 =3D> 4. Sp will be (3*4)-2 =3D> 10.=0A= >=0A= > Is my calculation correct?=0A= >=0A= > Editorial=0A= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= >=0A= > Section 3.2=0A= >=0A= > s/maintin/maintain/=0A= >=0A= > Section 3.3=0A= >=0A= > s/if none is/if none are/=0A= >=0A= > Thanks=0A= > Suresh=0A= >=0A= >=0A= =0A= From nobody Wed Nov 18 11:00:31 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 E4E081A21AE for ; Wed, 18 Nov 2015 11:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 WWqVvlfaRtVr for ; Wed, 18 Nov 2015 11:00:28 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0DE41A6FBA for ; Wed, 18 Nov 2015 11:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8101; q=dns/txt; s=iport; t=1447873227; x=1449082827; h=from:to:subject:date:message-id:mime-version; bh=xm/Qf99yFvdKiYEXKXZQ2bqON/WR6wlqUTkr8DQizeQ=; b=aao6Qde5UX1AiHkwvXM6Jd3hc/JrRb+hVUOqJIRc11w2kXNXXvDVpdOm 6nbfCOpvRcA9cx9qzPMSF5oO44dbFxr5uoKkTwVHsPYM6HY6+wZcr/gbq 5KHp1AmsdfAXOtSrBhL9FJUoCiNwLgSLDA4LQNzwKCLX9+X+zn3ktcDqV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxCgCVyUxW/5FdJa1egm5NU28Gr22OR?= =?us-ascii?q?TmBZSGFboFSORMBAQEBAQEBgQqEOy1eAYEAJgEEG4gmDZ8moDYBAQEBBgEBAQE?= =?us-ascii?q?BHo1sghARAUyEMQWWSgF+hCKIA4FiSYN3likBEREBQIQEcgEBg0k6gQcBAQE?= X-IronPort-AV: E=Sophos; i="5.20,314,1444694400"; d="scan'208,217"; a="48104625" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2015 19:00:26 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tAIJ0P59029839 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Nov 2015 19:00:26 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 Nov 2015 13:00:25 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Wed, 18 Nov 2015 13:00:25 -0600 From: "Bernie Volz (volz)" To: "" Thread-Topic: Tooling for Int Area Directorate Thread-Index: AdEiMpNDrT+mMr84TS+Mbnl8rYKsBw== Date: Wed, 18 Nov 2015 19:00:25 +0000 Message-ID: <03db822fb3ac413b959fbc269730af55@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.77.70] Content-Type: multipart/alternative; boundary="_000_03db822fb3ac413b959fbc269730af55XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Int-dir] Tooling for Int Area Directorate 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, 18 Nov 2015 19:00:30 -0000 --_000_03db822fb3ac413b959fbc269730af55XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: We are moving to making use of the GenArt tooling for the Int Area Director= ate. Some of you may already be familiar with this tooling if you are invol= ved in other directorates (such as Suresh Krishnan). One reason for this is= that the number of reviews has been increasing and manually tracking thing= s is getting a bit tedious. And, there are some plans under discussion to m= orph the Int Area Directorate (more on this in the future). There is a general FAQ at http://wiki.tools.ietf.org/dav/genart/gen_art_rev= iew_tool_how-to.html. And, there is some additional information at https://= wiki.tools.ietf.org/tools/art/trac/wiki. Please note that the link to the Int Area tool is https://art.tools.ietf.or= g/tools/art/ipdir/. Terry has requested some new reviews and I will try making use of the tool = to assign these reviews ... so a few of you may receive notifications short= ly. I'm sure I will do some things wrong in starting to use the tool, so please= forgive me if you get some odd or incorrect emails. If you have any questions, please email me directly (or int-dir if you feel= others could benefit) and I will try to do my best to answer. - Bernie --_000_03db822fb3ac413b959fbc269730af55XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

We are moving to making use of the GenArt tooling fo= r the Int Area Directorate. Some of you may already be familiar with this t= ooling if you are involved in other directorates (such as Suresh Krishnan).= One reason for this is that the number of reviews has been increasing and manually tracking things is getting a b= it tedious. And, there are some plans under discussion to morph the Int Are= a Directorate (more on this in the future).

 

There is a general FAQ at http://wiki.tools.ietf.org/dav/genart/gen_art_review_tool_how-to.html. = And, there is some additional information at https://wiki.to= ols.ietf.org/tools/art/trac/wiki.

 

Please note that the link to the Int Area tool= is https://art.tools.ietf.org/tools/art/ipdir/.

 

Terry has requested some new reviews and I will t= ry making use of the tool to assign these reviews … so a few of you m= ay receive notifications shortly.

 

I’m sure I will do some things wrong in sta= rting to use the tool, so please forgive me if you get some odd or incorrec= t emails.

 

If you have any questions, please email me direct= ly (or int-dir if you feel others could benefit) and I will try to do my be= st to answer.

 

-       = ;   Bernie

--_000_03db822fb3ac413b959fbc269730af55XCHALN003ciscocom_-- From nobody Wed Nov 18 11:26:50 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 03B931A8861 for ; Wed, 18 Nov 2015 11:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 YJPMHw9BxoTs for ; Wed, 18 Nov 2015 11:26:46 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F8E1A8857 for ; Wed, 18 Nov 2015 11:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12090; q=dns/txt; s=iport; t=1447874806; x=1449084406; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9r9YdempWR51Qv+6B6Vbq36BBw0hj5S2MVAYSUktRIY=; b=Hh8h+ez8vPaDvJt2wBWJVhIzOXAy9ZoLTw3M5V/ATSMSk7LqN/HWbnTM jwDAkM+eXRGo1/UH9Coq/R+i9rI+uP9IJ2W+EzM0D36ljc/z3lEyDX92s RwGSRlnSHXqgI01O8wT4/uMubBZ/oovnyjA/vTDKk8kzh+rVali+wIMqy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgBn0ExW/5JdJa1egm5NU28Gr22Oc?= =?us-ascii?q?AENgWUhhW4CgVA4FAEBAQEBAQGBCoQ0AQEBBC1cAgEIEQQBASgHMhQJCAEBBBM?= =?us-ascii?q?IiCYNv2QBAQEBAQEBAQEBAQEBAQEBAQEBAQEYi1KCGoIQEQFMCYQoBZZKAYUgi?= =?us-ascii?q?AOBYkmDd5YpAREOAQFChARyAQGDSTqBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,314,1444694400"; d="scan'208,217";a="209746894" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2015 19:26:45 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tAIJQjI8028108 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Nov 2015 19:26:45 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 Nov 2015 13:26:44 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Wed, 18 Nov 2015 13:26:44 -0600 From: "Bernie Volz (volz)" To: "" Thread-Topic: Tooling for Int Area Directorate Thread-Index: AdEiMpNDrT+mMr84TS+Mbnl8rYKsBwAA+hJA Date: Wed, 18 Nov 2015 19:26:44 +0000 Message-ID: References: <03db822fb3ac413b959fbc269730af55@XCH-ALN-003.cisco.com> In-Reply-To: <03db822fb3ac413b959fbc269730af55@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.77.70] Content-Type: multipart/alternative; boundary="_000_d07269ae8ffe44f0b51b55d101cbe94bXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] Tooling for Int Area Directorate 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, 18 Nov 2015 19:26:49 -0000 --_000_d07269ae8ffe44f0b51b55d101cbe94bXCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - There seems to be something off with the tooling (the directorate's l= ist of users are not correct); so not sure if you try this link at this tim= e what would happen. - Bernie From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Bernie Volz (v= olz) Sent: Wednesday, November 18, 2015 2:00 PM To: Subject: [Int-dir] Tooling for Int Area Directorate Hi: We are moving to making use of the GenArt tooling for the Int Area Director= ate. Some of you may already be familiar with this tooling if you are invol= ved in other directorates (such as Suresh Krishnan). One reason for this is= that the number of reviews has been increasing and manually tracking thing= s is getting a bit tedious. And, there are some plans under discussion to m= orph the Int Area Directorate (more on this in the future). There is a general FAQ at http://wiki.tools.ietf.org/dav/genart/gen_art_rev= iew_tool_how-to.html. And, there is some additional information at https://= wiki.tools.ietf.org/tools/art/trac/wiki. Please note that the link to the Int Area tool is https://art.tools.ietf.or= g/tools/art/ipdir/. Terry has requested some new reviews and I will try making use of the tool = to assign these reviews ... so a few of you may receive notifications short= ly. I'm sure I will do some things wrong in starting to use the tool, so please= forgive me if you get some odd or incorrect emails. If you have any questions, please email me directly (or int-dir if you feel= others could benefit) and I will try to do my best to answer. - Bernie --_000_d07269ae8ffe44f0b51b55d101cbe94bXCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI – There seem= s to be something off with the tooling (the directorate’s list of use= rs are not correct); so not sure if you try this link at this time what wou= ld happen.

 

-&nb= sp;         Bernie

 

From: Int-dir [mailto:int-dir-bounces@ietf.or= g] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, November 18, 2015 2:00 PM
To: <int-dir@ietf.org> <int-dir@ietf.org>
Subject: [Int-dir] Tooling for Int Area Directorate

 

Hi:

 

We are moving to making use of the GenArt tooling fo= r the Int Area Directorate. Some of you may already be familiar with this t= ooling if you are involved in other directorates (such as Suresh Krishnan).= One reason for this is that the number of reviews has been increasing and manually tracking things is getting a b= it tedious. And, there are some plans under discussion to morph the Int Are= a Directorate (more on this in the future).

 

There is a general FAQ at http://wiki.tools.ietf.org/dav/genart/gen_art_review_tool_how-to.html. = And, there is some additional information at https://wiki.to= ols.ietf.org/tools/art/trac/wiki.

 

Please note that the link to the Int Area tool= is https://art.tools.ietf.org/tools/art/ipdir/.

 

Terry has requested some new reviews and I will t= ry making use of the tool to assign these reviews … so a few of you m= ay receive notifications shortly.

 

I’m sure I will do some things wrong in sta= rting to use the tool, so please forgive me if you get some odd or incorrec= t emails.

 

If you have any questions, please email me direct= ly (or int-dir if you feel others could benefit) and I will try to do my be= st to answer.

 

-       = ;   Bernie

--_000_d07269ae8ffe44f0b51b55d101cbe94bXCHALN003ciscocom_-- From nobody Thu Nov 19 06:58:23 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 6BFDB1ACD24; Thu, 19 Nov 2015 00:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 YGm3FHDA-rXK; Thu, 19 Nov 2015 00:34:12 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 7B33E1ACCED; Thu, 19 Nov 2015 00:34:12 -0800 (PST) Received: by igvi2 with SMTP id i2so6735270igv.0; Thu, 19 Nov 2015 00:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8KkXjoRKqX0WuUiMBlquapHH64WSr587zRQbxsCKaH4=; b=UN3o3/4ja/YqI0StT7ZeoJYsBI1wfEjc02JT5vnVWGk03CiPzadE2XiqObFgxgbOfi BWOz1pNNsLxHdeWeR1ngvFJQWDJ5etGOQBxBYeFk3KMtp5+HFSTnQk1d42wDU3jSHfiK /LjvIwGtO0SNAwA+mxDB1gAMO5KHFZyXztRYhXHU8Wqn31SJq0lYD/WQ1iCSdQlZLyHc cOg1K8cX5gGIFr4abaKh5/MXHQS8PhL267SZoEcv1GCpperdCq/zm/YEz6KQTPXpz16d +k1C2wkBoKhWr6RbEQTVibUAzgYLFCMnzuBSvYvtBdNxXdq+7nCMY6Fox6YUhskhDEnS nAag== MIME-Version: 1.0 X-Received: by 10.50.160.5 with SMTP id xg5mr7955471igb.46.1447922051859; Thu, 19 Nov 2015 00:34:11 -0800 (PST) Received: by 10.79.38.68 with HTTP; Thu, 19 Nov 2015 00:34:11 -0800 (PST) In-Reply-To: <32E92224-BB99-4B2C-8138-8DDB4A6DC054@cisco.com> References: <32E92224-BB99-4B2C-8138-8DDB4A6DC054@cisco.com> Date: Thu, 19 Nov 2015 10:34:11 +0200 Message-ID: From: Dong Jiang To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=001a11c31560904d4c0524e09f90 Archived-At: X-Mailman-Approved-At: Thu, 19 Nov 2015 06:56:49 -0800 Cc: "draft-ietf-softwire-mesh-mib.all@ietf.org" , "int-ads@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 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, 19 Nov 2015 08:34:15 -0000 --001a11c31560904d4c0524e09f90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Carlos, We have modified the draft and plan to update a new version recently. Here are the details based on your comments: 1. We have added RFC 5512 and RFC 5566 in Terminology. 2. In section 5.1 we have mentioned that Softwire mesh framework RFC 5565 [RFC5565] does not mandate the use of any particular tunneling technology. Based on the BGP tunnel encapsulation attribute tunnel types introduced by RFC 5512[RFC5512] and RFC 5566[RFC5566], the softwire mesh tunnel types include at least L2TPv3 over IP, GRE, Transmit tunnel endpoint, IPsec in Tunnel mode, IP in IP tunnel with IPsec Transport Mode, MPLS-in-IP tunnel with IPsec Transport Mode and IP in IP. Since swmSupportedTunnelTable is used to provide the information about what kind of tunnel can be used for softwire mesh, we do not plan to manage detailed TLV information of each established tunnel in swmSupportedTunnelTable. 3. We have removed the sentence of =E2=80=98The swmMIB module can be used f= or configuration of certain objects,=E2=80=99 in Security Consideration. 4. We have added RFC 5566 and RFC 5640 in Normative References. Thank you! Br, Jiang 2015-10-22 22:00 GMT+03:00 Carlos Pignataro (cpignata) = : > Hi, > > I am an assigned INT directorate reviewer for > draft-ietf-softwire-mesh-mib-11. These comments were written primarily fo= r > the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat commen= ts > from any other IETF contributors and resolve them along with any other La= st > Call comments that have been received. For more details on the INT > Directorate, see http://www.ietf.org/iesg/directorate/intarea.html. > > This document defines MIB objects to manage softwire mesh solutions, and > targets the Standards Track. > > I have a number of comments and concerns with this document, which amount > to requesting the ADs to take a closer look: > > 3. Terminology > > This document uses terminology from the softwire problem statement > RFC 4925 [RFC4925] and the softwire mesh framework RFC 5565 > [RFC5565]. > > CMP: I think terminology from RFC 5512 is also heavily used. > > 5.1. The swmSupportedTunnelTable Subtree > > According > to section 4 of RFC 5512 [RFC5512], current softwire mesh tunnel > types include IP-IP, GRE and L2TPv3. > > CMP: This is true, but at the same time there are now many other =E2=80= =9Ccurrent > tunnel types=E2=80=9D (which are actually BGP Tunnel Encapsulation Attrib= ute Tunnel > Types). See > http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunne= l-types Specifically > the ones introduced by RFC5566 ought to be included. > > CMP: This comment also applies to swmSupportedTunnelType > > XX. Missing sub-TLVs > > CMP: If the Tunnel Type is one which requires encapsulation information > (e.g., L2TPv3 Session ID, Cookie, GRE Key, etc.), how is that information > managed? I cannot seem to find it in the MIB Module. See Section 4.1 of R= FC > 5512. > > CMP: Similarly, what about Protocol Type and Color (S4.2 and 4.3 of RFC > 5512), and IPsec Tunnel Authenticator (RFC 5566)? > > CMP: Similarly, what about the Load-Balancing Block values from RFC 5640? > Without this, an ECMP-aware L2TPv3 tunnel will be misunderstood. > > 8. Security Considerations > > The swmMIB module can be used for configuration of certain objects, > > CMP: How is this so, without read-write or read-create? > > 11. References > > 11.1. Normative References > > CMP: Curiously, I do not see RFC 5566 or RFC 5640 referenced. > > Hope these help! > > Thanks, > > =E2=80=94 Carlos. > > --001a11c31560904d4c0524e09f90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear Carlos,

=C2=A0

We have modified the draft and plan to upda= te a new version recently. Here are the details based on your comments:

=C2=A0

1. We have added RFC 5512 and RFC 5566 in= =C2=A0Terminology.

=C2=A0


2. In section 5.1 we have mentioned that So= ftwire mesh framework RFC 5565 [RFC5565] does not mandate the use of any particular tunneling technology.=C2=A0 Based on the BGP tunnel encapsulation attribute tunnel types introduced by RFC 5512[RFC5512]= and RFC 5566[RFC5566], the softwire mesh tunnel types include at least L2TPv3 o= ver IP, GRE, Transmit tunnel endpoint, IPsec in Tunnel mode, IP in IP tunnel wi= th IPsec Transport Mode, MPLS-in-IP tunnel with IPsec Transport Mode and IP in= IP.

=C2=A0

Since swmSupportedTunnelTable is used to pr= ovide the information about what kind of tunnel can be used for softwire mesh, we do = not plan to manage detailed TLV information of each established tunnel in swmSu= pportedTunnelTable.

=C2=A0

3. We have removed the sentence of =E2=80= =98The swmMIB m= odule can be used for configuration of certain objects,=E2=80=99 in Security Consideration.

=C2=A0

4. We have added RFC 5566 and RFC 5640 in N= ormative References.


Thank you!

Br,
Jiang

2015-10-22 22:00 GMT+03:00 Carlos Pignataro (cpignat= a) <cpignata@cisco.com>:
=
Hi,

I am a= n assigned INT directorate reviewer for draft-ietf-softwire-mesh-mib-11.=C2= =A0These comments were written primarily for the benefit of the Internet=C2= =A0Area Directors. Document editors and shepherd(s) should treat these=C2= =A0comments just like they would treat comments from any other IETF=C2=A0co= ntributors and resolve them along with any other Last Call comments=C2=A0th= at have been received. For more details on the INT Directorate,=C2=A0see=C2= =A0http://www.ietf.org/iesg/directorate/intarea.html.
This document defines MIB objects to manage softwi= re mesh solutions, and targets the Standards Track.

I have a number of comments and concerns with this document, which amount= to requesting the ADs to take a closer look:

3.= =C2=A0 Terminology

=C2=A0 =C2=A0This document uses terminology = from the softwire problem statement
=C2=A0 =C2=A0RFC 4925=C2=A0[R= FC4925] and the softwire mesh framework=C2=A0RFC 5565
=C2= =A0=C2=A0 [RFC5565].

CMP: I think terminology from= RFC 5512 is also heavily used.

5.1.=C2=A0 The swm= SupportedTunnelTable Subtree

=C2=A0 =C2=A0According<= /div>
=C2=A0 =C2=A0to section 4 of RFC 5512=C2=A0[RFC5512], current sof= twire mesh tunnel
=C2=A0 =C2=A0types include IP-IP, GRE and L2TPv= 3.

CMP: This is true, but at the same time t= here are now many other =E2=80=9Ccurrent tunnel types=E2=80=9D (which are a= ctually BGP Tunnel Encapsulation Attribute Tunnel Types). See=C2=A0http://www.iana.org/assignments/bgp-parameters= /bgp-parameters.xhtml#tunnel-types=C2=A0Specifically the ones introduce= d by RFC5566 ought to be included.

CMP: This comme= nt also applies to swmSupportedTunnelType

XX. Miss= ing sub-TLVs

CMP: If the Tunnel Type is one which = requires encapsulation information (e.g., L2TPv3 Session ID, Cookie, GRE Ke= y, etc.), how is that information managed? I cannot seem to find it in the = MIB Module. See Section 4.1 of RFC 5512.

CMP: Simi= larly, what about Protocol Type and Color (S4.2 and 4.3 of RFC 5512), and= =C2=A0IPsec Tunnel Authenticator (RFC 5566)?

CMP: = Similarly, what about the Load-Balancing Block values from RFC 5640? Withou= t this, an ECMP-aware L2TPv3 tunnel will be misunderstood.

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0The swmM= IB module can be used for configuration of certain objects,

CMP: How is this so, without read-write or read-create?

11.=C2=A0 References

11.1.=C2=A0 Normative Ref= erences

CMP: Curiously, I do not see RFC 5566 or R= FC 5640 referenced.

Hope these help!
Thanks,

=E2=80=94 Carlos.

--001a11c31560904d4c0524e09f90-- From nobody Thu Nov 19 07:04: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 AC9EC1A90A3; Thu, 19 Nov 2015 00:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 q9ADZ480bw_f; Thu, 19 Nov 2015 00:58:48 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 560C41ACF5B; Thu, 19 Nov 2015 00:58:48 -0800 (PST) Received: by ioc74 with SMTP id 74so81979644ioc.2; Thu, 19 Nov 2015 00:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iWv2O6ArpAGQ5XmrXKwJBM6kxhmxIvTw3ACfCsCVeFg=; b=b/ls3r+PnBIl9DYl4yPIUa/kU173zFnStLUeHUx/74yRqn4JDvEYUyvRVS62SdPGEl oo38a21U1n70C4DTSa1Q9bLfQqm0OSzj+BFfAXXQtWFLL2rUKurjjf52cZ3+ID8Qt792 +WwGauf8608hZUQ9I6jW0Kyohj1XEI6P3/bMWcmqTGfj/02MubL3Ktmxvv2PM/qCxvzA 53Qg4WBoexKrjlDFGpyGl0QfQBjNu5Ge+DgEk5AAZhAk86GaVgBEUAGiYqfesBNDHc4P LsEC4V/6aAzzb7FeExx4n/FvPbXOlZG03rwW3kHoUWSo2wrChp76zQOuKwA4kPOnYVmQ Z8EA== MIME-Version: 1.0 X-Received: by 10.107.133.16 with SMTP id h16mr6710163iod.79.1447923527704; Thu, 19 Nov 2015 00:58:47 -0800 (PST) Received: by 10.79.38.68 with HTTP; Thu, 19 Nov 2015 00:58:47 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Nov 2015 10:58:47 +0200 Message-ID: From: Dong Jiang To: Hui Deng Content-Type: multipart/alternative; boundary=001a113f9a3a87e8720524e0f747 Archived-At: X-Mailman-Approved-At: Thu, 19 Nov 2015 07:04:29 -0800 Cc: draft-ietf-softwire-mesh-mib.all@ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11 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, 19 Nov 2015 08:58:51 -0000 --001a113f9a3a87e8720524e0f747 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Deng Hui, We have modified the draft and plan to update a new version recently. Here are the details based on your comments: 1. We have added quotation mark for 0.0.0.0 and :: 2. We have added references for swmEncapsEIPDst and swmEncapsIIPDst. 3. We have explained the usage of ipv4(1) and ipv6(2) in different scenario in the DESCRIPTION of swmEncapsEIPDstType: =E2=80=9CThis object specifies the address type used for swmEncapsEIPDst. I= t is different from the tunnelIfAddressType in the tunnelIfTable. The swmEncapsEIPDstType is IPv6 (2) if it is IPv6-over-IPv4 tunneling. The swmEncapsEIPDstType is IPv4 (1) if it is IPv4-over-IPv6 tunneling.=E2=80=9D We also added "IPv4 and IPv6 in RFC RFC4001." in REFERECNCE: 4. swmEncapsEIPDstType and swmEncapsIIPDstType are using two different address types in the scenario of softwire mesh. For example, if swmEncapsEIPDstType is ipv4, swmEncapsIIPDstType will be IPv6. Thus we did not modify this part. 5. We have modified the DESCRIPTION: "Represents the tunnel type that can be used for softwire mesh scenario, such as L2TPv3 over IP, GRE, Transmit tunnel endpoint, IPsec in Tunnel-mode, IP in IP tunnel with IPsec Transport Mode, MPLS-in-IP tunnel with IPsec Transport Mode and IP in IP. There is no restriction of tunnel type the Softwire mesh can use." 6. The number of connection tunnels can be calculated by the number of entries in swmEncapsTable. Thus we did not add new statistic object. But we clarified this in 5.2: =E2=80=9CThe number of entries in swmEncapsTable sho= ws how many softwire mesh tunnels are maintained in this AFBR.=E2=80=9D 7. Since swmEncapsIIPDst is an ip address used for encapsulation, the prefix length is the length of the ip address. Thus we did not define swmEncapsIIPDstPrefixLength. 8. swmEncapsEIPDst and swmEncapsIIPType are not-accessible since they are used for indexing (section7.7 of RFC1902 says Objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects. The MAX-ACCESS clause for auxiliary objects is "not-accessible"). Thank you! Best regards, Jiang 2015-10-25 9:55 GMT+02:00 Hui Deng : > Hi > > I am an assigned INT directorate reviewer for > draft-ietf-softwire-mesh-mib-11. These comments were written primarily fo= r > the benefit of the Internet Area Directors. > > Document editors and shepherd(s) should treat these comments just like > they would treat comments from any other IETF contributors and resolve th= em > 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/intarea.html. > > This document defines MIB objects to manage softwire mesh solutions, and > targets the Standards Track. > > Please find below review comments: > > 1) Page 5 in section 6.2, =E2=80=9CThe tunnelIfRemoteInetAddress MUST be = set to > 0.0.0.0 for IPv4 or :: for IPv6 because it is a point to multi-point > tunnel.=E2=80=9D > It needs quotation mark for 0.0.0.0 and :: > > 2) In the MIB definitions, it needs REFERENCE for the IMPORT objects. eg: > swmEncapsEIPDst OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The E-IP destination prefix, which is > used for I-IP encapsulation destination looking up." > ::=3D { swmEncapsEntry 2 } > > It should add a REFERENCE =E2=80=9CE-IP and I-IP in RFC 5565 =E2=80=9D. T= he same comment > for the definition of swmEncapsIIPDst. > > 3) In page 8, > swmEncapsEIPDstType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object specifies the address type used for > swmEncapsEIPDst. It is different from the tunnelIfAddressType > in the tunnelIfTable." > ::=3D { swmEncapsEntry 1 } > > It should list ipv4(1) and ipv6(2) in the DESCRIPTION for different > scenario. Also it should add a REFERENCE to RFC 4001. > > 4) In page 8, SwmEncapsEntry: I think swmEncapsEIPDstType and > swmEncapsIIPDstType should just be swmEncapsIPDstType and apply to both. = If > all address objects in > > the row are of the same type, you only need one type object. > > 5) In page 7, =E2=80=9CRepresents the tunnel type that the AFBR supports= =E2=80=9D in > definition of swmSupportedTunnelType. It need a clarification that It > represents the tunnel > > type used for softwire mesh scenario. > > 6) As it states in the section 6.1, the ifInucastPkts counts the number > of IPv6 packets which are sent to the virtual interface for decapsulation > into IPv4. I > > think it need some statistics objects to define for the softwire mesh suc= h > as the number of the connection tunnel when running point to multi-point > tunnel. > > 7) Why not define a parameter for swmEncapsIIPDstPrefixLength? > > 8) In the swmEncapsGroup, there are only information about > swmEncapsIIPDst and swmEncapsIIPDstType, why there are not swmEncapsEIPDs= t > and swmEncapsIIPType and so on? > > Best regards, > > DENG Hui > --001a113f9a3a87e8720524e0f747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2=A0

Dear Deng Hui,

=C2=A0

We have modified the draft and plan to upda= te a new version recently. Here are the details based on your comments:

=C2=A0

1. We have added quotation mark fo= r 0.0.0.0 and ::

=C2=A0

2. We have added references for swmEncapsEIPDst and swmEncapsIIPDst.

=C2=A0

3. We have explained the usage of ipv4(1) and ipv6(2) in different scenario in= the DESCRIPTION of swmEncapsEIPDstType:

=E2=80=9CThis object specifies the address type used for swmEncapsEIPDst. It is different from the tunnelIfAddressType in the tunnelIfTable. The swmEncapsEIPDstType = is IPv6 (2) if it is IPv6-over-IPv4 tunneling. The swmEncapsEIPDstType is IPv4= (1) if it is IPv4-over-IPv6 tunneling.=E2=80=9D

We also added "IPv4 and IPv6 in RFC RFC4001." in REFERECNCE: =

=C2=A0

4. swmEncapsEIPDst= Type and swmEncapsIIPDstType are u= sing two different address types in the scenario of softwire mesh. For example, if swmEncapsEIPDstType is ipv4, swmEncapsIIPDstType will be IPv6. Thus we did not modify this part.

=C2=A0

5. We have modified the DESCRIPTION: "Represents the tunnel type that can be used for softwire= mesh scenario, such as L2TPv3 over IP, GRE, Transmit tunnel endpoint, IPsec in Tunnel-mode, IP in IP tunnel with IPsec Transport Mode, MPLS-in-IP tunnel w= ith IPsec Transport Mode and IP in IP. There is no restriction of tunnel type t= he Softwire mesh can use."

=C2=A0

6. The number of connection tunnels can be calculated by the number of entries in swmEncapsTable. Thus we did not add new statistic object. But we clarified this in 5.2: =E2=80=9CThe number of entries in swmEncapsTable sho= ws how many softwire mesh tunnels are maintained in this AFBR.=E2=80=9D=

7. Since swmEncapsIIPDst is an ip address u= sed for encapsulation, the prefix length is the length of the ip address. Thus we d= id not define swmE= ncapsIIPDstPrefixLength.

=C2=A0

8. swmEncapsEIPDst and swmEncapsIIPType are not-accessible since they are used for indexing (section7.7 of RFC1902 says= Objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects.= =C2=A0 The MAX-ACCESS clause for auxiliary objects is "not-accessible").

=C2=A0

Thank you!

Best regards,

Jiang


2015-10-25 9:55 GMT+02:00 Hui Deng <denghui02@gmail.com>:
Hi

I am an assigned INT directorate re= viewer for draft-ietf-softwire-mesh-mib-11. These comments were written pri= marily for the benefit of the Internet Area Directors.=C2=A0

=
Document editors and shepherd(s) should treat these comments jus= t like they would treat comments from any other IETF contributors and resol= ve them along with any other=C2=A0

Last Call comme= nts that have been received. For more details on the INT Directorate, see <= a href=3D"http://www.ietf.org/iesg/directorate/intarea.html" target=3D"_bla= nk">http://www.ietf.org/iesg/directorate/intarea.html.

This document defines MIB objects to manage softwire mesh solution= s, and targets the Standards Track.

Please find be= low review comments:

1) Page 5 in section 6.2, =E2=80=9CThe tunnelIfRemoteInetAdd= ress MUST be set to 0.0.0.0 for IPv4 or :: for IPv6 because it is a point t= o multi-point tunnel.=E2=80=9D=C2=A0
It needs quotation mark for = 0.0.0.0 and ::

2) In the MIB definitions, it needs REFERENCE for the IMPORT objec= ts. eg:
swmEncapsEIPDst OBJECT-TYPE
SYNTAX InetAddress<= /div>
MAX-ACCESS not-accessible
STATUS current
DESC= RIPTION
"The E-IP destination prefix, which is
use= d for I-IP encapsulation destination looking up."
::=3D { sw= mEncapsEntry 2 }

It should add a REFERENCE =E2=80= =9CE-IP and I-IP in RFC 5565 =E2=80=9D. The same comment for the definition= of swmEncapsIIPDst.

3) In page 8,=C2=A0
swmEncapsEIPDstType OBJECT-TYP= E
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object spec= ifies the address type used for
swmEncapsEIPDst. It is different = from the tunnelIfAddressType
in the tunnelIfTable."
::=3D { swmEncapsEntry 1 }

It should list ipv4(1= ) and ipv6(2) in the DESCRIPTION for different scenario. Also it should add= a REFERENCE to RFC 4001.

4) In page 8, SwmEncapsEntry: I think swmEncapsEIPDstTy= pe and swmEncapsIIPDstType should just be swmEncapsIPDstType and apply to b= oth. If all address objects in=C2=A0

the row are o= f the same type, you only need one type object.

5)= In page 7, =E2=80=9CRepresents= the tunnel type that the AFBR supports=E2=80=9D in definition of swmSuppor= tedTunnelType. It need a clarification that It represents the tunnel=C2=A0<= /div>

type used for softwire mesh scenario.
6) As it states in= the section 6.1, the ifInucastPkts counts the number of IPv6 packets which= are sent to the virtual interface for decapsulation into IPv4. I=C2=A0

think it need some statistics objects to define for t= he softwire mesh such as the number of the connection tunnel when running p= oint to multi-point tunnel.

7) Why not define a parameter for swmEncapsIIPDstPref= ixLength?=C2=A0

8) In the swmEncapsGroup, there are only information about swmEnc= apsIIPDst and swmEncapsIIPDstType, why there are not swmEncapsEIPDst and sw= mEncapsIIPType and so on?=C2=A0

Best regards= ,

DENG Hui

--001a113f9a3a87e8720524e0f747-- From nobody Fri Nov 20 13:35:14 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 8C7211B3E69 for ; Fri, 20 Nov 2015 13:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.085 X-Spam-Level: X-Spam-Status: No, score=-15.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 wq_jEfZX8DNg for ; Fri, 20 Nov 2015 13:35:10 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8AF31B3E68 for ; Fri, 20 Nov 2015 13:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18015; q=dns/txt; s=iport; t=1448055309; x=1449264909; h=from:to:subject:date:message-id:references:mime-version; bh=cGQUpapDw+0QXInB2BZIZlBpRwqxOHgQHNYVSvziQo4=; b=WLkTANOCpI273du6qtQ86MdAk8iiKIlFOULZs2zG7nMvcpNheS8OCwO3 HW1DnDgUkeM9KTcO4VwE6VXqMR0tb9ZRxL0e2SZop4G42xqCeVOxizmG0 DLekqgQzcdw7qmStngXYiD/breFc+Xg/l4lFA/Lhp2vAABOHfpdWBvZxu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQBvkU9W/5tdJa1egm5NU28GsBSOd?= =?us-ascii?q?gENgWUhhW4CgUg4FAEBAQEBAQGBCoQ0AQEBBC1cAgEIEQQBASgHMhQJCAEBBBM?= =?us-ascii?q?IiCYNwGMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYi1KCGoIQEQFMCYQoBZZMAYUii?= =?us-ascii?q?AWBZEmDd5YuAREOAQFChARyAQGDaDqBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,324,1444694400"; d="scan'208,217";a="210027823" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2015 21:35:08 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAKLZ87u023933 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 20 Nov 2015 21:35:08 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 20 Nov 2015 15:35:08 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Fri, 20 Nov 2015 15:35:08 -0600 From: "Bernie Volz (volz)" To: "" Thread-Topic: Tooling for Int Area Directorate Thread-Index: AdEiMpNDrT+mMr84TS+Mbnl8rYKsBwAA+hJAAGkSW7A= Date: Fri, 20 Nov 2015 21:35:08 +0000 Message-ID: <8067b58b91e24b579f522fbb1cec7b54@XCH-ALN-003.cisco.com> References: <03db822fb3ac413b959fbc269730af55@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: multipart/alternative; boundary="_000_8067b58b91e24b579f522fbb1cec7b54XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] Tooling for Int Area Directorate 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, 20 Nov 2015 21:35:12 -0000 --_000_8067b58b91e24b579f522fbb1cec7b54XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, I figured out what the issue is ... wrong URL. Please use https://art.tools.ietf.org/tools/art/intdir/. (I also updated be= low.) - Bernie From: Bernie Volz (volz) Sent: Wednesday, November 18, 2015 2:25 PM To: Subject: RE: Tooling for Int Area Directorate FYI - There seems to be something off with the tooling (the directorate's l= ist of users are not correct); so not sure if you try this link at this tim= e what would happen. - Bernie From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Bernie Volz (v= olz) Sent: Wednesday, November 18, 2015 2:00 PM To: > > Subject: [Int-dir] Tooling for Int Area Directorate Hi: We are moving to making use of the GenArt tooling for the Int Area Director= ate. Some of you may already be familiar with this tooling if you are invol= ved in other directorates (such as Suresh Krishnan). One reason for this is= that the number of reviews has been increasing and manually tracking thing= s is getting a bit tedious. And, there are some plans under discussion to m= orph the Int Area Directorate (more on this in the future). There is a general FAQ at http://wiki.tools.ietf.org/dav/genart/gen_art_rev= iew_tool_how-to.html. And, there is some additional information at https://= wiki.tools.ietf.org/tools/art/trac/wiki. Please note that the link to the Int Area tool is https://art.tools.ietf.or= g/tools/art/intdir/. Terry has requested some new reviews and I will try making use of the tool = to assign these reviews ... so a few of you may receive notifications short= ly. I'm sure I will do some things wrong in starting to use the tool, so please= forgive me if you get some odd or incorrect emails. If you have any questions, please email me directly (or int-dir if you feel= others could benefit) and I will try to do my best to answer. - Bernie --_000_8067b58b91e24b579f522fbb1cec7b54XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, I figured out what= the issue is … wrong URL.

 

Please use <= a href=3D"https://art.tools.ietf.org/tools/art/intdir/">https://art.tools.i= etf.org/tools/art/intdir/. (I also update= d below.)

 

-&nb= sp;         Bernie

 

From: Bernie Volz (volz)
Sent: Wednesday, November 18, 2015 2:25 PM
To: <int-dir@ietf.org> <int-dir@ietf.org>
Subject: RE: Tooling for Int Area Directorate

 

FYI – There seem= s to be something off with the tooling (the directorate’s list of use= rs are not correct); so not sure if you try this link at this time what wou= ld happen.

 

-&nb= sp;         Bernie

 

From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, November 18, 2015 2:00 PM
To: <int-dir@ietf.org>= <int-dir@ietf.org>
Subject: [Int-dir] Tooling for Int Area Directorate

 

Hi:

 

We are moving to making use of the GenArt tooling fo= r the Int Area Directorate. Some of you may already be familiar with this t= ooling if you are involved in other directorates (such as Suresh Krishnan).= One reason for this is that the number of reviews has been increasing and manually tracking things is getting a b= it tedious. And, there are some plans under discussion to morph the Int Are= a Directorate (more on this in the future).

 

There is a general FAQ at http://wiki.tools.ietf.org/dav/genart/gen_art_review_tool_how-to.html. = And, there is some additional information at https://wiki.to= ols.ietf.org/tools/art/trac/wiki.

 

Please note that the link to the Int Area tool= is https://art.tools.ietf.org/tools/art/intdir/.

 

Terry has requested some new reviews and I will t= ry making use of the tool to assign these reviews … so a few of you m= ay receive notifications shortly.

 

I’m sure I will do some things wrong in sta= rting to use the tool, so please forgive me if you get some odd or incorrec= t emails.

 

If you have any questions, please email me direct= ly (or int-dir if you feel others could benefit) and I will try to do my be= st to answer.

 

-       = ;   Bernie

--_000_8067b58b91e24b579f522fbb1cec7b54XCHALN003ciscocom_-- From nobody Tue Nov 24 09:29:20 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 322021A88C0 for ; Tue, 24 Nov 2015 09:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 YNjlasF-3oXC for ; Tue, 24 Nov 2015 09:29:18 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 810921B2E47 for ; Tue, 24 Nov 2015 09:29:14 -0800 (PST) Received: by pabfh17 with SMTP id fh17so29241977pab.0 for ; Tue, 24 Nov 2015 09:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=CegmZkwb0PFBdG9ekSteW+vdhTdUCcJTbvOpwqhGvso=; b=pVUeutmiXEY3DdotGLP2rLhl1f5Q99KsKPPPhNlX6dtvzDMqoQRrmAKqJKwGptCJG1 +ha2F3ihmnO55/Q326CkSJ7fo8btBPtA0hKNH2bz23Lr2BAJ+20c1etcwtd0GUG8iapm iwW3hG/jpgtxjtb4JMg8/UvDceNDL7c0TO3CeCqbteTy0Dgwcv7QmHD0hxmzC3Lz3lbn XgaoTPhaZgDC/CiR3j311vvumjYaqSUwffIXDbLf5RRrhV+r816nLoYa1zUs/0fJUD1g +cYug56hT4fZdfhqX7TzVNkAN63mdJw7CSKadVrheChhO2fxc7ItcM+KbojvZDxF4s9Q XWbg== X-Received: by 10.66.122.39 with SMTP id lp7mr44767185pab.74.1448386154206; Tue, 24 Nov 2015 09:29:14 -0800 (PST) Received: from [10.16.84.147] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id c1sm16126920pas.1.2015.11.24.09.29.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Nov 2015 09:29:13 -0800 (PST) To: "" , draft-ietf-hip-rfc6253-bis@tools.ietf.org, "volz@cisco.com" From: Jouni Korhonen Message-ID: <56549E68.7070701@gmail.com> Date: Tue, 24 Nov 2015 09:29:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05 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, 24 Nov 2015 17:29:19 -0000 I reviewed this document as part of the Int-Dir reviews activity. You should treat the comments as any IETF LC comments. The document is ready for piblication with minor nits. My comments follow the line numbering as seen in IDnits. Editorial Comments: * Line 28: s/extends/updates * Line 72: s/extends/updates * Line 269: replaces or obsoletes.. typically when following the cover page terminology I would prefer "obsoletes" here as well. * Line 287: a verb is missing? e.g. "..are discussed.." etc * Lines 264-265: I cannot parse this sentence. "in order" meanning the 2 octets contain first Cert Group and followed by Cert ID? Please clarify. * Figure line 136: although text is clear about the padding behavior the figure makes one think there is always 2 octets of padding.. suggest coming up with slightly different ascii art here. Other (substantial) comments: * Lines 95-98: I find the recommendation of not including the CERT in the I1 packet odd. Actually, allowing it in I1 is a bit odd in general. A well behaving initiator would not do that unless it has a very good reason to do so but a hostile initiator would most certainly do that just to cause more processing at the responder. Why the CERT has to be possible in I1 if it is not recommended to be added in the first place? * Lines 103-14: The "MUST be set" text is a bit strange. Why not stating the same for Cert ID and type as well? Actually as these fields are in fixed positions and cannot be "optionally" left out. I suggest doing some rewording here. * Section 7 security considerations does not discuss the possible hostile use of CERT payload in I1 packet.. this is already hinted in Section 2. - Jouni From nobody Tue Nov 24 13:32:29 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 99AB61A8AC1 for ; Tue, 24 Nov 2015 13:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 WcLyW4IS-qu5 for ; Tue, 24 Nov 2015 13:32:26 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC7B1A8AB7 for ; Tue, 24 Nov 2015 13:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4422; q=dns/txt; s=iport; t=1448400746; x=1449610346; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3u5/z4UwRINj93U5MzpUMRulzwrIESGJJlKWtApYk9A=; b=KwriyBA+T/x0uFktMVKFKLvJCuEBkQx0kWzeEDkntVE4WYRlcLlE0PDB oDTn+6owmtVpKQL1j30TQiNKFJ76wUrHnyqFmRn1oLp7NT9VwPOHw/GUW OkrdliSDALvhUJJZpKunQG1mXJkPd+3CmXF+YwZm4Rfd3KF41gYV0iDZE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQCs1lRW/4oNJK1egztTbwa+OgENg?= =?us-ascii?q?WchhW4CHIEnOBQBAQEBAQEBgQqENQEBBCMRVQIBCBoCJgICAh8RFRACBAESiBk?= =?us-ascii?q?DEg2tYIsuDYRqAQEBAQEBAQEBAQEBAQEBAQEBFwSBAYlLgQaCGjmCHoMEgUQFl?= =?us-ascii?q?lUBhSSCcoMlgXaBW4RBjmeHVAEfAQFChARyhCWBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,339,1444694400"; d="scan'208";a="211774454" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Nov 2015 21:32:25 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tAOLWP7B002232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2015 21:32:25 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 24 Nov 2015 15:32:25 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Tue, 24 Nov 2015 15:32:25 -0600 From: "Bernie Volz (volz)" To: Jouni Korhonen , "" , "draft-ietf-hip-rfc6253-bis@tools.ietf.org" Thread-Topic: Int-Dir review of draft-ietf-hip-rfc6253-bis-05 Thread-Index: AQHRJt2ketpRG91hFk+lCZyiJyKHH56rwl+A Date: Tue, 24 Nov 2015 21:32:24 +0000 Message-ID: References: <56549E68.7070701@gmail.com> In-Reply-To: <56549E68.7070701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05 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, 24 Nov 2015 21:32:28 -0000 VGhhbmtzIGZvciBkb2luZyB0aGUgcmV2aWV3IGZvciBJbnQtRGlyIEpvdW5pIQ0KDQoNCkJ5IHRo ZSB3YXkgYW5kIGZvciB3aGF0IGl0IG1heSBiZSB3b3J0aCB0byBzb21lb25lOg0KDQpPbmUgaXRl bSBJIG5vdGljZWQgd2hlbiBxdWlja2x5IGxvb2tpbmcgYXQgdGhpcyBkb2N1bWVudCB3aGlsZSBh c3NpZ25pbmcNCml0IHRvIHJldmlld2VycyBmb3IgdGhlIEludC1EaXIgaXMgdGhhdCBBcHBlbmRp eCBCIOKAnENoYW5nZSBMb2figJ0gaXMNCnByb2JhYmx5IG5vdCB0aGUgYmVzdCDigJxyZXBvcnTi gJ0gb2YgZGlmZmVyZW5jZXMgZnJvbSBSRkMgNjI1Mz8gQW4gZXhhbXBsZQ0KdGhhdCB3YXMgYmV0 dGVyIGlzIGluIGFub3RoZXIgZG9jdW1lbnQgSSB3YXMgYWxzbyBpbiB0aGUgcHJvY2VzcyBvZg0K YXNzaWduaW5nIGF0IHRoZSBzYW1lIHRpbWUgLSBzZWUNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWhpcC1yZmM1MjAzLWJpcy0wOSNhcHBlbmRpeC1BOg0KDQrigJQNCg0K QXBwZW5kaXggQS4gIENoYW5nZXMgZnJvbSBSRkMgNTIwMw0KDQogICBvICBVcGRhdGVkIHJlZmVy ZW5jZXMgdG8gcmV2aXNlZCBISVAgc3BlY2lmaWNhdGlvbnMuDQoNCiAgIG8gIEFkZGVkIGEgbmV3 IHJlZ2lzdHJhdGlvbiBmYWlsdXJlIHR5cGUgZm9yIHVzZSBpbiBjYXNlIG9mDQogICAgICBpbnN1 ZmZpY2llbnQgcmVzb3VyY2VzIGF2YWlsYWJsZSBhdCB0aGUgSElQIHJlZ2lzdHJhci4NCg0KICAg byAgQWRkZWQgcmVxdWVzdGVyIGF1dGhvcml6YXRpb24gYmFzZWQgb24gY2VydGlmaWNhdGVzLCBh bmQgbmV3DQogICAgICByZWdpc3RyYXRpb24gZmFpbHVyZSB0eXBlIGZvciBpbnZhbGlkIGNlcnRp ZmljYXRlLg0KDQoNCuKAlA0KDQpCYXNpY2FsbHkgdGhlIGRldGFpbGVkIGNoYW5nZSBsb2cgb2Yg cmZjNjI1My1iaXMgZHJhZnQgaXMgbm90IGFzIHVzZWZ1bCBhcw0KdGhlIGtleSBkaWZmZXJlbmNl cyBmcm9tIHRoZSBvcmlnaW5hbCBSRkMgYmVpbmcg4oCcYmlzLWVk4oCdLiBUaGVyZSBjaGFuZ2Ug bG9nDQppcyBtb3JlIG9mdGVuIHRoYW4gbm90IHJlcXVlc3RlZCB0byBiZSBkcm9wcGVkIGJ5IHRo ZSBSRkMgZWRpdG9yIHdoZW4NCnB1Ymxpc2hlZCBhcyBhbiBSRkMuDQoNClNvLCBJIHdvdWxkIHJl Y29tbWVuZCByZXdvcmtpbmcgdGhlIGRyYWZ0IHRvIGhhdmUgYSBjbGVhciBsaXN0IG9mDQpkaWZm ZXJlbmNlcyBmcm9tIHRoZSBSRkMgKHlvdSBjYW4gbGVhdmUgdGhlIGRldGFpbGVkIGxvZyBpZiB5 b3Ugd2FudCwgYnV0DQpyZWNvbW1lbmQgaXQgYmUgcmVtb3ZlZCBieSBSRkMgZWRpdG9yIG9uIHB1 YmxpY2F0aW9uLikNCg0KLSBCZXJuaWUNCg0KT24gMTEvMjQvMTUsIDEyOjI5IFBNLCAiSm91bmkg S29yaG9uZW4iIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPiB3cm90ZToNCg0KPkkgcmV2aWV3ZWQg dGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBJbnQtRGlyIHJldmlld3MgYWN0aXZpdHkuIFlv dQ0KPnNob3VsZCB0cmVhdCB0aGUgY29tbWVudHMgYXMgYW55IElFVEYgTEMgY29tbWVudHMuDQo+ DQo+VGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwaWJsaWNhdGlvbiAgd2l0aCBtaW5vciBuaXRz LiBNeSBjb21tZW50cw0KPmZvbGxvdyB0aGUgbGluZSBudW1iZXJpbmcgYXMgc2VlbiBpbiBJRG5p dHMuDQo+DQo+RWRpdG9yaWFsIENvbW1lbnRzOg0KPg0KPiogTGluZSAyODogcy9leHRlbmRzL3Vw ZGF0ZXMNCj4qIExpbmUgNzI6IHMvZXh0ZW5kcy91cGRhdGVzDQo+KiBMaW5lIDI2OTogcmVwbGFj ZXMgb3Igb2Jzb2xldGVzLi4gdHlwaWNhbGx5IHdoZW4gZm9sbG93aW5nIHRoZQ0KPiAgIGNvdmVy IHBhZ2UgdGVybWlub2xvZ3kgSSB3b3VsZCBwcmVmZXIgIm9ic29sZXRlcyIgaGVyZSBhcyB3ZWxs Lg0KPiogTGluZSAyODc6IGEgdmVyYiBpcyBtaXNzaW5nPyBlLmcuICIuLmFyZSBkaXNjdXNzZWQu LiIgZXRjDQo+KiBMaW5lcyAyNjQtMjY1OiBJIGNhbm5vdCBwYXJzZSB0aGlzIHNlbnRlbmNlLiAi aW4gb3JkZXIiIG1lYW5uaW5nDQo+ICAgdGhlIDIgb2N0ZXRzIGNvbnRhaW4gZmlyc3QgQ2VydCBH cm91cCBhbmQgZm9sbG93ZWQgYnkgQ2VydCBJRD8NCj4gICBQbGVhc2UgY2xhcmlmeS4NCj4qIEZp Z3VyZSBsaW5lIDEzNjogYWx0aG91Z2ggdGV4dCBpcyBjbGVhciBhYm91dCB0aGUgcGFkZGluZw0K PiAgIGJlaGF2aW9yIHRoZSBmaWd1cmUgbWFrZXMgb25lIHRoaW5rIHRoZXJlIGlzIGFsd2F5cyAy IG9jdGV0cw0KPiAgIG9mIHBhZGRpbmcuLiBzdWdnZXN0IGNvbWluZyB1cCB3aXRoIHNsaWdodGx5 IGRpZmZlcmVudCBhc2NpaQ0KPiAgIGFydCBoZXJlLg0KPg0KPk90aGVyIChzdWJzdGFudGlhbCkg Y29tbWVudHM6DQo+DQo+KiBMaW5lcyA5NS05ODogSSBmaW5kIHRoZSByZWNvbW1lbmRhdGlvbiBv ZiBub3QgaW5jbHVkaW5nIHRoZSBDRVJUDQo+ICAgaW4gdGhlIEkxIHBhY2tldCBvZGQuIEFjdHVh bGx5LCBhbGxvd2luZyBpdCBpbiBJMSBpcyBhIGJpdCBvZGQgaW4NCj4gICBnZW5lcmFsLiBBIHdl bGwgYmVoYXZpbmcgaW5pdGlhdG9yIHdvdWxkIG5vdCBkbyB0aGF0IHVubGVzcyBpdCBoYXMNCj4g ICBhIHZlcnkgZ29vZCByZWFzb24gdG8gZG8gc28gYnV0IGEgaG9zdGlsZSBpbml0aWF0b3Igd291 bGQgbW9zdA0KPiAgIGNlcnRhaW5seSBkbyB0aGF0IGp1c3QgdG8gY2F1c2UgbW9yZSBwcm9jZXNz aW5nIGF0IHRoZSByZXNwb25kZXIuDQo+ICAgV2h5IHRoZSBDRVJUIGhhcyB0byBiZSBwb3NzaWJs ZSBpbiBJMSBpZiBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8NCj4gICBiZSBhZGRlZCBpbiB0aGUg Zmlyc3QgcGxhY2U/DQo+KiBMaW5lcyAxMDMtMTQ6IFRoZSAiTVVTVCBiZSBzZXQiIHRleHQgaXMg YSBiaXQgc3RyYW5nZS4gV2h5IG5vdA0KPiAgIHN0YXRpbmcgdGhlIHNhbWUgZm9yIENlcnQgSUQg YW5kIHR5cGUgYXMgd2VsbD8gQWN0dWFsbHkgYXMgdGhlc2UNCj4gICBmaWVsZHMgYXJlIGluIGZp eGVkIHBvc2l0aW9ucyBhbmQgY2Fubm90IGJlICJvcHRpb25hbGx5IiBsZWZ0IG91dC4NCj4gICBJ IHN1Z2dlc3QgZG9pbmcgc29tZSByZXdvcmRpbmcgaGVyZS4NCj4qIFNlY3Rpb24gNyBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBkb2VzIG5vdCBkaXNjdXNzIHRoZSBwb3NzaWJsZQ0KPiAgIGhvc3Rp bGUgdXNlIG9mIENFUlQgcGF5bG9hZCBpbiBJMSBwYWNrZXQuLiB0aGlzIGlzIGFscmVhZHkgaGlu dGVkDQo+ICAgaW4gU2VjdGlvbiAyLg0KPg0KPi0gSm91bmkNCg0K From nobody Wed Nov 25 04:52:33 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 8A0481B29F3 for ; Wed, 25 Nov 2015 04:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, 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 g218DNL9h-Y1 for ; Wed, 25 Nov 2015 04:52:30 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB261A1F70 for ; Wed, 25 Nov 2015 04:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6210; q=dns/txt; s=iport; t=1448455950; x=1449665550; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BGLOdKguVWtVaveUT2DXH2xH7AkiVDvOMA7QXNg+edk=; b=e9/gWoXr+KkgyWpVkZ2vHqYAV1vyEWZojqqUKfg2x5pBeDnqPfT2gbum Anh3v1Zlhic4+RWOQc0qUPGhwIivtGFJfaYZcwiVnZxilA6kTkEA2+Pe4 3RakTobac9txoXdXqniQ9/8r2ToEibLc413l769Bfw4l9ua3KFkWHJr7z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQDVrVVW/4UNJK1VCYM7U28GvjkBD?= =?us-ascii?q?YFnFwqCPoMwAoFFOBQBAQEBAQEBgQqENAEBAQMBAQEBNzQXBAIBCBEEAQEfCQc?= =?us-ascii?q?nCxQJCAIEARIIiB4IDb1wAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVIR+ghqCF?= =?us-ascii?q?4UIBZZVAYgWhRSBYoRBjWWIVgEfAQFCghEdgVZyg2ICAhwEAxyBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,342,1444694400"; d="scan'208";a="53792078" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Nov 2015 12:52:29 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tAPCqT8q021180 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 12:52:29 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 Nov 2015 06:52:28 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Wed, 25 Nov 2015 06:52:28 -0600 From: "Pascal Thubert (pthubert)" To: Jouni Korhonen , "" , "draft-ietf-hip-rfc6253-bis@tools.ietf.org" , "Bernie Volz (volz)" Thread-Topic: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05 Thread-Index: AQHRJt24vYdSgT3joU2j9UNAN2i6CJ6sYS1A Date: Wed, 25 Nov 2015 12:52:20 +0000 Deferred-Delivery: Wed, 25 Nov 2015 09:59:35 +0000 Message-ID: <9df3058fc43f444c8560059a51473816@XCH-RCD-001.cisco.com> References: <56549E68.7070701@gmail.com> In-Reply-To: <56549E68.7070701@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.6.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05 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, 25 Nov 2015 12:52:32 -0000 My additions to Jouni's review since I am also assigned INT directorate rev= iewer for draft-ietf-hip-rfc6253-bis-05: The document reads well, appreciate that. Generic problem:=20 I see how the requester and the registrar can cancel registrations, but is = unclear how a registrar can withdraw a service. I think this should be clarified before publication, with possibly a valida= tion from the WG. More detailed stuff: 3. HIP Registration Extension Overview This document does not specify the means by which a requester discovers the availability of a service, or how a requester locates a registrar. >> The fact that the lookup is not included in the method means potentially= an additional round trip than if R1 could be send to some anycast address = (like DHAAD is in MIPv6). 3.1. Registrar Announcing Its Ability A requester that is capable and willing to act as a registrar vis-a-vis a specific requester SHOULD include a REG_INFO parameter in the R1 packets it sends during all base exchanges with that requester.=20 Also, the R1 could contain a certificate and a some signed stuff that inclu= des I1 to prove it is whom the requester thinks.=20 >> Why is this a SHOULD? I expected a MUST otherwise nothing happens, right= ? >> I mean, the potential not to do it is contained in the words capable and= willing. If services can be provided later, it SHOULD send UPDATE packets indicating the current set of services available in a new REG_INFO parameter to all hosts it is associated with. >> And if the registrar is no more capable (maybe temporarily) SHOULD it al= so UPDATE with a REG_INFO? If the requester does not have any suitable certificates, it SHOULD send the registration request without the CERT parameter to test whether the registrar accepts the request based on the host's identity. >> The Registrar could have hinted the required Authentication method in R1= , per service type if needed. >> This is wasting a round trip if the host does not have a certificate and= has to try multiple registrars in a row. the registrar MUST proceed with the registration. >> MUST looks strong language now; e.g. what of the registrar can no more f= or whatever reason? >> I'd not have expected lowercase "may". Failure Type 0 >> Not that I mind so much but sometime it is good to avoid the value '0'.= =20 >> This makes software easier to test (did my code write the damn field ?) = etc...=20 If the registrar requires further authorization and the requester has additional credentials available, the requester SHOULD try to register again with the service after the HIP association has been established. >> again the uppercase is not necessarily warranted. A lowercase "may" wou= ld do.=20 >> It may have other options like going somewhere else. The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. >> Is this me or is the 'or more' is pointless?=20 >> the registrar receiving more than one REG_REQUEST is a protocol error an= d the traditional way is to drop the packet. The minimum lifetime both registrars and requesters MUST support is 10 seconds, while they SHOULD support a maximum lifetime of 120 seconds, at least. >> I agree that there needs to be boundaries. But this text looks inconsist= ent with: The requester MUST be prepared to receive any registration lifetime, including ones beyond the minimum and maximum lifetime indicated in the REG_INFO parameter. A zero lifetime is reserved for canceling purposes. >> This text should be in section 4.1 I hope this helps, Pascal > -----Original Message----- > From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Jouni Korhon= en > Sent: mardi 24 novembre 2015 18:29 > To: ; draft-ietf-hip-rfc6253- > bis@tools.ietf.org; Bernie Volz (volz) > Subject: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05 >=20 > I reviewed this document as part of the Int-Dir reviews activity. You sho= uld treat > the comments as any IETF LC comments. >=20 > The document is ready for piblication with minor nits. My comments follo= w the > line numbering as seen in IDnits. >=20 > Editorial Comments: >=20 > * Line 28: s/extends/updates > * Line 72: s/extends/updates > * Line 269: replaces or obsoletes.. typically when following the > cover page terminology I would prefer "obsoletes" here as well. > * Line 287: a verb is missing? e.g. "..are discussed.." etc > * Lines 264-265: I cannot parse this sentence. "in order" meanning > the 2 octets contain first Cert Group and followed by Cert ID? > Please clarify. > * Figure line 136: although text is clear about the padding > behavior the figure makes one think there is always 2 octets > of padding.. suggest coming up with slightly different ascii > art here. >=20 > Other (substantial) comments: >=20 > * Lines 95-98: I find the recommendation of not including the CERT > in the I1 packet odd. Actually, allowing it in I1 is a bit odd in > general. A well behaving initiator would not do that unless it has > a very good reason to do so but a hostile initiator would most > certainly do that just to cause more processing at the responder. > Why the CERT has to be possible in I1 if it is not recommended to > be added in the first place? > * Lines 103-14: The "MUST be set" text is a bit strange. Why not > stating the same for Cert ID and type as well? Actually as these > fields are in fixed positions and cannot be "optionally" left out. > I suggest doing some rewording here. > * Section 7 security considerations does not discuss the possible > hostile use of CERT payload in I1 packet.. this is already hinted > in Section 2. >=20 > - Jouni >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir From nobody Wed Nov 25 11:50:33 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 8CC701B2EE9 for ; Wed, 25 Nov 2015 11:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 65Pg3d-KC9Hl for ; Wed, 25 Nov 2015 11:50:26 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 EA9FF1B2EE6 for ; Wed, 25 Nov 2015 11:50:25 -0800 (PST) Received: by pabfh17 with SMTP id fh17so68441173pab.0 for ; Wed, 25 Nov 2015 11:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=joKi5+d9bpQo4JQZHkBEWIKrqdgbZxxDc9dETp6SXTM=; b=YuHMA8eIJ0h6npQePXt5iWPJn2WJhehbMCo/WBq+JxlArZK4npDtQiDPtc7Wl8NGtV 6lthiK9mY34uO4tddLlwIMMv9mkFvp7Qwyg2fA771eNap1B0/jRLwRGf7gA6XJsy9K8c Dal/SdlPBHd5BPyclFYpwqpeC/0E5Mne1weh3/GWHMLU90qx1/zp2IjA2iY/vNIC3x8r 7IMd7yJMd+IIIxxjjFDiedbGUaa58nlKNdKyX4k5oJ/r4pUHT9NnPspjzrH1MALToJPP 5is8rMPiqJ4rZbw0RlinOpEwH+eVhOdxqQ+5TeppBkRcaxqQk9hLdYccpkFs9oGW2X51 KahQ== X-Received: by 10.66.246.137 with SMTP id xw9mr54691529pac.31.1448481025636; Wed, 25 Nov 2015 11:50:25 -0800 (PST) Received: from [10.16.84.195] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id lg14sm23086929pab.45.2015.11.25.11.50.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Nov 2015 11:50:25 -0800 (PST) To: "" , draft-ietf-hip-rfc5203-bis@tools.ietf.org, "volz@cisco.com" From: Jouni Korhonen Message-ID: <56561100.7010207@gmail.com> Date: Wed, 25 Nov 2015 11:50:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Int-dir] Int-Dir review of draft-ietf-hip-rfc5203-bis-09 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, 25 Nov 2015 19:50:30 -0000 Authors, I was appoited to do Int-Dir review of draft-ietf-hip-rfc5203-bis-09. You should treat these comments as any Last Call comments. I found the document well written and got only few clarifying questions. * In Section 4.1. the lifetime calculation does not actually define whether integer or floating point math is used. Depending on these or the lack of rounding guidance the lifetimes may end up to very different numbers. * Section 5. should probably have some text describing what happens if the certificate used to authz the service expires or gets revocated during the registration lifetime. Specifically what the registrar is supposed to do. Some obvious IDnits: == Outdated reference: A later version (-05) exists of draft-ietf-hip-rfc6253-bis-02 == Outdated reference: A later version (-09) exists of draft-ietf-hip-native-nat-traversal-08 - Jouni From nobody Thu Nov 26 06:22: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 4A1991A904B; Thu, 26 Nov 2015 01:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-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 5Lm7FqckEQTb; Thu, 26 Nov 2015 01:10:43 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 79A121B378C; Thu, 26 Nov 2015 01:10:42 -0800 (PST) Received: from LIUXD (unknown [218.241.103.218]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMEyDzFZWKkDNCA--.65493S3; Thu, 26 Nov 2015 17:10:27 +0800 (CST) From: "Yu Fu" To: "'Carlos Pignataro \(cpignata\)'" , , References: In-Reply-To: Date: Thu, 26 Nov 2015 17:10:33 +0800 Message-ID: <000c01d1282a$4ebb24c0$ec316e40$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D1286D.5CDE64C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHRDPv8uQQq0547Q0u+jVdDMLjGGp6uIPpQ Content-Language: zh-cn X-CM-TRANSID: AQAAf0ApMEyDzFZWKkDNCA--.65493S3 X-Coremail-Antispam: 1UD129KBjvJXoWxXr4fuF1fWFWxCFWkKFyDJrb_yoW5tr45pF s7W3y5Kryktr1xJrn7uF48Wa4Yka9agFWagFyDCr1UAws8G3Z2yryF9ay5AayDGryfWF48 Zw12vr93Wan5ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202 j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I8CrV CF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvj eVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GFWl42xK82IYc2 Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE 42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87 Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07boUDXUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: X-Mailman-Approved-At: Thu, 26 Nov 2015 06:22:31 -0800 Cc: draft-ietf-softwire-dslite-mib.all@ietf.org Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-dslite-mib-11 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, 26 Nov 2015 09:10:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01D1286D.5CDE64C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, =20 Thanks for your review. We have updated our draft based on you comments. = Please see my reply inline. =20 >>CMP: Should the above say that this only supports IPv4-in-IPv6? =20 [Yu]=EF=BC=9AYes, it only supports IPv4 in IPv6 tunnel. =20 >>CMP: Might be useful to add that this is because the tunnel is not = point-to-point. =20 [Yu]: We have added it in the updated version. =20 >>CMP:Has this been checked? = https://www.ietf.org/iesg/statement/writable-mib-module.html =20 [Yu]:It has been reviewed by mib doctor during the WGLC. I am not sure = is that could be considered as it has been checked? =20 >>CMP: I only saw one read-write and no read-create. Are there = =E2=80=9Ca number of =E2=80=A6=E2=80=9D? =20 [Yu]:We have updated this sentence to =E2=80=9CThere is only one objects = defined in this MIB module=E2=80=A6..=E2=80=9D =20 >>CMP: Why is RFC 2119 Informative? =20 [Yu]: We have changed it into Normative References in the new version. =20 Thanks again =20 BR Yu =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: Friday, October 23, 2015 3:01 AM To: int-dir@ietf.org; int-ads@ietf.org Cc: draft-ietf-softwire-dslite-mib.all@ietf.org Subject: Int-Dir - Review of draft-ietf-softwire-dslite-mib-11=20 =20 Hi, =20 I am an assigned INT directorate reviewer for = draft-ietf-softwire-dslite-mib-11. These comments were written primarily = for the benefit of the Internet Area Directors. Document editors and = shepherd(s) should treat these comments just like 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/intarea.html. =20 This document defines MIB objects to manage DS-Lite solutions, and = targets the Standards Track. =20 Please find some minor review comments: =20 5. Difference from the IP tunnel MIB and NATV2-MIB =20 Notes: According to section 5.2 of [RFC6333], DS-Lite only defines IPv4 in IPv6 tunnels at this moment, but other types of encapsulation could be defined in the future. So this DS-Lite MIB only supports IP in IP encapsulation, if another RFC defined other tunnel types in the future, this DS-Lite MIB will be updated then. =20 CMP: Should the above say that this only supports IPv4-in-IPv6? =20 The implementation of the IP Tunnel MIB is required for DS-Lite. The tunnelIfEncapsMethod in the tunnelIfEntry should be set to dsLite("xx"), and a corresponding entry in the DS-Lite module will exist for every tunnelIfEntry with this tunnelIfEncapsMethod. The tunnelIfRemoteInetAddress must be set to "::=E2=80=9D. =20 CMP: Might be useful to add that this is because the tunnel is not = point-to-point. =20 dsliteAFTRAlarmConnectNumber OBJECT-TYPE SYNTAX Integer32 (60..90) MAX-ACCESS read-write =20 CMP: Has this been checked? = https://www.ietf.org/iesg/statement/writable-mib-module.html =20 9. Security Considerations There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create.=20 =20 CMP: I only saw one read-write and no read-create. Are there =E2=80=9Ca = number of =E2=80=A6=E2=80=9D? =20 12.2. Informative References =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . =20 CMP: Why is RFC 2119 Informative? =20 I hope these are useful! =20 Thanks, =20 =E2=80=94 Carlos. ------=_NextPart_000_000D_01D1286D.5CDE64C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Carlos,

 =

Thanks for = your review. We have updated our draft based on you comments. Please see = my reply inline.

 =

>>CMP= : Should the above say that this only supports = IPv4-in-IPv6?

 =

[Yu]= =EF=BC=9AYes, = it only = supports IPv4 in IPv6 tunnel.

 =

>>CMP= : Might be useful to add that this is because the tunnel is not = point-to-point.

 =

[Yu]: We = have added it in the updated version.

 =

>>CMP= :Has this been checked? htt= ps://www.ietf.org/iesg/statement/writable-mib-module.html<= /span>

 =

[Yu]:It = has been reviewed by mib doctor during the WGLC. =C2=A0I am not sure is = that could be considered as it has been checked?

 =

>>CMP= : I only saw one read-write and no read-create. Are there =E2=80=9Ca = number of =E2=80=A6=E2=80=9D?

 =

[Yu]:We = have updated this sentence to =E2=80=9CThere is only one objects defined = in this MIB module=E2=80=A6..=E2=80=9D

 =

>>CMP= : Why is RFC 2119 Informative?

 =

[Yu]: We = have changed it into Normative = References in the new version.

 

Thanks = again

 =

BR

Yu

 

From:= Carlos = Pignataro (cpignata) [mailto:cpignata@cisco.com] =
Sent: Friday, October 23, 2015 3:01 AM
To: int-dir@ietf.org; int-ads@ietf.org
Cc: draft-ietf-so= ftwire-dslite-mib.all@ietf.org
Subject: Int-Dir - Review = of draft-ietf-softwire-dslite-mib-11 =

 

Hi,

 

I am an assigned INT directorate = reviewer for draft-ietf-softwire-dslite-mib-11. These comments were = written primarily for the benefit of the Internet Area Directors. = Document editors and shepherd(s) should treat these comments just = like 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.iet= f.org/iesg/directorate/intarea.html.

=

 

This document defines MIB objects = to manage DS-Lite solutions, and targets the Standards = Track.

 

Please find some minor review = comments:

 

5.  Difference from the IP = tunnel MIB and NATV2-MIB

 

   Notes: According = to section 5.2 of [RFC6333], DS-Lite only = defines

   IPv4 in IPv6 tunnels at this moment, but other = types of encapsulation

   could be defined in = the future.  So this DS-Lite MIB only supports = IP

   in IP encapsulation, if another RFC defined = other tunnel types in the

   future, this DS-Lite = MIB will be updated then.

 

CMP: Should the above say that this = only supports IPv4-in-IPv6?

 

   The implementation of = the IP Tunnel MIB is required for DS-Lite. =  The

   tunnelIfEncapsMethod in the tunnelIfEntry = should be set to

  =  dsLite("xx"), and a corresponding entry in the DS-Lite = module will

   exist for every tunnelIfEntry with this = tunnelIfEncapsMethod.  The

  =  tunnelIfRemoteInetAddress must be set to = "::=E2=80=9D.

 

CMP: Might be useful to add that = this is because the tunnel is not = point-to-point.

 

      = dsliteAFTRAlarmConnectNumber = OBJECT-TYPE

         SYNTAX Integer32 = (60..90)

         MAX-ACCESS = read-write

 

 

9.  Security = Considerations

   There are a number of management objects = defined in this MIB module

   with a MAX-ACCESS = clause of read-write and/or = read-create. 

 

CMP: I only saw one read-write and = no read-create. Are there =E2=80=9Ca number of = =E2=80=A6=E2=80=9D?

 

12.2.  Informative = References

 

   [RFC2119] =  Bradner, S., "Key words for use in RFCs to = Indicate

              = Requirement Levels", BCP 14, RFC = 2119,

              DOI = 10.17487/RFC2119, March 1997,

 

CMP: Why is RFC 2119 = Informative?

 

I hope these are = useful!

 

Thanks,

 

=E2=80=94 = Carlos.

------=_NextPart_000_000D_01D1286D.5CDE64C0-- From nobody Thu Nov 26 06:22:36 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 327A91B3793; Thu, 26 Nov 2015 01:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-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 BNjVMPQBXcdr; Thu, 26 Nov 2015 01:12:53 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 15A261B3791; Thu, 26 Nov 2015 01:12:51 -0800 (PST) Received: from LIUXD (unknown [218.241.103.218]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CJkU0RzVZWIUXNCA--.61429S3; Thu, 26 Nov 2015 17:12:49 +0800 (CST) From: "Yu Fu" To: "'Hui Deng'" References: In-Reply-To: Date: Thu, 26 Nov 2015 17:12:56 +0800 Message-ID: <001101d1282a$a33aeb20$e9b0c160$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D1286D.B15E2B20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdEO+iJEsvJ9guqgSXa0Fm6mfi8XdwUSZENQ Content-Language: zh-cn X-CM-TRANSID: AQAAf0CJkU0RzVZWIUXNCA--.61429S3 X-Coremail-Antispam: 1UD129KBjvJXoWxXw1xZr1fCF1DKFy3Ar45trb_yoW5uw48p3 98twsxKrWkAw4UJrn29w4kWa4SvF4kAayUtFy5Wry2yr98G3W0yr4xK39rtF18ur109a1Y yr45Zr45ZayUGaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB2b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202 j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Gr0_Xr1l5I8CrV CF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvj eVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GFWl42xK82IYc2 Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE 42xK8VAvwI8IcIk0rVW3JVWrJr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aV CY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU2txhDUUUU X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: X-Mailman-Approved-At: Thu, 26 Nov 2015 06:22:31 -0800 Cc: draft-ietf-softwire-dslite-mib.all@ietf.org, int-ads@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Int-Dir - Review of draft-ietf-softwire-dslite-mib-11 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, 26 Nov 2015 09:12:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01D1286D.B15E2B20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Hui, =20 Thank you for your thorough review for this draft. We have updated the = draft based on your comments, please see my reply in line. =20 >>2) In section 6.1.1, =E2=80=9CBecause some objects defined in the IP = Tunnel MIB are not read-write and read-only, a few new objects are = defined in DS- Lite MIB.=E2=80=9D What is the = =E2=80=9Cread-write=E2=80=9D and =E2=80=9Cread-only=E2=80=9D? If it is a = special meaning words in MIB, it need a quotation mark here. =20 [Yu]: We have updated this sentence to =E2=80=9CBecause some objects = defined in the IP Tunnel MIB are not readable=E2=80=9D. =20 >>3) In page 8,=20 >>=E2=80=9CdsliteTunnelAddressType OBJECT-TYPE >>SYNTAX InetAddressType >>MAX-ACCESS not-accessible >>STATUS current >>DESCRIPTION >>" This object MUST be set to the value of ipv6(2). >>It describes the address type of the IPv4-in-IPv6 >>tunnel initiator and endpoint." >>::=3D { dsliteTunnelEntry 1 }=E2=80=9D =20 >>There=E2=80=99s no scenario requiring ipv6z(4)? It needs a REFERENCE = to RFC 4001 in this object definition. =20 [Yu]: In DS-Lite scenario, there is no requirement for ipv6z(4) as it is = defined for non-global IPv6 address. We have added the REFFERENCE to RFC 4001. =20 =20 >>4) In page 10, DsliteNATBindEntry: I think = dsliteNATBindMappingExtAddressType and = dsliteNATBindMappingIntAddressType should just be = dsliteNATBindMappingAddressType and apply to both. If all address = objects in the row are of the same type, you only need one type object. =20 [Yu]:Because the dsliteNATBindMappingExtAddressType is the index of the = dsliteNATBindEntry, it can=E2=80=99t merge = dsliteNATBindMappingExtAddressType and = dsliteNATBindMappingIntAddressType into one. =20 >>5) In page 11, it needs a REFERENCE to RFC 4001 in the definition of = dsliteNATBindMappingExtPort. =20 [Yu]: Done. =20 >>6) In page 12, it need some description to describe = =E2=80=9CendpointIndependent, addressDependent, = addressAndPortDependent=E2=80=9D in more detail in the DESCRIPTION of = dsliteNATBindMappingMapBehavior.=20 The same comments to the =E2=80=9Carbitrary, paired=E2=80=9D in = dsliteMATBindMappingAddressPooling. A REFERENCE is also needed. =20 [Yu]: Done. =20 >>7) In page 14, it needs to define a DEFVAL value for = dsliteAFTRAlarmConnectionNumber. =20 [Yu]: Yes, we have added a DEFVAL value into the definition of = dsliteAFTRAlarmConnectionNumber. =20 >>8) Whether dsliteStatisticSubscriberIdex is enough or direct to get = subscribers' information?=20 =20 [Yu]: As Natv2SubsicriberIndex defined in NATV2-MIB, =E2=80=9CA unique = value, greater than zero, for each NAT instance in the managed = system=E2=80=A6=E2=80=A6If a NAT instance is deleted, its assigned index = value MUST NOT be assigned to another NAT instance at least until = reinitialization of the entity's management system=E2=80=9D. The = dsliteStatisticSubscriberIdex imported Natv2SubsicriberIndex from the = NATV2-MIB, it is enough to direct to get the subscribers=E2=80=99 = information.=20 =20 >>9) I am not very sure what is dsliteStatisticIpv6Session mean? As for = IPv6 traffic, there seems no mapping.=20 =20 [Yu]: This object is defined to count the normal IPv6 session because = DS-Lite can offer both IPv4 and IPv6 connectivity. =20 >>10)Whether there has requirement to support multiple instances in = DS-Lite?=20 =20 [Yu]: Yes, we have defined dsliteNATBindMappingInstanceIndex to support = multiple instance. It imported Natv2InstanceIndex defined in NATV2-MIB. =20 Thanks again for your kind review. =20 BR Yu ------=_NextPart_000_0012_01D1286D.B15E2B20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Hui,

 

=

Thank you for your thorough = review for this draft. We have updated the draft based on your comments, = please see my reply in line.

 

=

>>2) In section = 6.1.1,  =E2=80=9CBecause some objects defined in the IP Tunnel MIB = are not read-write and read-only, a few new objects are defined in DS- = Lite MIB.=E2=80=9D What is the =E2=80=9Cread-write=E2=80=9D and = =E2=80=9Cread-only=E2=80=9D? If it is a special meaning words in MIB, it = need a quotation mark here.

 

=

[Yu]: We have updated this = sentence to =E2=80=9CBecause some objects defined in the IP Tunnel MIB = are not readable=E2=80=9D.

 

=

>>3) In page = 8, 

>>=E2=80=9CdsliteTunne= lAddressType OBJECT-TYPE

>>SYNTAX = InetAddressType

>>MAX-ACCESS = not-accessible

>>STATUS = current

>>DESCRIPTION

>>" This object = MUST be set to the value of ipv6(2).

>>It describes the = address type of the IPv4-in-IPv6

>>tunnel initiator = and endpoint."

>>::=3D { = dsliteTunnelEntry 1 }=E2=80=9D

 

=

>>There=E2=80=99s no = scenario requiring ipv6z(4)?  It needs a REFERENCE to RFC 4001 in = this object definition.

 

=

[Yu]: In DS-Lite scenario, = there is no requirement for ipv6z(4) as it is defined for non-global = IPv6 address.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 We have added the REFFERENCE to RFC = 4001.

 

=

 

=

>>4) In page 10, = DsliteNATBindEntry: I think dsliteNATBindMappingExtAddressType and = dsliteNATBindMappingIntAddressType should just be = dsliteNATBindMappingAddressType and apply to both. If all address = objects in the row are of the same type, you only need one type = object.

 

=

[Yu]:Because the = dsliteNATBindMappingExtAddressType is the index of the = dsliteNATBindEntry, it can=E2=80=99t merge = dsliteNATBindMappingExtAddressType and = dsliteNATBindMappingIntAddressType into one.

 

=

>>5) In page 11, it = needs a REFERENCE to RFC 4001 in the definition of = dsliteNATBindMappingExtPort.

 

=

[Yu]: = Done.

 

=

>>6) In page 12, it = need some description to describe =E2=80=9CendpointIndependent, = addressDependent, addressAndPortDependent=E2=80=9D in more detail in the = DESCRIPTION of = dsliteNATBindMappingMapBehavior. 

 The same comments to = the =E2=80=9Carbitrary, paired=E2=80=9D in = dsliteMATBindMappingAddressPooling. A REFERENCE is also = needed.

 

=

[Yu]: = Done.

 

=

>>7) In page 14, it = needs to define a DEFVAL value for = dsliteAFTRAlarmConnectionNumber.

 

=

[Yu]: Yes, we have added a = DEFVAL value into the definition of = dsliteAFTRAlarmConnectionNumber.

 

=

>>8) Whether = dsliteStatisticSubscriberIdex is enough or direct to get subscribers' = information? 

 

=

[Yu]: As = Natv2SubsicriberIndex defined in NATV2-MIB, =E2=80=9CA unique value, = greater than zero, for each NAT instance=C2=A0 in the managed = system=E2=80=A6=E2=80=A6If a NAT instance is deleted, its assigned index = value MUST NOT be assigned to another NAT instance at least until = reinitialization of the entity's management system=E2=80=9D. The = dsliteStatisticSubscriberIdex imported Natv2SubsicriberIndex from the = NATV2-MIB,=C2=A0 it is enough to direct to get the subscribers=E2=80=99 = information.

 

=

>>9) I am not very = sure what is dsliteStatisticIpv6Session mean? As for IPv6 traffic, there = seems no mapping. 

 

=

[Yu]: This object is = defined to count the normal IPv6 session because DS-Lite can offer both = IPv4 and IPv6 connectivity.

 

=

>>10)Whether there = has requirement to support multiple instances in = DS-Lite? 

 

=

[Yu]: Yes, we have defined = dsliteNATBindMappingInstanceIndex to support multiple instance. It = imported Natv2InstanceIndex defined in = NATV2-MIB.

 

Thanks again = for your kind review.

 

=

BR

Yu

------=_NextPart_000_0012_01D1286D.B15E2B20--