From nobody Wed Jul 1 01:34:58 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5220C1ACD2B for ; Tue, 30 Jun 2015 08:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zA0adXBEyQIA for ; Tue, 30 Jun 2015 08:52:11 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 159A81ACD2D for ; Tue, 30 Jun 2015 08:52:11 -0700 (PDT) Received: by pdjd13 with SMTP id d13so8376767pdj.0 for ; Tue, 30 Jun 2015 08:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=xhKkrm2Y5MM9S2cSYZtDhVZe2j+VhJCosRq02XeJtAk=; b=AJyn20IQyxWUQRvI+PTG/ra0ceA2y4/Jtp/YAWCkd5GMibBRjDo32BOVYMqS6hZtWh 7tdV34tZM2Yyth3qPF/kBCQ2/qDCNu4YQIBCFcHcCFd8IpvTyQ2XsX3gdfQVxh1y75L1 U2z7E2pKEmJbQGFfpfRQuXkSnoOZfbjdFUb10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xhKkrm2Y5MM9S2cSYZtDhVZe2j+VhJCosRq02XeJtAk=; b=i85RHGBzas2Hq8sLpQgT0Da4Ot4oSfkuKQXkkl+1+dhWa98cA3FlobqiYID871qCkv XnpWcCaW/yhnAzosGgpIk4CQBRbjpz1KeuGWlBsVBJw4axNR1iAlrLMIt6o4yXn6MJtv o/voZDuO8TlO01Y6EJ9kjiCBcMM9Qr4Zg1ae/LB/+e1IROqyRVfyZ+Yc2J/KnQ4ncW+7 gpQ2pHlYKEc6bc2s2G9b4IxpdBcXtUXk3xKHVcec/PrY4YZEEBVck8qpyOoJbfmSs1kR ayOEwxhufyu4QzL4TXB+F045g9JTbw+N91KLIjKLw0eSgNURNt8iHqOnDHGr+IJhGjw7 8ExA== X-Gm-Message-State: ALoCoQlFThWhDWggNXsSuvgpQXw4CQ/RG+cCibVV4kUtO8f8zLOZUiYTF3sDf6l0iW0H6U3MR3Cg X-Received: by 10.66.229.65 with SMTP id so1mr44785952pac.92.1435679530432; Tue, 30 Jun 2015 08:52:10 -0700 (PDT) Received: from [172.22.240.20] ([162.210.130.3]) by mx.google.com with ESMTPSA id ud3sm45982309pbc.10.2015.06.30.08.52.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 08:52:08 -0700 (PDT) To: Jamal Hadi Salim , draft-rtg-dt-encap References: From: Erik Nordmark Message-ID: <5592BB23.1040404@arista.com> Date: Tue, 30 Jun 2015 17:52:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 01:34:56 -0700 Cc: "rtg-dir@ietf.org" , Tom Herbert Subject: Re: [RTG-DIR] Bouncing email address X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 15:52:13 -0000 On 6/30/15 2:26 PM, Jamal Hadi Salim wrote: > Someone needs to change Tom's email address on the alias > draft-rtg-dt-encap@tools.ietf.org > I'm about to submit an updated draft, which will list Tom's current email address. As a result of that I assume the tools.ietf.org mailing list will be updated (or more likely, a new one will be created since the updated draft will be a WG document i.e. with a different name.) Erik > > cheers, > jamal > > ---------- Forwarded message ---------- > From: *Mail Delivery System* > > Date: Tue, Jun 30, 2015 at 8:21 AM > Subject: Undelivered Mail Returned to Sender > To: hadi@mojatatu.com > > > This is the mail system at host ietfa.amsl.com . > > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to postmaster. > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > The mail system > > > (expanded from > >): host > aspmx.l.google.com [74.125.129.26] said: > 550 5.2.1 The email account that > you tried to reach is disabled. fm2si69908050pab.148 - gsmtp (in > reply to > RCPT TO command) > > Final-Recipient: rfc822; therbert@google.com > Original-Recipient: rfc822; expand-draft-rtg-dt-encap@virtual.ietf.org > > Action: failed > Status: 5.2.1 > Remote-MTA: dns; aspmx.l.google.com > Diagnostic-Code: smtp; 550 5.2.1 The email account that you tried to > reach is > disabled. fm2si69908050pab.148 - gsmtp > > > > > Return-Path: > Received: by ietfa.amsl.com (Postfix, from userid 65534) > id EB4DD1A8AC0; Tue, 30 Jun 2015 05:21:24 -0700 (PDT) > X-Original-To: xfilter-draft-rtg-dt-encap@ietfa.amsl.com > Delivered-To: xfilter-draft-rtg-dt-encap@ietfa.amsl.com > Received: from localhost (ietfa.amsl.com [127.0.0.1]) > by ietfa.amsl.com (Postfix) with ESMTP id BDAB91A8ABF > for ; > Tue, 30 Jun 2015 05:21:24 -0700 (PDT) > 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, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 Zgc9bITV4UBF > for ; > Tue, 30 Jun 2015 05:21:17 -0700 (PDT) > Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org > [IPv6:2001:1890:123a::1:2a]) > (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 BD1491A8AB9 > for ; Tue, 30 Jun 2015 05:21:17 -0700 (PDT) > Received: from mail-oi0-f41.google.com ([209.85.218.41]:36068) > by zinfandel.tools.ietf.org with esmtps > (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) > (envelope-from ) id 1Z9uXJ-0003Fu-Qz > for draft-rtg-dt-encap@tools.ietf.org; Tue, 30 Jun 2015 05:21:17 -0700 > Received: by oift81 with SMTP id t81so5715995oif.3 > for ; Tue, 30 Jun 2015 05:21:06 -0700 (PDT) > X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=1e100.net; s=20130820; > h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc > :content-type; > bh=1yHbMle1Rw4ke7dtiA+yhAbctxNl0ZOtjWDlNRv7lYU=; > b=QRZKcevSQRQL61zITn2tnNu50OIQwVD7pvG/QCCZMKUa1exkhi583bEkeg+GQW6l6O > EjIx7Ac9JZWbKSCEUd0x9X83Fmpkj57W+FzaG7hwuo805if/C/VBeZbsRmb+U5MyA9en > HwfwkDmub5GgPmUpLxv4eZ5YL7WdnJPjRdTx6IJJoDfQBw4fO4mSmPHpmlUxvmsQwZfK > G1XzaOB0GFTSpWCJSLEcpPbQBSNGSO9ShYDDs8ttDOfFv+E52Bk1KN9+xpCfMeHOrpQS > CYZWAvOo9iKNMKSyCK/acmf8ytvKZT0yd8o1F6aZ8LMkt2XM0vgXIzrgHCU+oiZ1eSJq > 849w== > X-Gm-Message-State: ALoCoQnUVMN7PuUS3ehSNf3+DkDKGE5ifM8VKGePiAQMNp0tUU2XP4jApMKHVV0moeHuS7wJxI5V > X-Received: by 10.182.153.197 with SMTP id vi5mr19101894obb.28.1435666865937; > Tue, 30 Jun 2015 05:21:05 -0700 (PDT) > MIME-Version: 1.0 > Received: by 10.202.88.194 with HTTP; Tue, 30 Jun 2015 05:20:46 -0700 (PDT) > From: Jamal Hadi Salim > Date: Tue, 30 Jun 2015 08:20:46 -0400 > Message-ID: > To: "rtg-ads@tools.ietf.org" > Cc: "rtg-dir@ietf.org" , draft-rtg-dt-encap@tools.ietf.org > Content-Type: multipart/mixed; boundary=089e014953208fa4b00519bb3d5b > X-SA-Exim-Connect-IP: 209.85.218.41 > X-SA-Exim-Rcpt-To: draft-rtg-dt-encap@tools.ietf.org > X-SA-Exim-Mail-From: hadi@mojatatu.com > Subject: RtgDir review: draft-rtg-dt-encap-02 > X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) > X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) > Resent-To: draft-rtg-dt-encap@ietf.org > List-ID: > Resent-Message-Id: <20150630122117.BD1491A8AB9@ietfa.amsl.com> > Resent-Date: Tue, 30 Jun 2015 05:21:17 -0700 (PDT) > Resent-From: hadi@mojatatu.com > Archived-At: From nobody Mon Jul 6 22:25:30 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3544F1A8A84; Mon, 6 Jul 2015 22:25:28 -0700 (PDT) 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 gsaT9npwhz9R; Mon, 6 Jul 2015 22:25:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146D61A8A83; Mon, 6 Jul 2015 22:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21325; q=dns/txt; s=iport; t=1436246725; x=1437456325; h=from:to:cc:subject:date:message-id:mime-version; bh=/XpZkQhEk9EfTxzat+EO3blEKtdm+NRSXVTeV/tc71E=; b=cE6EqrYdH42wEGUgN/p03dvxZt6xHsVfoVhVI92AmMWT2g2sFgmHQbXD CYtw+woCkHHeeBw6sh6evw/tAwrDcMs8wo2sWYTqKl/HPGm1L/MolF9RI pTE+RxUH7UGL1ZT0CwP2oFEn2Iiq0ZXtbJhCFefo2KX/TlkW1n+aIuO++ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApCAB7YptV/4ENJK1cgkVNVGABBb01giGFdwKBRjsRAQEBAQEBAYEKhCUBBC1BCxIBHA5WJgEEDg2IJg3KHQEBAQEBAQEBAQEBAQEBAQEBAQEBGI94KCARgx6BFAWRNIJkAYRhglqFZ0WDUpMIERWCCR+BU3CBAyQfgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,420,1432598400"; d="scan'208,217";a="9439550" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jul 2015 05:25:20 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t675PKGD012901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 05:25:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 00:25:19 -0500 From: "Les Ginsberg (ginsberg)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-homenet-dncp-07.txt Thread-Index: AdC4dM67HZyS0u8fSh2s5cmMOaEiiw== Date: Tue, 7 Jul 2015 05:25:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.145.182] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F59489CEBxmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "homenet@ietf.org Group" , "draft-ietf-homenet-dncp.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-homenet-dncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 05:25:28 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F59489CEBxmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as a Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts a= s they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing = ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-homenet-dncp-07 Reviewer: Les Ginsberg Review Date: July 6, 2015 IETF LC End Date: Seems to have already occurred?? Intended Status: Standard Major Issues: My biggest concern is that the document - and its companion HNCP - are not yet mature enough to be doing last call. What is being defined here is a "state synchronization protocol" which is used within the context of a "parent protocol" (most interestingly a routing protocol for the homenet context) and which depends upon another configuration protocol (presumably HNCP) to fully define the behavior. Judging from the review comments provided by others (notably Thomas Clausen= 's detailed review) and the continued discussion on the mailing list it has no= t yet been demonstrated that the specification is clear enough and robust eno= ugh for implementations to meet all the requirements and interoperate. This is not to suggest that you are on the wrong track - but given the dependencies pushing this to last call seems - to put it politely - very "ambitious". I would prefer to see more implementation experience befo= re the document moves to a state where it is presumed to be complete. I still have some trouble calling this a protocol. This is more of a proces= s - or part of a process - which comprises a routing protocol. The process defi= ned here serves to support reliable distribution and synchronization of "state" in an efficient manner under a limited set of conditions. I don't want to quibble too much about the term "protocol" - but I would prefer something l= ike: "a generic set of procedures which - when supplemented by a specific profil= e - define a means of maintaining state synchronization" Some specific comments on points in the draft follow. *************** Section 2 Terminology The term "neighbor" is not defined - but used frequently in the document. The term "peer" is defined as: "another DNCP node with which a DNCP node communicates using a particular local and remote endpoint pair." What I am used to is that the definition above for "peer" is usually associated with the term "neighbor", whereas the term "peer" is more generi= c - it is associated with a node in the network which performs the same functio= ns in the protocol - but is not necessarily a neighbor. Section 4.5 illustrates why I find this confusing as it says "When receiving a Node Endpoint TLV... the remote node MUST be added as a p= eer on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created for it." ??? ******* Section 4.4 - final bullet on Page 11 o Any other TLV: TLVs not recognized by the receiver MUST be silently ignored. Does "ignore mean "discard"? (This is one traditional meaning) If so this seems inappropriate as it is part of the database sent by the node and therefore needs to be retained in order to keep a consistent database. Perhaps "store but do not process" is a more accurate behavioral description? ******************** Section 6.1 Keep-alives Here is another case where the confusion between "peer" and "neighbor" aris= es for me. I would expect that keep-alives are only used between neighbors - but the text here uses the term "peer". Are keep alives sent in multicast-listener mode? From the text in 6.1.2 and 6.1.3 it seems "no" - but I am not certain. ***************** Section 6.2 Support For Dense Broadcast Links If a node is in Multicast-listen+unicast mode does it bear any responsibili= ty for publishing state data in the event the node with highest node identifie= r does not have the latest information? I presume yes - but the text does not discuss this point. Also, does multicast-listener mode affect the way neighbors are advertised? It seems not - so what you are preventing w multicast-listener mode is redundant state updates - but there is no change to the set of neighbors advertised (N*(N-1))? ******************** Section 6.3 Node Data Fragmentation The significance of the MTU limitation is network-wide i.e. a too large Node State TLV generated anywhere in the network could cause problems in some other part of the network. This issue is usually not well understood as experience w IS-IS has shown. More discussion of this point would be helpful. Second paragraph says "The data within Node State TLVs of all fragments MUST be valid..." And if it is not then all fragments are ignored/discarded?? When multiple fragments are used and the location of specific pieces of information move from one fragment to another cases arise where some data temporarily disappears and/or there are two copies. Are you addressing this by expecting that a new set of fragments will not be used at all until all = of them have been received? If so, what happens if you receive some fragments but not all of them? Is there a timeout to be applied here? *************** Section 7 TLVs It says "padding bytes with value zero"". Is "0' a MUST - or is this the usual "SHOULD be transmitted as zero and ignored on receipt"? ******************* Section 7.2.1 Node Endpoint TLV When is this sent and how often? --_000_F3ADE4747C9E124B89F0ED2180CC814F59489CEBxmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected as a Routing Directorate rev= iewer for this draft. The

Routing Directorate seeks to review all routing o= r routing-related drafts as

they pass through IETF last call and IESG review,= and sometimes on special

request. The purpose of the review is to provide = assistance to the Routing ADs.

For more information about the Routing Directorat= e, please see

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use= of the Routing ADs,

it would be helpful if you could consider them al= ong with any other IETF

Last Call comments that you receive, and strive t= o resolve them through

discussion or by updating the draft.

Document: draft-ietf-homenet-dncp-07

Reviewer: Les Ginsberg

Review Date: July 6, 2015

IETF LC End Date: Seems to have already occurred?= ?

Intended Status: Standard

 

Major Issues:

 

My biggest concern is that the document - and its= companion HNCP - are not

yet mature enough to be doing last call. What is = being defined here is a

"state synchronization protocol" which = is used within the context of a

"parent protocol" (most interestingly a= routing protocol for the homenet

context) and which depends upon another configura= tion protocol

(presumably HNCP) to fully define the behavior.

 

Judging from the review comments provided by othe= rs (notably Thomas Clausen's

detailed review) and the continued discussion on = the mailing list it has not

yet been demonstrated that the specification is c= lear enough and robust enough

for implementations to meet all the requirements = and interoperate.

 

This is not to suggest that you are on the wrong = track - but given the

dependencies pushing this to last call seems - to= put it politely -

very "ambitious". I would prefer to see= more implementation experience before

the document moves to a state where it is presume= d to be complete.

 

I still have some trouble calling this a protocol= . This is more of a process -

or part of a process - which comprises a routing = protocol. The process defined

here serves to support reliable distribution and = synchronization of "state"

in an efficient manner under a limited set of con= ditions. I don't want to

quibble too much about the term "protocol&qu= ot; - but I would prefer something like:

 

"a generic set of procedures which - when su= pplemented by a specific profile -

define a means of maintaining state synchronizati= on"

 

Some specific comments on points in the draft fol= low.

 

***************

 

Section 2 Terminology

 

The term "neighbor" is not defined - bu= t used frequently in the document.

The term "peer" is defined as:

 

"another DNCP node with which a DNCP node co= mmunicates using a particular

local and remote endpoint pair."<= /p>

 

What I am used to is that the definition above fo= r "peer" is usually

associated with the term "neighbor", wh= ereas the term "peer" is more generic -

it is associated with a node in the network which= performs the same functions

in the protocol - but is not necessarily a neighb= or.

 

Section 4.5 illustrates why I find this confusing= as it says

 

"When receiving a Node Endpoint TLV... the r= emote node MUST be added as a peer

      on the endpoint an= d a Neighbor TLV (Section 7.3.2) MUST be created

      for it."=

 

???

 

*******

 

Section 4.4 - final bullet on Page 11<= /p>

 

   o  Any other TLV: TLVs not reco= gnized by the receiver MUST be

      silently ignored.<= o:p>

 

Does "ignore mean "discard"? (This= is one traditional meaning)

 

If so this seems inappropriate as it is part of t= he database sent by

the node and therefore needs to be retained in or= der to keep a consistent

database. Perhaps "store but do not process&= quot; is a more accurate behavioral

description?

 

********************

Section 6.1 Keep-alives

 

Here is another case where the confusion between = "peer" and "neighbor" arises

for me. I would expect that keep-alives are only = used between neighbors -

but the text here uses the term "peer".=

 

Are keep alives sent in multicast-listener mode? = >From the text in 6.1.2 and

6.1.3 it seems "no" - but I am not cert= ain.

*****************

Section 6.2 Support For Dense Broadcast Links

 

If a node is in Multicast-listen+unicast mode= does it bear any responsibility

for publishing state data in the event the node w= ith highest node identifier

does not have the latest information? I presume y= es - but the text does not

discuss this point.

 

Also, does multicast-listener mode affect the way= neighbors are advertised?

It seems not - so what you are preventing w multi= cast-listener mode is

redundant state updates - but there is no change = to the set of neighbors

advertised (N*(N-1))?

 

********************

Section 6.3 Node Data Fragmentation

 

The significance of the MTU limitation is network= -wide i.e. a too large

Node State TLV generated anywhere in the network = could cause problems in

some other part of the network. This issue is usu= ally not well understood

as experience w IS-IS has shown. More discussion = of this point would be

helpful.

 

Second paragraph says

 

"The data within Node State TLVs of all frag= ments MUST be valid..."

 

And if it is not then all fragments are ignored/d= iscarded??

 

When multiple fragments are used and the location= of specific pieces of

information move from one fragment to another cas= es arise where some data

temporarily disappears and/or there are two copie= s. Are you addressing this

by expecting that a new set of fragments will not= be used at all until all of

them have been received? If so, what happens if y= ou receive some fragments

but not all of them? Is there a timeout to be app= lied here?

 

***************

Section 7 TLVs

 

It says "padding bytes with value zero"= ".

Is "0' a MUST - or is this the usual "S= HOULD be transmitted as zero and

ignored on receipt"?

 

*******************

Section 7.2.1 Node Endpoint TLV

 

When is this sent and how often?

 

 

 

--_000_F3ADE4747C9E124B89F0ED2180CC814F59489CEBxmbalnx02ciscoc_-- From nobody Tue Jul 7 03:45:19 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E451ACD2F; Mon, 6 Jul 2015 10:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 AnhSmmNMy4zl; Mon, 6 Jul 2015 10:17:36 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 EF76A1ACD7A; Mon, 6 Jul 2015 10:17:34 -0700 (PDT) Received: from [192.168.10.26] ([78.197.168.57]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t66HHSCa002003 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Jul 2015 10:17:29 -0700 To: Jamal Hadi Salim , "rtg-ads@tools.ietf.org" , "rtgwg@ietf.org" References: From: Erik Nordmark Message-ID: <559AB820.9000309@acm.org> Date: Mon, 6 Jul 2015 19:17:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZ0kQyARGYV8WHQ1DD/AosnorUnXTpJchIl0F8ZFY2WO4RgD3quuIPdTfRZepShiAO9mRasSUFg9EEx7jc/YxNb X-Sonic-ID: C;4i6m4AIk5RG8d+fp6CYw6A== M;qKVo4QIk5RG8d+fp6CYw6A== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2015 03:45:18 -0700 Cc: draft-rtg-dt-encap@tools.ietf.org, "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-rtg-dt-encap-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 17:17:39 -0000 On 6/30/15 2:20 PM, Jamal Hadi Salim wrote: > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, > please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve > them through discussion or by updating the draft. > > Document: draft-rtg-dt-encap-02 > Reviewer: Jamal Hadi Salim > Review Date: 6/30/15 (later than requested, sorry) > Intended Status: Informational > WG LC End Date: unknown > > Summary: > > The document has significant good work and recommendations for > encapsulation design. Many years of experience in issues found > with encapsulation deployments are discussed. There are times > where i lost track what the document was about because issues > were being discussed without making recommendations on what is needed > from an encapsulation perspective to deal with those issues; otoh, > a good read is section 18 which would mention an issue and in the > same breath suggests how a design should handle said issue. Jamal, Thanks for your careful review. The design team tried to stay away from potentially contentions discussion by putting firm recommendations in place. Thus currently the document is more of "things to think about" and some tradeoffs, and less of recommendations (and no requirements). Alia has asked for more of a list of choices for the protocol designers, and this is definitely something which folks can help with as we continue this work in the RTGWG. But I also think we need to let the specific in-flight WGs (NVO3, SFC, and BIER) use this document as input but figure out their own tradeoffs and answers. > > The document needs at least one more pass. Agreed. We're looking for more feedback in the RTGWG and also from the WGs that work on the encapsulations. > > I have some minor concerns about this document that I believe are > resolvable. > Annotated comments attached. > o SFC carries service meta-data which might be modified or > unmodified as the packets follow the service path. SFC talks of > Being a little picky, how about: > "SFC carries service meta-data which might be modified as the packets > follow the service path." Agreed - the "unmodified" is a bit to clever (intended to capture that in some cases things might be restored to their original). > 6. Terminology > > The capitalized keyword MUST is used as defined in > http://en.wikipedia.org/wiki/Julmust > > Missing the context on what looks like a high calorie delicious drink. > and should that be https?;-> > Since you are the first to discover the lack of https in that URL, you get a free beverage of your choice (in the bar in Prague if you will be there). > The UDP source port might change over the lifetime of an encapsulated > flow, for instance for DoS mitigation or re-balancing load across > ECMP. > Shouldnt the above statement bear a little more discussion/comment? > What happens to packet ordering then? > I'll add a flag about this. > [Note: For any given bit in BIER (that identifies an exit from the > BIER domain) there might be multiple immediate next hops. The > BIER entropy field is used to select that next hop as part of BIER > processing. The BIER forwarding process may do equal cost load > balancing, but the load balancing procedure MUST choose the same > path for any two packets have the same entropy value.] > "... two packets that have the same ..." > Fixed. > o In the case of IP transport use >=14 bits of UDP source port, plus > outer IPv6 flowid for entropy. > > Looks like a typo. <=14 bits? > No; 14 or 16 depending on the environment. I'll reword as such. > o Reuse Ethernet types - makes it easy to carry existing L2 and L3 > protocols including IPv6, IPv6, and Ethernet. Disadvantages are > that it is a 16 bit number and we probably need far less than 100 > values, and the number space is controlled by the IEEE 802 RAC > with its own allocation policies. > If i understood correctly what "reuse" implies: you are suggesting a new > super-ethertype whose content space will carry an additional type > semantic so you never have to go back to IEEE? > Nope. Rewording as "Use the Ethernet type space" should make it clearer - means going to the IEEE RAC for each new protocol. (Not my idea - IDs have suggested using the Ethernet type space.) I'll apply s/Reuse/Use/ to the next bullets as well. > Many Internet protocols use fixed values (typically managed by the > IANA function) for their next-protocol field. That facilitates > interpretation of packets by middleboxes and e.g., for debugging > purposes, but might make the protocol evolution inflexible. Our > collective experience with MPLS shows an alternative where the label > can be viewed as an index to a table containing processing > instructions and the table content can be managed in different ways. > Would it not be useful to provide a reference here? Just reading this > has questions popping for me - who populates this tag-indexed table of > instructions and could interop be impacted? > The DT added the above text based on comments at the mike from Stewart Bryant. I don't know if there is any reference for the general concept. Anybody else know? In general this implies some control-plane mechanism to populate the table. > o Would it be useful for the IETF come up with a common scheme for > encapsulation protocols? If not each encapsulation can define its > own scheme. > > In my view it would be hard to come up with a ring to rule them all. > There are cases where simple is good enough and asking someone to carry > a christmas tree is the wrong answer. And, yes, there are cases where > (to quote Mencken) the answer is clear, simple and wrong (especially > in one-off-use-cases which then are refactored to fit into square pegs). > My suggestion is to not be too clever in answering the question above. > FWIW the design team just asked the question; someone else gets to answer ;-) But I agree to not blindly forcing some new requirement on common next-header approaches across different WGs. > Reference to Aerolink and the sins committed would be useful. > I googled aerolink and found references of some radio thing running over IP. > Given IP provides the fragmention service above, why is aerolink not capable > of this mechanism? I think there's a simple answer; just reading this didnt help. There are Aerolink internet-drafts. We'll have to go back and see what makes sense as citations. > o Make OAM packets look the same as data packets i.e. the initial > part of the OAM payload has the inner Ethernet, IP, TCP/UDP > headers as a payload. (This approach was taken in TRILL out of > necessity since there is no UDP header.) Any OAM bit in the > encapsulation header must in any case be excluded from the > entropy. > > Does it make sense to have inband OAM info? i.e carried alongside the > data (sure request for a path trace doesnt fit; but inband > healthinfo may fit); in such a case OAM info could be carried in something > like a TLV. > That was the intent. The formatting issue you caught in the bulleted list made this less than clear. > In real deployment, the security of the underlying network may be > considered for determining the level of security needed in the > encapsulation layer. However for the purposes of this discussion, we > assume that network security is out of scope and that the underlying > network does not itself provide adequate or as least uniform security > mechanisms for encapsulation. > I found the above paragraph awkward to read. How about simplifying: > "This document assumes that the underlying network does not itself > provide adequate or at least uniform security mechanisms for encapsulation. > The authors understand that the underlying network security could provide > useful input into the security needs of the encapsulation layer but ignore > it to provide a focus on the discussion." > Let me check whether that was indeed the intent of the text. > o Interaction with packet level security such as IPsec or DTLS > So would IPSEC not be considered "underlying network security"? > Probably not. If you want to ensure e.g. isolation between different tenants then you probably want to avoid know plaintext attacks from one tenant against another. That means that the security associations need to be different for the different tenants' encapsulated traffic. Hence the IPsec policy would need to be aware of how the tenants are described in the encapsulation somehow. Stated differently, can't just apply IPsec pixie dust. Requires some real work to specify the details. > Confidentially is one - but what about integrity of the VNI? That's captured in the Anti-spoofing bullet. > * The criticality of virtual network isolation depends on whether > tenants are trusted or untrusted. In the most extreme cases, > tenants might not only be untrusted but may be considered > hostile. > So would confidentiality then become a requirement to address this? > It is more readable to make suggestions on each issue on what needs > to be done. > I think it is too early to tell. For NVO3-like deployment there has some thoughts, but I don't know if we have the same level of understanding across encapsulations. And even for NVO3-like deployments it could be different - a public provider where anybody can get a virtual machine, vs. isolation between different departments in an enterprise NVO3 network. >> o Our collective IETF experience is that succesful protocols get >> deployed outside of the original intended context, hence the >> initial assumptions about the threat model might become invalid. >> That needs to be considered in the standardization of new >> encapsulations. > So whats the recommendation here? Over-engineer in case something is needed > later? > At least provide the extensibility mechanisms so it can be added without too much pain. > 12. QoS > > In the Internet architecture we support QoS using the Differentiated > Services Code Points (DSCP) in the formerly named Type-of-Service > field in the IPv4 header, and in the Traffic-Class field in the IPv6 > Its been at least a decade since the change, do you really need to say > "formerly named ToS"? > I dunno. I was told by the LISPers that the RFC 1812 ICMP errors requirement is not yet implemented (getting more than 8 bytes past the IP header) and that was 20 years ago. > Is a ref for NCP needed? Why not? RFC33 seems to be the most pertinent RFC. > Extending a protocol header with new fields can be done in several > ways. > o TLVs are a very popular method used in such protocols as IP and > TCP. Depending on the type field size and structure, TLVs can > offer a virtually unlimited range of extensions. A disadvantage > of TLVs is that processing them can be verbose, quite complicated, > several validations must often be done for each TLV, and there is > I think if you make such strong comments you need to quantify them. > A TLV is a formal structure with well defined characteristics. You could > write efficient code to parse, identify and validate TLVs. How is it > verbose to process etc? > >> no deterministic ordering for a list of TLVs. TCP serves as an > The reason deterministic ordering would matter is if there's dependencies > between the TLVs. If that is a huge need, then the document needs to provide a > sample space or explanation why that is important. > Fair enough; let me check with the co-authors on how to improve those parts. > The main difference seems to be in the fact that in a list of header > extensions, the current extension describes the next; whereas in TLVs > there is no such relationship; otherwise the T in TLV is an extension > header. One imposes ordering, the other doesnt really. In the case of IPv6 header extensions there isn't a strong ordering requirement; there is a recommended order in which to transmit them but a receiver should be more liberal. Header extensions seem to be set apart from options/TLV/extensions in that they use the same next-header space as is used to indicate a "terminal" header such as TCP. >> o Flag-fields are a non-TLV like method of extending a protocol >> header. The basic idea is that the header contains a set of >> flags, where each set flags corresponds to optional field that is >> present in the header. GRE is an example of a protocol that >> employs this mechanism. The fields are present in the header in >> the order of the flags, and the length of each field is fixed. >> Flag-fields are simpler to process compared to TLVs, having fewer >> validations and the order of the optional fields is deterministic. >> A disadvantage is that range of possible extensions with flag- >> fields is smaller than TLVs. > Qualify with "much smaller" maybe? > Defer with other TLV comments. > "a middlebox could first decapsulate, perform some function then encapsulate; > which means it will generate a new encapsulation header." Much better - and I've applied your other editorial fixes that I didn't explicitly respond to. > Is there a reference to work which says quiet periods (which i am implicitly > reading that in the text above) can be used to change the hash selection? > I would think that one needs to closely observe packet trends to make > such a decision. So please provide some ref to some scholarly or > engineering work. I don't know of citations to such work; perhaps my co-authors have some. I recall reading about using markers, but that was a long time ago. > I think this section is well done. > > In regards to TLVs, I understand now a little more where the earlier > comments come from (IMO: you will need to point to a reference to this > section from the earlier reference). > > Having said that, lets weigh out the pros and cons: > pro: > TLVs very flexible - almost give you future proofness in terms of extensibility. > cons: > Harder to parallelize in hardware. > > I think the pro side should be driving things. > I would say to the hardware folks - get busy now! > > I am still unsure why this is hard to do in h/ware given all the benefits. > At the expense of getting tomatoes thrown at me: > sounds like there's an extra parsing step of hardware processing to find each > individual TLVs "fixed offset" and after that you can parallelize. This is something that should be discussed in RTGWG. Thanks, Erik > cheers, > jamal > From nobody Tue Jul 7 14:09:53 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87041ACDEA; Tue, 7 Jul 2015 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 OvUu80TSKKll; Tue, 7 Jul 2015 14:09:47 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1251ACDBE; Tue, 7 Jul 2015 14:09:47 -0700 (PDT) Received: by oiab3 with SMTP id b3so33321190oia.1; Tue, 07 Jul 2015 14:09:47 -0700 (PDT) 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=85L3aDQihTKF2/wGbEPbxOvA3GJ3tkebdF7pvFLZY5c=; b=kWMbxT5XzbXs39jshj/EjxOO6DCNgoiYFmjGOXFZ2TZ1qFOE/s+GRe+U7ieymtwLAh z2G+mmJH0l6YA0Pn1Wyivg0n2QoylkGSQL0xpJvKKk6q5ZlUhfbNz5bMCUbKSzH8jWYH SLB1LXEjXvhgQxqH/WSdsux76CzjtiQ8DnogH/uOVPZYELXrFdN8mxcbhvaet7ZU41wT rf6563w5LBWz7ZrvKsBsV/FfRGQmQ764YwBbbtzNg0H1ehni6Xf/k46cEydwmj9A9xuC 89Nwn8HrXsXf9UCCOxsJTlHlDo8B5OzzznRvRlh9Ox9gIq1YugyJO3bnFv/O35reuia0 SQfg== MIME-Version: 1.0 X-Received: by 10.60.141.135 with SMTP id ro7mr4841145oeb.13.1436303386968; Tue, 07 Jul 2015 14:09:46 -0700 (PDT) Received: by 10.60.41.99 with HTTP; Tue, 7 Jul 2015 14:09:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jul 2015 17:09:46 -0400 Message-ID: From: Alia Atlas To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=047d7b41c5b42b8cca051a4f71fa Archived-At: Cc: "rtg-dir@ietf.org" , "homenet@ietf.org Group" , "draft-ietf-homenet-dncp.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 21:09:50 -0000 --047d7b41c5b42b8cca051a4f71fa Content-Type: text/plain; charset=UTF-8 Les, Thanks very much for your review. Alia On Tue, Jul 7, 2015 at 1:25 AM, Les Ginsberg (ginsberg) wrote: > Hello, > > I have been selected as a Routing Directorate reviewer for this draft. > The > > Routing Directorate seeks to review all routing or routing-related drafts > as > > they pass through IETF last call and IESG review, and sometimes on special > > request. The purpose of the review is to provide assistance to the Routing > ADs. > > For more information about the Routing Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other IETF > > Last Call comments that you receive, and strive to resolve them through > > discussion or by updating the draft. > > Document: draft-ietf-homenet-dncp-07 > > Reviewer: Les Ginsberg > > Review Date: July 6, 2015 > > IETF LC End Date: Seems to have already occurred?? > > Intended Status: Standard > > > > Major Issues: > > > > My biggest concern is that the document - and its companion HNCP - are not > > yet mature enough to be doing last call. What is being defined here is a > > "state synchronization protocol" which is used within the context of a > > "parent protocol" (most interestingly a routing protocol for the homenet > > context) and which depends upon another configuration protocol > > (presumably HNCP) to fully define the behavior. > > > > Judging from the review comments provided by others (notably Thomas > Clausen's > > detailed review) and the continued discussion on the mailing list it has > not > > yet been demonstrated that the specification is clear enough and robust > enough > > for implementations to meet all the requirements and interoperate. > > > > This is not to suggest that you are on the wrong track - but given the > > dependencies pushing this to last call seems - to put it politely - > > very "ambitious". I would prefer to see more implementation experience > before > > the document moves to a state where it is presumed to be complete. > > > > I still have some trouble calling this a protocol. This is more of a > process - > > or part of a process - which comprises a routing protocol. The process > defined > > here serves to support reliable distribution and synchronization of > "state" > > in an efficient manner under a limited set of conditions. I don't want to > > quibble too much about the term "protocol" - but I would prefer something > like: > > > > "a generic set of procedures which - when supplemented by a specific > profile - > > define a means of maintaining state synchronization" > > > > Some specific comments on points in the draft follow. > > > > *************** > > > > Section 2 Terminology > > > > The term "neighbor" is not defined - but used frequently in the document. > > The term "peer" is defined as: > > > > "another DNCP node with which a DNCP node communicates using a particular > > local and remote endpoint pair." > > > > What I am used to is that the definition above for "peer" is usually > > associated with the term "neighbor", whereas the term "peer" is more > generic - > > it is associated with a node in the network which performs the same > functions > > in the protocol - but is not necessarily a neighbor. > > > > Section 4.5 illustrates why I find this confusing as it says > > > > "When receiving a Node Endpoint TLV... the remote node MUST be added as a > peer > > on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created > > for it." > > > > ??? > > > > ******* > > > > Section 4.4 - final bullet on Page 11 > > > > o Any other TLV: TLVs not recognized by the receiver MUST be > > silently ignored. > > > > Does "ignore mean "discard"? (This is one traditional meaning) > > > > If so this seems inappropriate as it is part of the database sent by > > the node and therefore needs to be retained in order to keep a consistent > > database. Perhaps "store but do not process" is a more accurate behavioral > > description? > > > > ******************** > > Section 6.1 Keep-alives > > > > Here is another case where the confusion between "peer" and "neighbor" > arises > > for me. I would expect that keep-alives are only used between neighbors - > > but the text here uses the term "peer". > > > > Are keep alives sent in multicast-listener mode? >From the text in 6.1.2 > and > > 6.1.3 it seems "no" - but I am not certain. > > ***************** > > Section 6.2 Support For Dense Broadcast Links > > > > If a node is in Multicast-listen+unicast mode does it bear any > responsibility > > for publishing state data in the event the node with highest node > identifier > > does not have the latest information? I presume yes - but the text does > not > > discuss this point. > > > > Also, does multicast-listener mode affect the way neighbors are > advertised? > > It seems not - so what you are preventing w multicast-listener mode is > > redundant state updates - but there is no change to the set of neighbors > > advertised (N*(N-1))? > > > > ******************** > > Section 6.3 Node Data Fragmentation > > > > The significance of the MTU limitation is network-wide i.e. a too large > > Node State TLV generated anywhere in the network could cause problems in > > some other part of the network. This issue is usually not well understood > > as experience w IS-IS has shown. More discussion of this point would be > > helpful. > > > > Second paragraph says > > > > "The data within Node State TLVs of all fragments MUST be valid..." > > > > And if it is not then all fragments are ignored/discarded?? > > > > When multiple fragments are used and the location of specific pieces of > > information move from one fragment to another cases arise where some data > > temporarily disappears and/or there are two copies. Are you addressing > this > > by expecting that a new set of fragments will not be used at all until all > of > > them have been received? If so, what happens if you receive some fragments > > but not all of them? Is there a timeout to be applied here? > > > > *************** > > Section 7 TLVs > > > > It says "padding bytes with value zero"". > > Is "0' a MUST - or is this the usual "SHOULD be transmitted as zero and > > ignored on receipt"? > > > > ******************* > > Section 7.2.1 Node Endpoint TLV > > > > When is this sent and how often? > > > > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > --047d7b41c5b42b8cca051a4f71fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Les,

Thanks very much for your =C2=A0re= view.

Alia
<= br>
On Tue, Jul 7, 2015 at 1:25 AM, Les Ginsberg = (ginsberg) <ginsberg@cisco.com> wrote:

Hello,

I have been selected as a Routing Directorate reviewer for this draft. T= he

Routing Directorate seeks to review all routing or routing-related draft= s as

they pass through IETF last call and IESG review, and sometimes on speci= al

request. The purpose of the review is to provide assistance to the Routi= ng ADs.

For more information about the Routing Directorate, please see

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir=

Although these comments are primarily for the use of the Routing ADs,

it would be helpful if you could consider them along with any other IETF

Last Call comments that you receive, and strive to resolve them through

discussion or by updating the draft.

Document: draft-ietf-homenet-dncp-07

Reviewer: Les Ginsberg

Review Date: July 6, 2015

IETF LC End Date: Seems to have already occurred??

Intended Status: Standard

=C2=A0

Major Issues:

=C2=A0

My biggest concern is that the document - and its companion HNCP - are n= ot

yet mature enough to be doing last call. What is being defined here is a

"state synchronization protocol" which is used within the cont= ext of a

"parent protocol" (most interestingly a routing protocol for t= he homenet

context) and which depends upon another configuration protocol

(presumably HNCP) to fully define the behavior.

=C2=A0

Judging from the review comments provided by others (notably Thomas Clau= sen's

detailed review) and the continued discussion on the mailing list it has= not

yet been demonstrated that the specification is clear enough and robust = enough

for implementations to meet all the requirements and interoperate.

=C2=A0

This is not to suggest that you are on the wrong track - but given the

dependencies pushing this to last call seems - to put it politely -

very "ambitious". I would prefer to see more implementation ex= perience before

the document moves to a state where it is presumed to be complete.

=C2=A0

I still have some trouble calling this a protocol. This is more of a pro= cess -

or part of a process - which comprises a routing protocol. The process d= efined

here serves to support reliable distribution and synchronization of &quo= t;state"

in an efficient manner under a limited set of conditions. I don't wa= nt to

quibble too much about the term "protocol" - but I would prefe= r something like:

=C2=A0

"a generic set of procedures which - when supplemented by a specifi= c profile -

define a means of maintaining state synchronization"<= /p>

=C2=A0

Some specific comments on points in the draft follow.

=C2=A0

***************

=C2=A0

Section 2 Terminology

=C2=A0

The term "neighbor" is not defined - but used frequently in th= e document.

The term "peer" is defined as:

=C2=A0

"another DNCP node with which a DNCP node communicates using a part= icular

local and remote endpoint pair."

=C2=A0

What I am used to is that the definition above for "peer" is u= sually

associated with the term "neighbor", whereas the term "pe= er" is more generic -

it is associated with a node in the network which performs the same func= tions

in the protocol - but is not necessarily a neighbor.

=C2=A0

Section 4.5 illustrates why I find this confusing as it says

=C2=A0

"When receiving a Node Endpoint TLV... the remote node MUST be adde= d as a peer

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on the endpoint and a Neighbor TLV (Secti= on 7.3.2) MUST be created

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for it."

=C2=A0

???

=C2=A0

*******

=C2=A0

Section 4.4 - final bullet on Page 11

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Any other TLV: TLVs not recognized by the receiver = MUST be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 silently ignored.

=C2=A0

Does "ignore mean "discard"? (This is one traditional mea= ning)

=C2=A0

If so this seems inappropriate as it is part of the database sent by

the node and therefore needs to be retained in order to keep a consisten= t

database. Perhaps "store but do not process" is a more accurat= e behavioral

description?

=C2=A0

********************

Section 6.1 Keep-alives

=C2=A0

Here is another case where the confusion between "peer" and &q= uot;neighbor" arises

for me. I would expect that keep-alives are only used between neighbors = -

but the text here uses the term "peer".

=C2=A0

Are keep alives sent in multicast-listener mode? >From the text in 6.= 1.2 and

6.1.3 it seems "no" - but I am not certain.

*****************

Section 6.2 Support For Dense Broadcast Links

=C2=A0

If a node is in Multicast-listen+unicast mode does it bear any responsib= ility

for publishing state data in the event the node with highest node identi= fier

does not have the latest information? I presume yes - but the text does = not

discuss this point.

=C2=A0

Also, does multicast-listener mode affect the way neighbors are advertis= ed?

It seems not - so what you are preventing w multicast-listener mode is

redundant state updates - but there is no change to the set of neighbors

advertised (N*(N-1))?

=C2=A0

********************

Section 6.3 Node Data Fragmentation

=C2=A0

The significance of the MTU limitation is network-wide i.e. a too large

Node State TLV generated anywhere in the network could cause problems in

some other part of the network. This issue is usually not well understoo= d

as experience w IS-IS has shown. More discussion of this point would be

helpful.

=C2=A0

Second paragraph says

=C2=A0

"The data within Node State TLVs of all fragments MUST be valid...&= quot;

=C2=A0

And if it is not then all fragments are ignored/discarded??

=C2=A0

When multiple fragments are used and the location of specific pieces of

information move from one fragment to another cases arise where some dat= a

temporarily disappears and/or there are two copies. Are you addressing t= his

by expecting that a new set of fragments will not be used at all until a= ll of

them have been received? If so, what happens if you receive some fragmen= ts

but not all of them? Is there a timeout to be applied here?

=C2=A0

***************

Section 7 TLVs

=C2=A0

It says "padding bytes with value zero"".

Is "0' a MUST - or is this the usual "SHOULD be transmitte= d as zero and

ignored on receipt"?

=C2=A0

*******************

Section 7.2.1 Node Endpoint TLV

=C2=A0

When is this sent and how often?

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


--047d7b41c5b42b8cca051a4f71fa-- From nobody Wed Jul 8 00:57:51 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8551AD36A; Tue, 7 Jul 2015 14:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 u86QIZ8165Ox; Tue, 7 Jul 2015 14:52:57 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 BCAE21AD369; Tue, 7 Jul 2015 14:52:57 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZCanN-00027s-3J with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Tue, 07 Jul 2015 23:52:53 +0200 Message-ID: <559C4A32.5050400@openwrt.org> Date: Tue, 07 Jul 2015 23:52:50 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ole Troan , ginsberg@cisco.com References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> In-Reply-To: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 00:57:49 -0700 Cc: rtg-dir@ietf.org, "homenet@ietf.org Group" , rtg-ads@tools.ietf.org, int-ads@tools.ietf.org, int-dir@ietf.org Subject: Re: [RTG-DIR] review: draft-ietf-homenet-dhcp-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 21:52:59 -0000 Hello Ole, hello Les, thank you both for your reviews. We will hopefully get back to you with a detailed reply and a list of changes we made based on your reviews by next week (due to vacations etc). Cheers, Steven From nobody Wed Jul 8 00:57:52 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BCA1B3145; Tue, 7 Jul 2015 23:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6rYyO0cgVEw; Tue, 7 Jul 2015 23:37:40 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580FC1B3143; Tue, 7 Jul 2015 23:37:40 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 7 Jul 2015 23:37:38 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Tue, 7 Jul 2015 23:37:38 -0700 From: Terry Manderson To: Steven Barth , Ole Troan , "ginsberg@cisco.com" Thread-Topic: [homenet] review: draft-ietf-homenet-dhcp-07 Thread-Index: AQHQuP9dGTPAdeseu06lKkGpoVi1wJ3SPCOA Date: Wed, 8 Jul 2015 06:37:37 +0000 Message-ID: References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> <559C4A32.5050400@openwrt.org> In-Reply-To: <559C4A32.5050400@openwrt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3519218255_116797519" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 08 Jul 2015 00:57:49 -0700 Cc: "rtg-dir@ietf.org" , "homenet@ietf.org Group" , "int-dir@ietf.org" , "int-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [homenet] review: draft-ietf-homenet-dhcp-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 06:37:41 -0000 --B_3519218255_116797519 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks Steven, ... as they say 'watching the thread' :-) Cheers Terry On 8/07/2015 7:52 am, "Steven Barth" wrote: >Hello Ole, hello Les, > >thank you both for your reviews. >We will hopefully get back to you with a detailed reply and a list of >changes >we made based on your reviews by next week (due to vacations etc). > > > >Cheers, > > >Steven > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet --B_3519218255_116797519 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFO95 Uq26BtTzpnaBbpD7zitcuKU0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcwODA2MzczNVowDQYJKoZIhvcNAQEBBQAEggEAgzSZA0B0b21oJ+HAfrYa 8bA2NW0PGCrRxuUL+ACXLjDrl9RNNrDcvYePZvoAq1XgemkRWbMo+3YHGKxuOkBQZb1Ntvak dM+GwJ2jURT0dif2orOlwZDoAIx6hXxPWHFjHMmKsQS2stao12hnmOT1eiG4lp70fNBKse91 3M9guurkVRYXQ0tu84dajNiqmYiGl2/B5fQuchPExEJBy1j5OpJLaVq63eyjq8d2Kjp35Kh/ Z/Tqc/K3iiAhlhGIOK4j7+GrUx2DCU+jVJTQosmyeumV690GqKpIaj2viQSy1r+M6CV9Kdb8 /0Yp2aTO3XYxwnxXf80QLcCpUgk+DqCycA== --B_3519218255_116797519-- From nobody Thu Jul 9 10:04:50 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580FA1A9154; Wed, 8 Jul 2015 23:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 wLP9yHF-lotT; Wed, 8 Jul 2015 23:10:21 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 B2E3C1A9135; Wed, 8 Jul 2015 23:10:21 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZD52G-0001CX-1z with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 09 Jul 2015 08:10:16 +0200 Message-ID: <559E1047.4090105@openwrt.org> Date: Thu, 09 Jul 2015 08:10:15 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alia Atlas , "Les Ginsberg (ginsberg)" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2015 10:04:48 -0700 Cc: "rtg-dir@ietf.org" , "homenet@ietf.org Group" , "draft-ietf-homenet-dncp.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 06:10:24 -0000 Hello Les, thanks for your review. Please find detailed replies inline. Cheers, Steven & Markus > Major Issues: > > > > My biggest concern is that the document - and its companion HNCP - are not > yet mature enough to be doing last call. Please note that DNCP does not depend on nor reference HNCP in any way. It is a separate draft and it can and should be used not only by HNCP. Furthermore while DNCP has been submitted to the IESG, HNCP has not and is still in WGLC. Therefore I'd kindly ask you to keep issues separate from one another. > What is being defined here is a > "state synchronization protocol" which is used within the context of a > "parent protocol" (most interestingly a routing protocol for the homenet > context) and which depends upon another configuration protocol > (presumably HNCP) to fully define the behavior. I don't believe this to be an accurate summary. Again DNCP does not depend on HNCP, rather the reverse is true. DNCP even defines some extensions that are not used or intended to be used in HNCP. Neither of the two protocols depend on any routing protocol for correct operation. DNCP does not even mention routing anywhere in the draft. HNCP in fact enables routing protocols to operate in typical home network scenarios. > Judging from the review comments provided by others (notably Thomas Clausen's > detailed review) and the continued discussion on the mailing list it has not > yet been demonstrated that the specification is clear enough and robust enough > for implementations to meet all the requirements and interoperate. > > This is not to suggest that you are on the wrong track - but given the > dependencies pushing this to last call seems - to put it politely - > very "ambitious". I would prefer to see more implementation experience before > the document moves to a state where it is presumed to be complete. We addressed Thomas' comments to the best of our knowledge. Please let us know, if any of the issues still remain in the current revisions. Also, a second independent and interoperable implementation of DNCP and (parts of) HNCP exists: https://github.com/jech/shncpd Comments of the author regarding clarity of the draft are already integrated in the current revisions, some more are queued for the next. > I still have some trouble calling this a protocol. This is more of a process - > or part of a process - which comprises a routing protocol. Again "comprises a routing protocol" is simply incorrect. > The process defined > here serves to support reliable distribution and synchronization of "state" > in an efficient manner under a limited set of conditions. I don't want to > quibble too much about the term "protocol" - but I would prefer something like: > > "a generic set of procedures which - when supplemented by a specific profile - > define a means of maintaining state synchronization" It is very hard to find a wording for this that everyone agrees with. For now it was changed to “DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol.” based on a suggestion in Ole Troan’s review. > Section 2 Terminology > > > The term "neighbor" is not defined - but used frequently in the document. > The term "peer" is defined as: > "another DNCP node with which a DNCP node communicates using a particular > local and remote endpoint pair." > > What I am used to is that the definition above for "peer" is usually > associated with the term "neighbor", whereas the term "peer" is more generic - > it is associated with a node in the network which performs the same functions > in the protocol - but is not necessarily a neighbor. The terms "peer" and "neighbor" are used relatively interchangeably in this document. The terminology has been adapted to reflect that. > Section 4.5 illustrates why I find this confusing as it says > > "When receiving a Node Endpoint TLV... the remote node MUST be added as a peer > on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created > for it." > ??? I think this particular case should actually not be confusing, since all terms used here are defined in the Terminology or as TLVs. However, we may have a look at it again. > Section 4.4 - final bullet on Page 11 > > o Any other TLV: TLVs not recognized by the receiver MUST be > silently ignored. > > Does "ignore mean "discard"? (This is one traditional meaning) > > If so this seems inappropriate as it is part of the database sent by > the node and therefore needs to be retained in order to keep a consistent > database. Perhaps "store but do not process" is a more accurate behavioral > description? TLVs that are part of the database are sent within the Node State TLV (Node Data field). Said Node State TLV is mentioned just before "Any other TLV" in the same list and thus not meant to be part of "other TLV"s. The text now states this explicitly. > Section 6.1 Keep-alives > > Are keep alives sent in multicast-listener mode? >From the text in 6.1.2 and > 6.1.3 it seems "no" - but I am not certain. The are no multicast keep-alives in this case, please see next comment as well. > Section 6.2 Support For Dense Broadcast Links > > If a node is in Multicast-listen+unicast mode does it bear any responsibility > for publishing state data in the event the node with highest node identifier > does not have the latest information? I presume yes - but the text does not > discuss this point. Yes, it is implied by "SHOULD treat the endpoint as a unicast endpoint connected to the node that has the highest node identifier". So effectively, the node with lower identifier (multicast-listen aside) treats it as a unicast connection to the node with highest identifier, including state synchronisation, keep-alives etc. Maybe we can explicitly list some of those consequences, if that makes it more clear. > Also, does multicast-listener mode affect the way neighbors are advertised? > It seems not - so what you are preventing w multicast-listener mode is > redundant state updates - but there is no change to the set of neighbors > advertised (N*(N-1))? The initial paragraph states that that the main reason for this extension is to avoid lots of redundant Neighbor TLVs. A later paragraph also states that usage of this extension results in only a subset of the topology being advertised. So I think this point should be pretty clear already. As for the underlying logic, please see the comment before. > Section 6.3 Node Data Fragmentation The extension and thereby this section has been removed as requested by another reviewer. > Section 7 TLVs > It says "padding bytes with value zero"". > > Is "0' a MUST - or is this the usual "SHOULD be transmitted as zero and > ignored on receipt"? It actually says "Padding bytes with value zero MUST be added" so I guess it should be pretty unambiguous already. Making this a non-MUST would make some things like ordering and hashing of TLV sets a bit awkward. > Section 7.2.1 Node Endpoint TLV > When is this sent and how often? This is described in detail in 4.2, a reference has been added. From nobody Thu Jul 9 12:11:04 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E48D1A6FED; Thu, 9 Jul 2015 12:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebiBYeu9H6zu; Thu, 9 Jul 2015 12:11:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536FA1A1A7E; Thu, 9 Jul 2015 12:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10617; q=dns/txt; s=iport; t=1436469061; x=1437678661; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NTzBAwaur5R3g8FM+n1sPa2orYb2DU43aTTY/p9I/pw=; b=KZFLPTGci7q76LDJsk3b4chT4Xt2/4ejflIiWnyzxW4AMxrh5G1rh//3 iJSYcMh45v0Vp99BbKwG0y1TupukRhwP/QzvMowEkIOHe4fBLqKTIppvj 57KvzDycvjeYU1w3rjUmvRl9UUBx60+IeEdUaysPiytRw6JDikmVX6kcA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CSAwCrxp5V/4YNJK1RCoMSVGAGux8JgWcKhS1KAoFfOBQBAQEBAQEBgQqEIwEBAQMBAQEBNzQLDAQCAQgOAwQBAQsUCQcnCxQJCAEBBAENBQiIHggNzzMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItLhCkEKDEHBoMRgRQFjCqFG4JoAYRmgl6FeIQYjzODXyaCCQMcgVNvAYEDQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="scan'208";a="14075066" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jul 2015 19:11:00 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t69JAxVx027937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 19:10:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 14:10:58 -0500 From: "Les Ginsberg (ginsberg)" To: Steven Barth , Alia Atlas Thread-Topic: [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt Thread-Index: AdC4dM67HZyS0u8fSh2s5cmMOaEiiwArlp4AAEUq5oAAD2nyoA== Date: Thu, 9 Jul 2015 19:10:58 +0000 Message-ID: References: <559E1047.4090105@openwrt.org> In-Reply-To: <559E1047.4090105@openwrt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "homenet@ietf.org Group" , "draft-ietf-homenet-dncp.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 19:11:03 -0000 Steven - Thanx for the reply - inline. > -----Original Message----- > From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Steven > Barth > Sent: Wednesday, July 08, 2015 11:10 PM > To: Alia Atlas; Les Ginsberg (ginsberg) > Cc: rtg-dir@ietf.org; homenet@ietf.org Group; draft-ietf-homenet- > dncp.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt >=20 > Hello Les, >=20 > thanks for your review. Please find detailed replies inline. >=20 >=20 > Cheers, >=20 > Steven & Markus >=20 >=20 > > Major Issues: > > > > > > > > My biggest concern is that the document - and its companion HNCP - are > > not yet mature enough to be doing last call. >=20 > Please note that DNCP does not depend on nor reference HNCP in any way. > It is a separate draft and it can and should be used not only by HNCP. > Furthermore while DNCP has been submitted to the IESG, HNCP has not and > is still in WGLC. Therefore I'd kindly ask you to keep issues separate fr= om one > another. >=20 [Les:] We are not understanding each other. Let me try to explain more clea= rly than I did the first time. DNCP has two dependencies: 1)The (routing) protocol which uses it 2)The profile "protocol" which completes the specification of what informat= ion needs to be sent by DNCP. You are of course correct that HNCP is only one of many possible profile "p= rotocols" - I mention it specifically because it is clearly the one being u= sed in current prototyping/testing. To have high confidence that the DNCP specification is complete we would li= ke to have experience w multiple routing protocols/profile protocols. So... In the best of all worlds we would have development experience w multiple r= outing protocols using multiple profile protocols in combination w DNCP. Second best would be multiple implementations of a single routing protocol/= single profile protocol using DNCP. A distant third is a single implementation of a routing protocol/single pro= file protocol using DNCP. It seems to me that we are somewhere between #2 and #3 today - and HNCP its= elf is still under construction. This makes me concerned that we don't real= ly know what gaps/problems might exist in DNCP because we simply don't have= enough experience with it yet. HTH >=20 >=20 > > What is being defined here is a > > "state synchronization protocol" which is used within the context of a > > "parent protocol" (most interestingly a routing protocol for the > > homenet > > context) and which depends upon another configuration protocol > > (presumably HNCP) to fully define the behavior. >=20 > I don't believe this to be an accurate summary. Again DNCP does not depen= d > on HNCP, rather the reverse is true. DNCP even defines some extensions > that are not used or intended to be used in HNCP. >=20 > Neither of the two protocols depend on any routing protocol for correct > operation. DNCP does not even mention routing anywhere in the draft. > HNCP in fact enables routing protocols to operate in typical home network > scenarios. >=20 >=20 > > Judging from the review comments provided by others (notably Thomas > > Clausen's detailed review) and the continued discussion on the mailing > > list it has not yet been demonstrated that the specification is clear > > enough and robust enough for implementations to meet all the > requirements and interoperate. > > > > This is not to suggest that you are on the wrong track - but given the > > dependencies pushing this to last call seems - to put it politely - > > very "ambitious". I would prefer to see more implementation experience > > before the document moves to a state where it is presumed to be > complete. >=20 > We addressed Thomas' comments to the best of our knowledge. Please let > us know, if any of the issues still remain in the current revisions. Also= , a > second independent and interoperable implementation of DNCP and (parts > of) HNCP exists: > https://github.com/jech/shncpd >=20 > Comments of the author regarding clarity of the draft are already integra= ted > in the current revisions, some more are queued for the next. >=20 >=20 > > I still have some trouble calling this a protocol. This is more of a > > process - or part of a process - which comprises a routing protocol. > Again "comprises a routing protocol" is simply incorrect. >=20 >=20 > > The process defined > > here serves to support reliable distribution and synchronization of "st= ate" > > in an efficient manner under a limited set of conditions. I don't want > > to quibble too much about the term "protocol" - but I would prefer > something like: > > > > "a generic set of procedures which - when supplemented by a specific > > profile - define a means of maintaining state synchronization" >=20 > It is very hard to find a wording for this that everyone agrees with. > For now it was changed to "DNCP is an abstract protocol, that must be > combined with a specific profile to make a complete implementable > protocol." based on a suggestion in Ole Troan's review. >=20 >=20 >=20 > > Section 2 Terminology > > > > > > The term "neighbor" is not defined - but used frequently in the documen= t. > > The term "peer" is defined as: > > "another DNCP node with which a DNCP node communicates using a > > particular local and remote endpoint pair." > > > > What I am used to is that the definition above for "peer" is usually > > associated with the term "neighbor", whereas the term "peer" is more > > generic - it is associated with a node in the network which performs > > the same functions in the protocol - but is not necessarily a neighbor. >=20 > The terms "peer" and "neighbor" are used relatively interchangeably in th= is > document. The terminology has been adapted to reflect that. >=20 >=20 > > Section 4.5 illustrates why I find this confusing as it says > > > > "When receiving a Node Endpoint TLV... the remote node MUST be added > as a peer > > on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be create= d > > for it." > > ??? >=20 > I think this particular case should actually not be confusing, since all = terms > used here are defined in the Terminology or as TLVs. However, we may have > a look at it again. [Les:] Well "neighbor" is not defined - though yours would not be the only = specification to omit that definition. And I could intuit using "peer" to i= dentify other nodes operating the protocol who are not necessarily neighbor= s - but that can't be done using your definition of "peer". >=20 >=20 > > Section 4.4 - final bullet on Page 11 > > > > o Any other TLV: TLVs not recognized by the receiver MUST be > > silently ignored. > > > > Does "ignore mean "discard"? (This is one traditional meaning) > > > > If so this seems inappropriate as it is part of the database sent by > > the node and therefore needs to be retained in order to keep a > > consistent database. Perhaps "store but do not process" is a more > > accurate behavioral description? >=20 > TLVs that are part of the database are sent within the Node State TLV (No= de > Data field). Said Node State TLV is mentioned just before "Any other TLV" > in the same list and thus not meant to be part of "other TLV"s. The text = now > states this explicitly. >=20 [Les:] But there can be TLVs within the Node State TLV - and these cannot b= e discarded - though they could be ignored. So there seem to be two classes= of "unrecognized TLVs" - those within the Node State TLV and those not ass= ociated with the Node State TLV. ?? >=20 > > Section 6.1 Keep-alives > > > > Are keep alives sent in multicast-listener mode? >From the text in > > 6.1.2 and > > 6.1.3 it seems "no" - but I am not certain. >=20 > The are no multicast keep-alives in this case, please see next comment as > well. >=20 >=20 > > Section 6.2 Support For Dense Broadcast Links > > > > If a node is in Multicast-listen+unicast mode does it bear any > > responsibility for publishing state data in the event the node with > > highest node identifier does not have the latest information? I > > presume yes - but the text does not discuss this point. >=20 > Yes, it is implied by "SHOULD treat the endpoint as > a unicast endpoint connected to the node that has the highest node > identifier". >=20 > So effectively, the node with lower identifier (multicast-listen aside) t= reats it > as a unicast connection to the node with highest identifier, including st= ate > synchronisation, keep-alives etc. >=20 > Maybe we can explicitly list some of those consequences, if that makes it > more clear. >=20 >=20 > > Also, does multicast-listener mode affect the way neighbors are > advertised? > > It seems not - so what you are preventing w multicast-listener mode is > > redundant state updates - but there is no change to the set of > > neighbors advertised (N*(N-1))? >=20 > The initial paragraph states that that the main reason for this extension= is to > avoid lots of redundant Neighbor TLVs. A later paragraph also states that > usage of this extension results in only a subset of the topology being > advertised. > So I think this point should be pretty clear already. > As for the underlying logic, please see the comment before. >=20 >=20 > > Section 6.3 Node Data Fragmentation > The extension and thereby this section has been removed as requested by > another reviewer. >=20 >=20 > > Section 7 TLVs > > It says "padding bytes with value zero"". > > > > Is "0' a MUST - or is this the usual "SHOULD be transmitted as zero > > and ignored on receipt"? >=20 > It actually says "Padding bytes with value zero MUST be added" so I guess= it > should be pretty unambiguous already. >=20 > Making this a non-MUST would make some things like ordering and hashing > of TLV sets a bit awkward. >=20 >=20 > > Section 7.2.1 Node Endpoint TLV > > When is this sent and how often? >=20 > This is described in detail in 4.2, a reference has been added. > [Les:] Ahhh - thanx for the pointer. I searched for "Node Endpoint" - but S= ection 4.2 uses simply "Endpoint" - so I did not find a match. If you could= use the full TLV name in Section 4.2 that would be helpful. Thanx. Les >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Jul 9 22:30:31 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CDC1A88D4; Thu, 9 Jul 2015 22:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 Z-lgXMY5TVEi; Thu, 9 Jul 2015 22:30:25 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 8887B1A88D3; Thu, 9 Jul 2015 22:30:25 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZDQtB-0007qY-59 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Fri, 10 Jul 2015 07:30:21 +0200 Message-ID: <559F586B.2020104@openwrt.org> Date: Fri, 10 Jul 2015 07:30:19 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" , Alia Atlas References: <559E1047.4090105@openwrt.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtg-dir@ietf.org" , "homenet@ietf.org Group" , "draft-ietf-homenet-dncp.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 05:30:27 -0000 Hello Les, > > [Les:] We are not understanding each other. Let me try to explain more clearly than I did the first time. > > DNCP has two dependencies: > > 1)The (routing) protocol which uses it I'm sorry, but I can't seem to follow your logic. Are you thinking of a DNCP-based routing protocol here? But even then how can a thing using DNCP be a dependency of DNCP? > 2)The profile "protocol" which completes the specification of what information needs to be sent by DNCP. Let me tackle this another way: Trickle does not depend on DNCP, but DNCP depends on Trickle. That's why the DNCP specification has a Normative Reference on Trickle, but not the other way around. Similarly RPL uses Trickle, but that doesn't affect Trickle either and does not make it responsible if something was missing in RPL. > To have high confidence that the DNCP specification is complete we would like to have experience w multiple routing protocols/profile protocols. So... I don't see how building routing protocols out of DNCP proofs or disproofs anything. Furthermore, in general how could adding something proof or disproof the completeness of it, especially if the original thing is deliberately abstract? Or do you think existing routing protocols have any impact on DNCP? That is not the case either, i.e. DNCP-based profiles can rely purely on link-local communication - like HNCP does - and are thus unaffected by presence or absence of routing protocols. Or are you referring to mentions of "IGP" and "routing protocol" in the HNCP draft? If so, then these are unrelated to DNCP since they are in a separate draft. However even for HNCP there is not much sense, since it merely tells the router whether to run or not run any routing protocol on a network interface. It can also optionally provide a pre-shared key to use for authentication, but that's about it. > This makes me concerned that we don't really know what gaps/problems might exist in DNCP because we simply don't have enough experience with it yet. You may want to scan through https://www.ietf.org/id/draft-jin-homenet-dncp-experience-00.txt for some up-to-date information on the current state of DNCP and HNCP implementations. This draft also includes simulation results using a relatively bare-metal DNCP-profile (e.g. just using DNCP-TLVs IIRC). > [Les:] Well "neighbor" is not defined - though yours would not be the only specification to omit that definition. And I could intuit using "peer" to identify other nodes operating the protocol who are not necessarily neighbors - but that can't be done using your definition of "peer". The sentence you quoted didn't have the term "neighbor" in it but rather "Neighbor TLV" which is clearly defined as one of the TLVs in the document. >> TLVs that are part of the database are sent within the Node State TLV (Node >> Data field). Said Node State TLV is mentioned just before "Any other TLV" >> in the same list and thus not meant to be part of "other TLV"s. The text now >> states this explicitly. > [Les:] But there can be TLVs within the Node State TLV - and these cannot be discarded - though they could be ignored. So there seem to be two classes of "unrecognized TLVs" - those within the Node State TLV and those not associated with the Node State TLV. > ?? Yes, "Any other TLVs" as well as all the other elements of that enumeration are referring to top-level TLVs, not nested ones. I currently propose "TLVs not recognized by the receiver MUST be silently ignored unless they are sent as part of the payload of one of the TLVs above (such as TLVs in the Node Data field of a Node State TLV)." to make that more clear. Furthermore the definition of the Node State TLV already states that the Node Data content MUST not be modified, so it should be fine. > >> This is described in detail in 4.2, a reference has been added. >> > [Les:] Ahhh - thanx for the pointer. I searched for "Node Endpoint" - but Section 4.2 uses simply "Endpoint" - so I did not find a match. If you could use the full TLV name in Section 4.2 that would be helpful. Yes, I noticed that as well when adding the reference and corrected it. Cheers, Steven From nobody Fri Jul 10 08:27:17 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263551A1B9A; Thu, 9 Jul 2015 18:26:17 -0700 (PDT) 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 A0jVvfhzNGxq; Thu, 9 Jul 2015 18:26:15 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 B56BD1A1B77; Thu, 9 Jul 2015 18:26:15 -0700 (PDT) Received: by pdbqm3 with SMTP id qm3so30780490pdb.0; Thu, 09 Jul 2015 18:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wtWpqwoeOfmvFqJuLxgeFL5TzhCqcOgdSMSdTe807II=; b=RRWJpC+gSer+XLiDyV6RGXQbFF2dHcJ9x/N90phh1TGWjjyWECOL+SJU1THVKtEnri rHcU8WqIwKWulfnsc9CB0ZGxzi0DHXOyRQR/k1O6J2AxrYKBxtlf+FtMCxgClaCpa6A8 a8P/JoRf73dpei3ZRXznr5yXDb1jjwWxM2oGbqUtTPxeodud41KLE4i6fq3p88EIZxJz zKZehDrxmxPYqpW4zzXsPIGoHBk8ZVySILv8tR0DqK/Ui/8oYA64SbdYyYKTOFGCLDP6 FmfCwwbn7KluA9tzFSpqZ9bXy4Ejy0jG9V2St7vFT1KvDji2G7EZRNoWOpIE8ghoJzTe tvYw== X-Received: by 10.69.18.6 with SMTP id gi6mr37049615pbd.44.1436491575323; Thu, 09 Jul 2015 18:26:15 -0700 (PDT) Received: from ?IPv6:2406:e007:44a0:1:28cc:dc4c:9703:6781? ([2406:e007:44a0:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o3sm7453979pds.1.2015.07.09.18.26.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 18:26:13 -0700 (PDT) Message-ID: <559F1F3A.8040906@gmail.com> Date: Fri, 10 Jul 2015 13:26:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alia Atlas , "homenet@ietf.org Group" References: <559E1047.4090105@openwrt.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 10 Jul 2015 08:27:12 -0700 Cc: "Les Ginsberg \(ginsberg\)" , Steven Barth , "draft-ietf-homenet-dncp.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 01:26:17 -0000 (Cc's restored) On 10/07/2015 03:55, Juliusz Chroboczek wrote: >> The draft defines TLVs. To me that means it's somewhat more than an >> "algorithm". > > Yes, which is why I wrote "as well as a suggested packet format to be used > by such protocols". It isn't a "suggested" TLV format. It's fully specified with IANA Considerations and all that. IMHO this is clearly a protocol, although I share Les's doubts about its maturity. On the other hand, it's only going for Proposed Standard at first, and it isn't a routing protocol, although it walks and quacks* a bit like one. https://en.wikipedia.org/wiki/Duck_test Brian From nobody Mon Jul 13 04:53:33 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5101A90E6 for ; Mon, 13 Jul 2015 04:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 sC0035lxeFqu for ; Mon, 13 Jul 2015 04:53:30 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (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 D4C4E1AD10A for ; Mon, 13 Jul 2015 04:52:29 -0700 (PDT) Received: by oibn4 with SMTP id n4so21468099oib.3 for ; Mon, 13 Jul 2015 04:52:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HNjEl7uSv903U2Kc5VDX3hCz69LE6JaQVUX1LWrkgkU=; b=TkMDtLd7ww6pvZj/cyZFnC0KMsVQL+xpfo83GhUOx+TVEY+tDxWhEsj7V3Yjj5Y5o2 o5p/gPpQ1nhhz4HXuO50OrIwzPa5GFNIrtBEopOa3ka/of0VzesfDTN7XrqX8lgGFOMh XSF4W0hCa1CEdfyXkQTa9fiPHDYBqaP3Y2P8HoSbD5qt0NMtzYHxYCPfbz7ylV7znUVY d/4V2mUoZzMsTjZx2v9lEPV/wVAMRzzGPygoE8T2Om2eTVK8ve/M+e306nK1CcX5MQd6 ChCNvKmb6o6W4XTdIKv3/Vk46ckrOEIOXeVV2y8HCAsisXiVO8szgIMPce4oGbiL9QY2 QUdA== X-Gm-Message-State: ALoCoQn/b3mYNrca0iCzyBqvwtS1zceNPyplXiKvYmnWIvQcNwaqXqXt4UiFRDSQdnj/wl0VisXZ X-Received: by 10.202.191.139 with SMTP id p133mr13609270oif.130.1436788349220; Mon, 13 Jul 2015 04:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.88.194 with HTTP; Mon, 13 Jul 2015 04:52:09 -0700 (PDT) In-Reply-To: <559AB820.9000309@acm.org> References: <559AB820.9000309@acm.org> From: Jamal Hadi Salim Date: Mon, 13 Jul 2015 07:52:09 -0400 Message-ID: To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a113de0882c5d46051ac05b91 Archived-At: Cc: draft-rtg-dt-encap , "rtg-dir@ietf.org" , "rtgwg@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-rtg-dt-encap-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 11:53:32 -0000 --001a113de0882c5d46051ac05b91 Content-Type: text/plain; charset=UTF-8 Erik, Sorry for the latency - this got buried because i wasnt on the cc so my filters gave it low prio. On Mon, Jul 6, 2015 at 1:17 PM, Erik Nordmark wrote: > On 6/30/15 2:20 PM, Jamal Hadi Salim wrote: > [..] > The design team tried to stay away from potentially contentions discussion > by putting firm recommendations in place. Thus currently the document is > more of "things to think about" and some tradeoffs, and less of > recommendations (and no requirements). > > Alia has asked for more of a list of choices for the protocol designers, > and this is definitely something which folks can help with as we continue > this work in the RTGWG. But I also think we need to let the specific > in-flight WGs (NVO3, SFC, and BIER) use this document as input but figure > out their own tradeoffs and answers. > Generally the message was as you described. I probably should have used the term "guidelines" instead of "recommendations". I was looking for guidelines and i sometimes didnt grok them. I liked some of the format in section 18. It provides context ("Here's what a NIC does for TSO") and then provides guidelines ("optional protocol fields should not contain values that must be updated on a per segment basis .."). I realize that this specific example is closer to implementation details - which may change (or get obsolete) over time but it serves as a good example of what i was trying to say. I also realize this may be hard to keep consistent across the document - so take it as input of where it may make sense to use such formatting. 6. Terminology >> >> The capitalized keyword MUST is used as defined in >> http://en.wikipedia.org/wiki/Julmust >> >> Missing the context on what looks like a high calorie delicious drink. >> and should that be https?;-> >> >> > Since you are the first to discover the lack of https in that URL, you get > a free beverage of your choice (in the bar in Prague if you will be there). > > I will be there. I suspect they dont have Julmust ;-> > >> > o In the case of IP transport use >=14 bits of UDP source port, plus >> outer IPv6 flowid for entropy. >> >> Looks like a typo. <=14 bits? >> >> No; 14 or 16 depending on the environment. I'll reword as such. > > Ok. Re-reading the first 2-3 paragraphs in section 7 do present the context well. >> > Many Internet protocols use fixed values (typically managed by the >> IANA function) for their next-protocol field. That facilitates >> interpretation of packets by middleboxes and e.g., for debugging >> purposes, but might make the protocol evolution inflexible. Our >> collective experience with MPLS shows an alternative where the label >> can be viewed as an index to a table containing processing >> instructions and the table content can be managed in different ways. >> Would it not be useful to provide a reference here? Just reading this >> has questions popping for me - who populates this tag-indexed table of >> instructions and could interop be impacted? >> >> The DT added the above text based on comments at the mike from Stewart > Bryant. I don't know if there is any reference for the general concept. > Anybody else know? > > In general this implies some control-plane mechanism to populate the table. > Maybe an addendum to describe that the control-plane or some human would administer this would be useful. > >> Is there a reference to work which says quiet periods (which i am >> implicitly >> reading that in the text above) can be used to change the hash selection? >> I would think that one needs to closely observe packet trends to make >> such a decision. So please provide some ref to some scholarly or >> engineering work. >> > I don't know of citations to such work; perhaps my co-authors have some. > I recall reading about using markers, but that was a long time ago. > It would help i think to have some reference. I am not sure if this applies: http://simula.stanford.edu/~alizade/papers/conga-sigcomm14.pdf cheers, jamal --001a113de0882c5d46051ac05b91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Erik,
Sorry for the latency - this got buried because = i wasnt on the cc so my filters
gave it low prio.

<= /div>

On Mon, Jul = 6, 2015 at 1:17 PM, Erik Nordmark <nordmark@acm.org> wrote:
On 6/30/15 2:20 PM, Jamal Hadi Salim wrote:

[..]=C2=A0
The design team tried to stay away from potentially contentions discussion = by putting firm recommendations in place. Thus currently the document is mo= re of "things to think about" and some tradeoffs, and less of rec= ommendations (and no requirements).

Alia has asked for more of a list of choices for the protocol designers, an= d this is definitely something which folks can help with as we continue thi= s work in the RTGWG. But I also think we need to let the specific in-flight= WGs (NVO3, SFC, and BIER) use this document as input but figure out their = own tradeoffs and answers.

Generally th= e message was as you described.
I probably should have used the t= erm "guidelines" instead of "recommendations".
I was looking for guidelines and i sometimes didnt grok them.
I= liked some of the format in section 18. It provides context ("Here= 9;s what a NIC does for TSO")=C2=A0
and then provides guidel= ines ("optional protocol fields=C2=A0should not contain values that mu= st
be updated on a per=C2=A0segment basis .."). I realize th= at this specific example is=C2=A0
closer to implementation detail= s - which may change (or get obsolete) over time but it serves=C2=A0
<= div>as a good example of what i was trying to say.
I also realize= this may be hard to keep consistent across the document - so take it as in= put
of where it may make sense to use such formatting.
=
6.=C2=A0 Terminology

=C2=A0 =C2=A0 The capitalized keyword MUST is used as defined in
=C2=A0 =C2=A0 http://en.wikipedia.org/wiki/Julmust

Missing the context on what looks like a high calorie delicious drink.
and should that be https?;->


Since you are the first to discover the lack of https in that URL, you get = a free beverage of your choice (in the bar in Prague if you will be there).=


I will be there. I suspect they dont h= ave Julmust ;->
=C2=A0


=C2=A0 =C2=A0 o=C2=A0 In the case of IP transport use >=3D14 bits of UDP= source port, plus
=C2=A0 =C2=A0 =C2=A0 =C2=A0outer IPv6 flowid for entropy.

Looks like a typo.=C2=A0 <=3D14 bits?

No; 14 or 16 depending on the environment. I'll reword as such.


Ok. Re-reading the first 2-3 paragraph= s in section 7 do present the context well.=C2=A0



=C2=A0 =C2=A0 Many Internet protocols use fixed values (typically managed b= y the
=C2=A0 =C2=A0 IANA function) for their next-protocol field.=C2=A0 That faci= litates
=C2=A0 =C2=A0 interpretation of packets by middleboxes and e.g., for debugg= ing
=C2=A0 =C2=A0 purposes, but might make the protocol evolution inflexible.= =C2=A0 Our
=C2=A0 =C2=A0 collective experience with MPLS shows an alternative where th= e label
=C2=A0 =C2=A0 can be viewed as an index to a table containing processing =C2=A0 =C2=A0 instructions and the table content can be managed in differen= t ways.
Would it not be useful to provide a reference here? Just reading this
has questions popping for me - who populates this tag-indexed table of
instructions and could interop be impacted?

The DT added the above text based on comments at the mike from Stewart Brya= nt. I don't know if there is any reference for the general concept. Any= body else know?

In general this implies some control-plane mechanism to populate the table.=

Maybe an addendum to describe that the= control-plane or some human would administer
this would be usefu= l.
=C2=A0

Is there a reference to work which says quiet periods (which i am implicitl= y
reading that in the text above) can be used to change the hash selection? I would think that one needs to closely observe packet trends to make
such a decision. So please provide some ref to some scholarly or
engineering work.
I don't know of citations to such work; perhaps my co-authors have some= .
I recall reading about using markers, but that was a long time ago.
=C2=A0
It would help i think to have some reference= . I am not sure if this applies:

cheers,
jamal
--001a113de0882c5d46051ac05b91-- From nobody Tue Jul 21 05:48:24 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F661A1C06; Tue, 21 Jul 2015 05:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 5tWFx82T4tqX; Tue, 21 Jul 2015 05:48:15 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0BC1A1C00; Tue, 21 Jul 2015 05:48:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B56305A0630; Tue, 21 Jul 2015 05:48:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2742F1C013B; Tue, 21 Jul 2015 05:48:12 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2015 14:48:10 +0200 Message-Id: <564C2726-F2B9-4FDB-AB36-949ADE3C2869@thomasclausen.org> To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" , "homenet@ietf.org Group" , draft-ietf-homenet-hncp.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-homenet-hncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:48:23 -0000 [Apologies for the after-WGLC review] Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-homenet-hncp-07.txt Reviewer: Thomas Heide Clausen Review Date: July 21, 2015 IETF LC End Date: Intended Status: Standards Track Summary:=20 o I have significant concerns about this document and = recommend=20 that the Routing ADs discuss these issues further with = the authors. =09 Comments: =09 o This document is a profile for and specialization of=20 draft-ietf-homenet-dncp, and has a normative dependency on that document. Note that I = produced a RTG-DIR review of draft-ietf-homenet-dncp with several = suggestions a short while ago, to which the authors recently responded = with an updated document. I have not had a chance to review that update, = and iterate with the authors, yet. I also note a RTG-DIR review by = Les Ginsberg,=20 as well as several points raised by Juliusz Chroboczek = on the topic of draft-ietf-homenet-dncp, the resolution of which I = believe may impact draft-ietf-homenet-hncp somewhat significantly.=20 =09 This is one reason for my summary (above) of = "Significant concerns..." -- before this document can be processed, = draft-ietf-homenet-dncp should be squared off. It is not, however, the only reason o As a general comment, the document would do well with a = good editorial overhaul to bring consistency in language usage, = consistency in 2119 terminology, coherence in defined terms and their = definition, document structure, etc. =09 o Related to this, I found that the lack of a terminology = section was=20 unfortunate, and ended up -- for helping my own reading = of the document -- making a napkin-terminology to refer to as I walked = through the doc. (FWIW, I personally prefer the 2119-paragraph to be part = of a terminology section, although that is a minor issue / = personal preference). The words I'd suggest including, and = defining, would be: =09 o Node -- is that a router, a host, or = both? Again, I was=20 given to understand that HOMENET = did not want to redefine host behavior, and so I believe = that the right term would be router? =09 o Privat Link - Common Link -- If you = *insist* on having these concepts, then they definitely = need a clear-cut definition here ; I would prefer, though, = to not have those concepts. o External Interface o Internal Interface o Border o Border router =09 You "import" a lot of terminology from DNCP and from =20 [I-D.ietf-homenet-prefix-assignment], and I found myself = constantly hunting through to figure out which terminology was from = where. Suggest adding a paragraph to the terminology section (assuming = you make one) which recapitulates something like: =09 "Additionally, this document uses terminology = from DNCP, =20 specificially the terms XXX, YYY, ZZZ are to be = interpreted as=20 described therein. =09 This document also uses terminology from [I-D.ietf-homenet-prefix-assignment], = specifically the terms WWW, UUU, QQQ are to be interpreted as described = therein". =20 Reason being: when I came across a term (say "Shared = Link"), I wanted=20 to make sure that I understood what that was. So I went = to the=20 terminology section. Well, there was none. So I went to = grep through this document. Didn't really find a definition. So I = started looking through the references to see if there might be = something that made sense. Fortunately, my guess of what I-D to check first = was right, but it still was more work than it should have been. = =09 =09 =09 Major Issues: o I made this very same comment to = draft-ietf-homenet-dncp, as I am going to make here.=20 =09 The introduction does not read well; it contains parts = of something that could be considered as part of an applicability = statement (without it being called out as such, and without forming a complete = applicability statement), and does not actually introduce the = protocol. Reading just=20 the introduction and the abstract, it is very obscure = what HNCP is=20 actually accomplishing, and why one would chose to use = HNCP.=20 =09 It does, however, transpire that "whatever it is", it = imposes a src-dst routing protocol -- although, that is actually at odds = with the claim=20 (from the Abstract) that the use of HNCP allows = "...seamless use of a=20 routing protocol." ... given that, afaik, no = standardized src-dst routing protocols currently exist. =09 As I recommended for DNCP (hey, at least I'm being = somewhat consistent...) I suggest that a proper introduction = consisting of three parts would be beneficial: (i) what this document is, = (ii) what doing HNCP actually gets you, and (iii) the operating = conditions under which HNCP is applicable. =09 I am calling this out as a major issue, since I believe = that it is not just editorial, but is a matter of scoping this = document correctly, and in particular not falling into the trap of "claiming = applicability where it's not".=09 =09 o 4. Common Links =09 =46rom the document: =09 "HNCP uses the concept of Common Links for some of = its applications. A Common Link usually refers to a link layer = broadcast domain with certain properties and is used, e.g., to determine = where prefixes should be assigned or which neighboring nodes = participate in the election of a DHCP(v6) server. The Common Link is = computed separately for each local interface, and it always = contains the local interface. Additionally, if the local = interface is not in ad-hoc mode, it also contains the set of interfaces = that are bidirectionally reachable from the given local = interface, i.e. every remote interface of a remote node meeting all of the = following requirements:" =09 =09 Several issues here: =09 0) "refers to a link layer broadcast = domain" -- sounds like a "full broadcast link" or "something that = looks like an Ethernet" 1) "some of its applications" -- what are = those? 2) "usually refers to a ..." -- so, that = means that there are=20 situations where you use it to refer to = something else, then?=20 Please don't do that.... 3) "is computed seperately for each local = interface" -- wait, in 0) it was defined in terms of physical = properties, now it is=20 something which is computed? 4) "which neighboring nodes participate in = the election of a DHCP(v6) server" -- is that a hidden = requirement that slid in, that DHCP(v6) servers are part of the = architecture? SLAAC is out, then? Is that a conscious = architectural decision? =09 Now, I actually read in section 5, = bullet number 2 that "if an interface can receive a delegated = prefix by running a DHCPv6 client on the interface, it must = be considered external". So, at least, if a "common = link" connects "internal interfaces" then if DHCPv6 servers are = active on a common link, then this imposes constraints on = what these DHCPv6=20 servers are allowed to serve ... This = *really* merits being called out, the relationship DNCP-DHCP = is murky, at best. =09 5) "if the local interface is not in ad-hoc = mode" -- haaaaang on, if we are talking about an 802.11/WiFi = interface, "ad hoc mode=E2=80=9D=20 does not result in links that look like = in 0) ....not at all, actually.=09 =09 6) "if the local interface is not in ad-hoc = mode" -- I am not sure that this is actually "the right term" = nor that it is universally understood. At least, I have = personally had a heck of a time conveying what that meant when = charaterizing a link =E2=80=94=20 especually within the IETF" =09 7) Reading forward in the document, there's = something more on that in section 5 on page 6 where the = document talks about an "ad hoc category", and where it actually says = something about=20 "transitivity properties" -- = specifically that it is not=20 assumed, then a reference to section 4 = is given as-if there was any further discussion on this point. =09 =09 8) "set of interfaces that are = bidirectionally reachable from the given local interface" -- I take it = that this means that the below=20 specifies a part of a protocol (HELLO = protocol), which only run=20 over "ad hoc interface types"? If "yes" to 8), then I would recommend that you define = the interface types, and their behaviors, completely -- both what = characteristics you expect from the interface (and "ad hoc mode" is not = sufficient...), and what behaviors you exhibit across them. You have, in = this text, half-way defined "broadcast link type" and half-way defined a = "non-transitive non-reflexive link type" =09 Also, I really do not understand the choice of "Common = Link" as section header, and as a term. How is that definition different = from "an IP link"? Are the protocol mechanisms that you provide for = what you call "ad hoc mode" providing something which looks like an IP = limk to "the rest of the protocol", etc. =09 I am afraid that I do not understand what a common link = is. Are you=20 trying to define a link model? =09 o 3. DNCP Profile The document reads: =09 "A node implementing HNCP SHOULD generate and use a random node identifier. If = using a random node identifier and there is a node identifier = collision, the node MUST immediately generate and use a new random = node identifier which is not used by any other node." =20 Awesome, but that raises two questions: 1) How does a node detect identifier = collision?=20 2) How does a node generate an identifier = which is not used by any=20 other node? =09 It would seem that if 2) is actually possible, then a = colission should never ever happen. Also, if 1) and 2) are done "by this protocol", put in a = forward reference to where the corresponding mechanisms exist. = Or if done by DNCP or something else, stick in a reference. =09 As it is, it reads a little like: "...and then some magic happens, and then = poppies and pink unicorns" ;) =09 The document reads: =09 "o HNCP nodes use the following Trickle = parameters: - k SHOULD be 1, as the timer reset when = data is updated and further retransmissions should handle packet = loss." =20 I am wondering what the justification for "k=3D1" is = here? Actually, I can infer what it is: the topology in a homenet is = constituted by full-broadcast Ethernet links, with the assumption that = "if one station receives a transmission, all stations on the link = received the transmission" -- if so, then this is actually part of = the applicability=20 statement for HNCP: "MUST only be used on Ethernet-like = links and MUST NOT be used on non-transitive, non-reflexive, or on = lossy, links". =09 If this interpretation is correct, then you probably = should explain yourself -- for once, I am mostly in agreement with the = use of a SHOULD. =09 One question, however: for a router with multiple = interface, do you run the Trickle algorithm per interface? Would probably = merit clarification. If it is already said in DNCP (I do not recall if it is, = and couldn't immediately find it), perhaps a reminder and a pointer = would be good? =09 o Section 4 & 5 The document seems to define a set of interface types = and link types, but without any clear relationship between them -- and, = worse, without any discussion of what characterize each, what behaviors = are exhibited over each, and what impacts on the system/network = behavior and performance each has. Further, the definitions of the = different interface/link types are incomplete, and seem tied to = (without naming=20 explicitly) specific L2's...hinted at, but not actually = referenced. =09 o Section 5 =09 The document reads: "HNCP router's interfaces are either internal, = external or of a different category derived from the internal one." =20 So, this text tells me that there are n different = categories of interface, where n>=3D2 -- but does not tell me what = defines those different interface categories, or what the actual value = for n is. Nor does this tell me if I should expect different behaviors = across these interfaces, or not. =09 Could the document be more specific? =09 The text goes on: "It is suitable for both IPv4 and IPv6 (single = or dual-stack) and=20 determines whether an HNCP interface is = internal, external, or=20 uses another fixed category." =20 So what's "another fixed category"? Is that different = from "a different category derived from the internal one" discussed = earlier? Again, what behaviors to expect, exhibit, across these? =09 With that being said, I would really recommend that the = document defines what a border is, in this context. How do I identify it, = what characterizes a boarder (which perhaps falls off from = "what characterizes an internal and external interface). =09 I assume that "internal interface" means "internal to = the Internet" whereas "external" means "external to the internet, = i.e., part of the homenet" -- right? Of course, I am yanking your chain = here, but you must define precisely what these mean. External and Internal = are relative terms... =09 On that, reading through the algorithm that you give, = eseentially you define as "external" anything on which a DHCPv4 or = DHCPv6-PD server answers, correct? Other than having a hard time = reconciling that with=20 issue 4 under "common links" in Major Issues, that does = seem to assume an architectural choice which imposes constraints ("thou = shalt not run a DHCP server inside a homenet whilst running HNCP") = which, at least, needs to be called out in the applicability statement = for HNCP, and probably even merits more global discussion and decision = by the WG?=20 =09 But wait, then below the algorithm I read this: =09 "In order to avoid conflicts between border = discovery and HNCP routers running DHCPv4...." =09 ...and then, requirements that such routers must include = a User-Class string. That actually means that the specified algorithm = is incorrect -- underspecified: the algorithm must capture the = "...unless an User-Class string of .... is included", where = appropriate. =09 Sure, with efforts of the "...I thought this over, and I = am sure that the authors must have meant XXXX", it's probably = possible to implement but I'd much prefer to have the document tell me what to = implement, rather than have it tell me to guess. =09 The last paragraph in section 5 is hugely important: = that is where the normative behavior for each interface category is = detailed - but, I think, only part of the normative behavior is actually = specified therein. This is relative to what I mentioned earlier, = that for an interface/link type/category, it would be helpful to = have specified precisely (i) how to determine if a given interface/link = falls within it, (ii) what precise behaviors to expect over than = interface/link. =09 =09 o Section 6 Related to my last comment above to section 5, section 6 = brings out "border routers" -- which is not actually defined in the = document.=20 Some specific behavior is specified for a "border = router" and that brings me to expecting to see: =09 o A precise definition of when a router = is, or is not, a=20 border router (given a router, how do I = determine if I should configure it to exhibit that = "specific behavior" =09 o A precise and complete definition of = which behaviors a "border router", once identified, should = expect and exhibit. =09 The current text does not do that. Again, I could = perhaps try to guess, but for a document aiming for std.track, I really should = not have to. =09 =09 o Section 6.1 "Each HNCP router MAY obtain external connection = information from one or more sources, e.g., DHCPv6-PD [RFC3633], = NETCONF [RFC6241] or static configuration. This section = specifies how such information is encoded and advertised." What is "connection information"? Do you mean "prefixes, = addresses,=20 routing information, DNS resolvers" and such? Or does = it mean "bitrate, error rate, propagation delay"? Or something else? = Again, I could probably guess, and might even get it right, but in a = std.track document I really shouldn't have to. =09 =09 "o MAY contain at most one DHCPv6 Data TLV and = at most one DHCPv4=09 Data TLV encoding options associated with the = External Connection but MUST NOT contain more than one of = each otherwise the External Connection TLV MUST be ignored. o MAY contain other TLVs for future use. Such = additional TLVs MUST be ignored." Several comments to that specifically, and to the TLV = description in general (please apply also to the other signals/TLVs as=20= appropriate, the comments to this TLV description / = bullet apply through section 6): =09 0) You define a TLV "EXTERNAL-CONNECTION", = within which you have other TLVs, correct? Would it not be = clearer if those "other TLVs" be called "sub-TLVs" and that term = used systematically, so as to distinguish them from the = top-level DNCP TLVs. =09 I note that you then set up "sub-sub = TLVs" such as "Prefix Domain". So that means that we'll see: =09 o An EXTERNAL-CONNECTION = TLV, containing o A = DELEGATED-PREFIX TLV, containing o A = PREFIX-DOMAIN TLV =09 Correct? The first question that springs to mind = is one of IANA registries. Are you setting up, for each = TLV type, a new registry for sub-TLV-types? Or, are all = TLV types out of one global space? =09 More importantly, if out of a global TLV = type space, what happens if, say, a "PREFIX-DOMAIN" TLV = is received outside of=20 a "DELEGATED-PREFIX" TLV? Is that valid? = Should it be? What behavior should I, as an implementer, = exhibit if I receive that? =09 This, really, is a question about what = the context for processing each (sub)TLV os, or should = be, which is not specified in the document. It is also = related to issue 2) below. =09 =09 1) I would suggest a phrasing such as: "MAY contain at most one ... and at most = one DHCPv4 ... with the external connection." =20 2) The second part of the first bullet: "MUST not contain more than one = ... MUST be ignored" =09 That should, IMO, be a generic comment = for all (sub)-TLVs, and=20 brought forward to section 6.0 or 6.1, = for example some wordsmithing on: =09 "Any received TLV, which does = not satisfy the requirements specified in the below, MUST be = silently discarded, and MUST be ignored for processing. =20 More to the point, these TLVs (and = (sub-)TLVs) are speicified as=20 being in a specific order, or at least = in a specific hierarchy (TLV within another TLV) on = transmission. What are the constraints on their processing? At what = point shall I discard information based on it being received = "out of place" (such as a "DELEGATED-PREFIX" TLV not contained = in an=20 "EXTERNAL-CONNECTIVITY" TLV)? =09 3) This leads to a general question: are = all the constraints on the sub-TLVs contained in this TLV = completely specified? =09 I would actually like to see a = check-list of "constraints" that I could implement checks for, both when = generating and processing protocol messages. 4) Generally, to the fields in the TLVs, I = do not see the encoding, (unsigned/signed, endianness, ...) = stipulated. Rather important for interoperability, this MUST be = clarified. =09 5) I am generally not a great fan of having = some constraints in the picture (such as the length >=3D 9) and = some in the text (such as "MUST NOT have more than n occurences of = FOOBAR").=20 =09 6) "May contain other TLVs or future use" = -- sure, but then you go on to say "these MUST be ignored". = Strictly speaking, that means that you can't "future use" them either. = How about: =09 "May contain TLVs of other type, = for future use. For the=20 purporse of the processing = specified in this document,=20 such TLVs of unknown TLV type = MUST be ignored". =20 Note the subtlty here: "unknown TLV = types" -- what does that mean? We're actually back at the = IANA/hierarchical/sub-TLV=20 discussion. Assuming that you have just = one, flat IANA registry, such as you actually have. An = EXTERNAL-CONNECTIVITY TLV sure is a "known TLV Type". If you get a = DELEGATED-PREFIX TLV containing an EXTERNAL-CONNECTIVITY TLV, is that = valid, or must that be ignored? =09 So, with the current set-up of IANA = registries, the "unknown TLV=20 types" is not the right phrase. =09 My preference in this sort of situation = is actually to set up hierarchical IANA registries: =09 o DNCP sets up the = top-level TLV type registry. o HNCP specifies (from = within that regitry) the EXTERNAL-CONNECTIVITY = TLV type, which: o Sets up = a new registry for sub-TLV types o = Allocates the DELEGATED-PREFIX from that new registry =09 (and so on). =09 What it does is to set up a context in = which "unknown TLV type" (and such) means something -- and also = solves the rest of the processing context comments above =09 Alternatively, sure, you could put = something like: =09 =09 "May contain TLVs of other type, = for future use. For the=20 purporse of the processing = specified in this document,=20 TLVs of types other than FOO, = BAR, FOOBAR, and GNYF type MUST be ignored". =09 IMO this is less flexible and leads to = more repetition. =09 o Section 6.1.2 =09 The document reads: =09 "Valid Lifetime: The time in seconds the = delegated prefix is=20 valid. The value is relative to the point in = time the Node-Data TLV was last published. It MUST be updated = whenever the node republishes its Node-Data TLV." =20 I just can't parse that. Well, I can, but what I get doesn't = make sense to me: =09 "relative to the point in time the Node-Data TLV was = last published"=20 =09 So, I publish a NODE-DATA TLV. Must I now remember when I = did that, say,=20 at t0, and then next time I publish a NODE-DATA TLV include = (t-t0) as Valid=20 Lifetime? That does look like what the text says, but it = also doesn't sound like a "Vaid Lifetime". Given the name of the = field,=20 Lifetime, I would expect it to mean "Upon receiving this = TLV, please consider the information valid for this much time" -- but, = that's not what the text says.=09 Same comment applies to Preferred Lifetime Also, from this section: =09 "* Zero or more Prefix Domain TLVs. In absence = of any such TLV the prefix is assumed to be generated by an = HNCP-router and for internal use only." Could gain from being a little more specific: what is = "internal use only" (internal to whom?) -- related to my previous = comment about definition of External/Internal. Also "use" -- do you = mean that "this prefix MUST NOT be leaked externally, i.e., addresses = from within this=20 prefix MUST NOT be used as a source address for traffic = outside the homenet? If so, does this mean that you allow a homenet = router to grab any odd global prefix and treat as private? Or, is this = a matter of simply reflecting the already existing "don't route = 192.168/16" (and=20 equiv.) rules? =09 Either way, that needs to be clarified. =09 o 6.2.1 =09 "All HNCP nodes running the prefix assignment = algorithm MUST use the=09 following parameters:" =20 First, I think that an element of clarification would be = good. These parameters, where are they from? Do they come from [I-D.ietf-homenet-prefix-assignment], are they in that = specification given as "optional" (so that one might get the idea to = not use them), or? =09 Second, is it the parameters - or their values - that = must be used? =09 This goes a little bit deeper; I think that what you are = doing here is, in part, to specify "which values to assign to the = different parameters from [I-D.ietf-homenet-prefix-assignment]" -- although = that document=20 is not particularly clear on which parameters form the = interface to HNCP and to other protocols. =09 But, the question is, what does it mean to "MUST use the = following=20 parameters" here? I can see that using these = terms/definitions in the description of HNCP makes sense, but that does not a = "MUST use=20 the following parameters" make.=20 So, I simply do not understand what you intend with = 6.2.1. =09 o Section 6.2.2, 6.3, etc.... =09 This links in with previous comments regarding the = hierarchy and location of protocol elements. The TLVs defined herin, = are they "top level TLVs" or are they sub-TLVs, to be carried = within another TLV? And, what's the context of their processing. =09 This point is particularly obscure since the protocol = does not act symmetric nor consistent here:=20 =09 o it defines an "EXTERNAL-CONNECTION" TLV = (which really is what other protocols would call a = "messagge") which carries sub-TLVs that have to do with = describing "EXTERNAL CONNECTIONS". =09 o But, for Prefix Assignments, it does, as = far as I can tell, not define a "PREFIX-ASSIGNMENT" message = (apologies, TLV) which contains the related sub-TLVs =09 I would like to see this through through -- ideally, = re-engineered to be homogenous and consistent, but (at the very strict = minimum) called out and explained clearly. =09 o 6.2.3. Making New Assignments "Whenever the Prefix Assignment Algorithm subroutine = is run on a Common Link and whenever a new prefix may be = assigned (case 1 of the subroutine), the decision of whether the assignment = of a new prefix is desired MUST follow these rules: " =20 Hold on there for a second: =09 1) What is "the Prefix Assignment Algorithm = subroutine"? Throw a citation into = [I-D.ietf-homenet-prefix-assignment] here, so=20 the random reader knows what you're = talking about -- and, a=20 section reference, also. =20 2) This is exacerbated by the fact that the = descripton pointing to "case 1 of the subroutine". I guess that that correspinds to "bullet = number 1" on page 9 in [I-D.ietf-homenet-prefix-assignment], = but in a proposed=20 standard, guessing should not be needed. =09 3) =20 That aside, subroutines are programming = constructs, not specification elements. Just out of = spite, I'll go implement HNCP using GOTO's instead of = "subroutines" =09 4) I notice that sometimes this is called = the "Distributed Prefix Assignment Algorithm", at other times = "prefix assignment algorithm=E2=80=9D,=20 then "Prefix Assignment Algorithm = subroutine", etc. =09 o Are they all the same? o If yes, then why are = they written, and capitalized, differently? o If no, then what're the = differences between them? =09 =20 Next, the document reads: =09 "If the Delegated Prefix TLV contains a DHCPv4 = or DHCPv6 Data TLV, and the meaning of one of the DHCP options is = not understood by the HNCP router, the creation of a new prefix = is not desired. This rule applies to TLVs inside Delegated = Prefix TLVs but not to those inside External Connection TLVs." What does "is not desired" mean? =09 "...a new prefix MUST NOT be created?" "...a new prefix SHOULD NOT be created?" "...a new prefix MAY be created, but is not = necessary?" =09 The document reads: =09 "If the remaining preferred lifetime of the = prefix is 0 and there is another delegated prefix of the same IP = version used for prefix assignment with a non-null preferred = lifetime, the creation of a new prefix is not desired." =20 Suggest replacing "non-null" by "non-zero" -- but, = beyond that, what does "is not desired" mean? =09 Same comment for the next paragraph: =09 "Otherwise, the creation of a new prefix is = desired" =09 =09 Am I right in reading these three paragraphs as: =09 1) If then new prefix = MUST NOT be created 2) if then new prefix = MUST NOT be created 3) Otherwise, if then = new prefix MUST be created That is how the text reads, which begs the question: =09 Is it possible for , , = and to all not be satisfied, and what happens in = that case? =20 I *think* that this is a case of underspecification, or = at least where it looks like there's a case of underspecification. =09 o 6.2.4: "MUST create an appropriate route ..." =09 What's "an appropriate route"? Do you mean "install entry into the routing table", or = do you mean to launch a routing process to discover, calculate, or = otherwise obtain that route? Do you need the entire path, or just the "next hop = towards ..."? =09 o 6.2.6 "When an HNCP router receives a request for = prefix delegation ..." =09 OK, how does a HNCP router receive such a request? = Grepping through the document fpr "request" I see no protocol signals that = correspond to this. =09 Then, this: "The assigned prefixes MUST NOT be given to = clients" =09 made me wonder what a "client" is. I see DHCPv6/v4 = client used, occasionally, and in other places I see just "client" -- = is this intentionally, and, if so, what is a "client"? =09 o 6.3 =09 "Nodes MAY, at any time, try to reserve a new = address from any applied Assigned Prefix" =09 What is an "applied Assigned Prefix". Given = capitalization, it is an "Assigned Prefix" that is applied somewhere, I suppose, = but where and to what? The document reads: =09 For any assigned prefix for which SLAAC cannot = be used, the first quarter of the addresses are reserved for routers = HNCP based address assignments, whereas the last three quarters are = left to the DHCPv6 (resp. DHCPv4) elected router (Section 10 specifies = the DHCP server election process). For instance, if the prefix = 192.0.2.0/24 is assigned and applied to a Common Link, addresses = included in 192.0.2.0/26 are reserved for HNCP nodes and the = remaining addresses are reserved for the elected DHCPv4 server. =20 Why "the first quarter"? It seems a rather arbitrary = value? Is it known to be enough/too much/too little? =09 "HNCP routers assign themselves addresses using = the Node Address TLV" =09 =09 OK, but...do they send that TLV to themselves? Or do = they send it to someone else, or ...? Part of the answer to this question is embedded in the = text below the picture in section 6.3, but not all -- and, I believe, = this is potentially another problem of more global scope. =09 Generally, for each message (or TLV) it's good to know = how it is formatted, but it's fantastic to know also how it's generated = and how it is processed. I fali to find that (through and = through) in this document, and that makes it harder to implement. =09 Would it be possible to do something like this, = (generally, for the TLV types defined?): =09 Section X. FOOBAR TLVs =09 Section X.1 Generation A FOOBAR TLV is generated when a, b, c = happens. =09 When generating a FOOBAR TLV, its = content is determined as follows.... =09 Section X.2 Processing On receiving a FOOBAR TLV, take the = following steps ... =09 That would also be the place (in X.1) to state where to put information (for example, when a TLV must be = inside another TLV) or constraints on processing (X.2) for example if a TLV = is invalid=20 unless if contained inside another TLV. =09 o 9 Securing Third-Party Protocols =09 I take issue with the below: =09 "Pre-shared keys (PSKs) are often required to = secure IGPs and other protocols which lack support for asymmetric = security." Pre-shared keys are chosen, in some scenarios and for = whatever reasons, regardless of the capacity of the underlaying protocols = -- even when the protocol(s) (IGP or otherwise) are fully capable of = and completely supports assymetric security. Please address this by a = less broad claim for when PSK are used. =09 But, I wonder, reading this section as a whole: you = generate, and=20 distribute through HNCP, a PSK? So all it takes to get = access to said key is to sit by and passively listen to traffic for a = bit? That does strike me as a dangerous option to have...reading the = security considerations section, there seems to be nothing = securing HNCP against eavesdropping -- or, if there is, that's not called out. =09 I note that the security considerations of DNCP start = out by saying: =09 "If specified in the DNCP profile, either DTLS = [RFC6347] or TLS [RFC5246] may be used to authenticate and encrypt = either some (if specified optional in the profile), or all unicast = traffic" =09 =09 And, section 3 of HNCP states: =09 o HNCP unicast traffic SHOULD be secured using DTLS = [RFC6347] as described in DNCP if exchanged over unsecured = links. UDP on port HNCP-DTLS-PORT is used for this purpose. A node = implementing HNCP security MUST support the DNCP Pre-Shared Key = method, SHOULD support the DNCP Certificate Based Trust Consensus = and MAY support the PKI-based trust method. =20 Note the "SHOULD" and the conditonals "unsecured links" = (not sure what this would be, precisely). I do not know anything = meaningful about DTLS, but I would imagine that sking the SEC-DIR folks = about its use would make sense. =09 All that said...sadly, in many conditions and scenarios = "getting=20 security to work is hard" and in a home scenario the = choice (to minimize the amount of support calls, ...) it would not be hard = to imagine either=20 turning OFF or using lowest-common-denominator security. =09 Say "nothing" over an Ethernet "because physical access = required", and WEP for WiFi (yes, people still do that) and then = declare links "not unsecured" and therfore consider it legitimate to not = implement the SHOULD. =09 Effectively, what I fear here is that if HNCP "proposes = to share PSKs" then a (slightly naive) process might actually trust = those PSKs to be useful for security -- which, in fact, they are not = since they can be exposed by simple eavesdropping? I'd really like a bullet-proof guarantee that any shared = PSKs can't have been (easily) eavesdropped on -- or, would ratehr that = HNCP does not=20 tempt the use of compromized PSKs. =09 o Section 10 What's the solution if the message format changes? For = example, that the type field needs to grow/shrink?=20 =09 I've mentioned this in my DNCP review, but I strongly = believe that it is required to have versioning also capture "the frame = format", and not just the "payload". =09 =09 Minor Issues: o General comments: =09 o I recommend using "non-zero" when = referring to numerical values, and not "non-null" o Abstract Questions: is it clear what "naming" referres to? Is it = "name resolution"? Idem for "network borders", do you configure = those, or discover those?=20 =09 Routing-specific question here: What does "seamless use of a routing protocol" = mean? That any IP routing protocol can be used unmodified? I = *think* that that's not the case, given that the use-case that is often = trotted for homenet includes a multi-homed home - and the = introduction says as much so the abstract probably should reflect that. How about somehting like this for the abstract: =09 "This document describes the Home Networking = Control Protocol (HNCP), an extensible configuration protocol and = a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node = Consensus Protocol (DNCP). HNCP enables automated configuration of = addresses, name resolution, discovery of network borders, and = the use of any src-dest-routing capable routing protocol. o Introduction "HNCP synchronizes state across a small site in = order to allow..." =09 What precisely is a "small site"? Can we qualify that in = terms of, say,=20 number of routers? =09 "The protocol enables use of border discovery" =09 I am not sure that I understand what this means -- in = which way is=20 border discovery *enabled*? Or, do you mean "This = protocol discovers borders"? Or something else? =09 "naming and other services across multiple = links." =09 So, the first paragraph teaches me that HNCP is = applicable somewhere not too big -- but, of course, I do not know what exactly = that is -- , and it does "some stuff, and other services" -- but, of = course, I do not know what those are, or how they are characterized. = That's a little imprecise for an introduction. =09 Suggest being extremely precise. Something like: HNCP "Synchronizes state" by way of [dncp], and = specifies and uses state for providing the following network = services: o FOO o BAR o FOOBAR =09 All specified in this document. Additionally, = HNCP enables other services, characterized by ______, for example = prefix assignment as defined by [I-D.ietf-homenet-prefix-assignment] =09 Which brings me to a question. The abstract, and = introduction, state that HNCP "enables automated configuration of addresses" = -- how is that different from [I-D.ietf-homenet-prefix-assignment]? Or, = is the answer "it isn't, that I-D is required to do that", in which = case what does it mean that HNCP "enables" it?=20 =09 [Of course, reading the document it becomes clear that = HNCP does this=20 by way of a normative reference to = [I-D.ietf-homenet-prefix-assignment], but the abstract and introduction really are = unfortunately phrased] =09 Reading just the introduction, I'd like to be able to = know what HNCP would bring me, exactly? Implementing and turning on = HNCP would do what to my network?=20 =09 o 3. DNCP Profile =09 "HNCP is defined as a profile of DNCP..." =09 Is it not more correctly to say that" =09 "HNCP is a profile for DNCP..." =09 ? =09 "HNCP routers MUST assign a unique 32-bit = endpoint identifier to each interface for which HNCP is enabled." =09 Any additional requirements to that identifier? Reading = into DNCP, that is actually not entirely clear there. I *think* that the = endpoint identifier MUST be unique to the local node, but that = there's no requirement beyond that -- correct? Could that be called out both in this document, and = perhaps in DNCP more clearly? =09 Following the above: =09 "The value zero is reserved for internal = purposes." =09 What internal purposes would that be? Reading through, = hidden in the description of the frame format (6.2.2) I read: =09 "The endpoint identifier of the local interface that belongs to the Common Link the prefix is = assigned to, or 0 if the Common Link is a Private Link (e.g., when the = prefix is assigned for downstream prefix delegation)." =20 OK, so leaving that slightly odd phrasing (and the = notion of "Common Link" and "Private Link" -- both of which we will come = back to) for a later comment, can we not bring this up to section 3, = thus: =09 =09 "HNCP routers MUST assign a 32-bit endpoint = identifier, unique to the local node, to each interface for which = HNCP is enabled. The value zero MUST NOT be used, except as endpoint = identifier for an interface towards a Private Common Link" =09 ? =09 [but, I am no great fan of "Private Link" or "Common = Link", see other comments] =09 About this: "Received datagrams with an IPv6 source or = destination address which=20 is not link-local scoped" =20 How about: "Received datagrams where either or both of the = IPv6 source or destination address is not link-local scoped" =09 ? =09 As a general comment, this section contains an unordered = set of bullets, where a grouping and some common discussion probably = would make sense.=20 For example, a few concern security directly (e.g., 3 & = 5) but are not=20 really DNCP parametrizations -- whereas others are = (e.g., 6, 7, 8). The bullet-set reads somewhat like "the kitchen sink".=20= (Numbers indicate count from the first bullet in the = block). =09 o 5. Border Discovery The document reads: "A router MUST allow setting a category of = either auto-detected, internal or external for each interface which is = suitable for both internal and external connections. In addition the = following specializations of the internal category are = defined to modify the local router behavior:" =20 What defines if an interface is "suitable" for an = external, or internal, or both, connections? What does "connections" mean in = this context? What=20 requirements are there for an interface to be "suitable" = respectively "unsuitable"? =09 As part of the discussion of the different categories, = some are declared as SHOULD, others as OPTIONAL. I do not see any which = are MUST. I see that the two SHOULD should be MUST =20 =20 Also: =09 Hybrid category: This declares an interface to = be internal while still running DHCPv4 and DHCPv6-PD clients on it. It is = assumed that the link is under control of a legacy, trustworthy = non-HNCP router, still within the same network. Detection of = this category automatically in addition to manual configuration is out = of scope of this document. Support for this category is = OPTIONAL. What makes a router "legacy"? What makes it = "trustworthy"? =09 o In section 6.1.2 I see: =09 "Nested TLVs: Other TLVs included in the = Delegated Prefix TLV and starting at the next 32-bit boundary following = the end of the encoded prefix:" =20 "Prefix: Significant bits of the prefix padded = with zeroes up to=20 the next byte boundary." Question:=20 Other than "because historically that's how we = did things, because, at the time, that was a good idea", is = there any good reason that you're insisting on byte/32-bit = alignments here? It's been a good while since I've personally written = code where 32 bit alignment was a major concern -- but, when generating = a packet I sure could see it as a minor nuisance to do the = alignment.=20 So, I actually see this as "a nuisance = introduced in packet generation, for no real gain in parsing". =09 (Note that this is in the MINOR category, = though) o 6.2.3: =09 "In any case, a router MUST support a mechanism = suitable to distribute addresses from the considered prefix = if the link is intended to be used by clients. In this case a = router assigning an IPv4 prefix MUST support the L-capability and a = router assigning an IPv6 prefix MUST support serving router = advertisements. In addition if an assigned IPv6 prefix is not = suitable for Stateless Address Autoconfiguration the router MUST also = support the H-capability as defined in Section 10. =20 To your credit, you put a forward pointer to Section 10. = With that being said, would it not be more logical to discuss that = (which appears as "the overall message format of HNCP") somewhere = earlier? =09 Nits: o Any reason why some TLV types are written in ALL-CAPS = whereas others in=20 Hyphenated-Camel-Case? =09 o I saw a few "e.g." and "i.e.", which I believe the style = guide prescribes should be "i.e.," and "e.g.,". Yeah, the RFC = Editor will catch this ultimately, but if you re-spin the document = then might as=20 well make their life just a bit easier ;)= From nobody Tue Jul 21 07:38:38 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4BB1B2E92; Tue, 21 Jul 2015 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.398 X-Spam-Level: X-Spam-Status: No, score=-101.398 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, J_CHICKENPOX_35=0.6, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 snGoT839wR8O; Tue, 21 Jul 2015 07:38:21 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (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 07EE51B2E89; Tue, 21 Jul 2015 07:38:20 -0700 (PDT) Received: by obbop1 with SMTP id op1so117487576obb.2; Tue, 21 Jul 2015 07:38:20 -0700 (PDT) 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=NzZtWWghZmuDLqHqSnlLhOZVcZJ7XtwBpafoEc+05WU=; b=zhQ4guU6Z46PR5p2AnJ7mh4hVX3M1DQdE/OFkZTF/NztmdCi+X3rL66gd+4YVok/Pb Sa786dmDhOE2ruW0AjH+5qojZURJHlrodSj9Hm6SVHSYCFSWFNF2IAIHQTf4o0Uu/pki GmpAwDE8uF+clDYkJzjMhGXQaKjAcYFy188d4DJ0wIdru0t3YtxXS1OG+ZemteistE7S fH1TsJbah8Hr3lwou9sAX5+ldLJy8hbOU1S+0nWueisFwaOhG+ddOGv7AllnVB81gWXm U6avG7tIM37qQ7ExBB2hXoIipkeSCjFohLu4uW1uhYOpHlx4/HAhzKHXTD8A4FAZJFr5 tRag== MIME-Version: 1.0 X-Received: by 10.182.39.194 with SMTP id r2mr22036120obk.20.1437489500155; Tue, 21 Jul 2015 07:38:20 -0700 (PDT) Received: by 10.60.41.99 with HTTP; Tue, 21 Jul 2015 07:38:20 -0700 (PDT) In-Reply-To: <564C2726-F2B9-4FDB-AB36-949ADE3C2869@thomasclausen.org> References: <564C2726-F2B9-4FDB-AB36-949ADE3C2869@thomasclausen.org> Date: Tue, 21 Jul 2015 10:38:20 -0400 Message-ID: From: Alia Atlas To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a11c1d8d6067612051b639b63 Archived-At: Cc: "" , "homenet@ietf.org Group" , draft-ietf-homenet-hncp.all@tools.ietf.org, "" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-homenet-hncp-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 14:38:35 -0000 --001a11c1d8d6067612051b639b63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thomas, Thank you very much for the review! I look forward to the results of the discussion with the authors. Alia On Tue, Jul 21, 2015 at 8:48 AM, Thomas Clausen wrote: > [Apologies for the after-WGLC review] > > Hello, > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-homenet-hncp-07.txt > Reviewer: Thomas Heide Clausen > Review Date: July 21, 2015 > IETF LC End Date: > Intended Status: Standards Track > > Summary: > o I have significant concerns about this document and > recommend > that the Routing ADs discuss these issues further with th= e > authors. > > Comments: > > o This document is a profile for and specialization of > draft-ietf-homenet-dncp, and > has a normative dependency on that document. Note that I > produced a > RTG-DIR review of draft-ietf-homenet-dncp with several > suggestions a > short while ago, to which the authors recently responded > with an updated > document. I have not had a chance to review that update, > and iterate > with the authors, yet. I also note a RTG-DIR review by Le= s > Ginsberg, > as well as several points raised by Juliusz Chroboczek on > the topic of > draft-ietf-homenet-dncp, the resolution of which I believ= e > may impact > draft-ietf-homenet-hncp somewhat significantly. > > This is one reason for my summary (above) of "Significant > concerns..." > -- before this document can be processed, > draft-ietf-homenet-dncp should > be squared off. It is not, however, the only reason > > o As a general comment, the document would do well with a > good editorial > overhaul to bring consistency in language usage, > consistency in 2119 > terminology, coherence in defined terms and their > definition, document > structure, etc. > > o Related to this, I found that the lack of a terminology > section was > unfortunate, and ended up -- for helping my own reading o= f > the document > -- making a napkin-terminology to refer to as I walked > through the doc. > (FWIW, I personally prefer the 2119-paragraph to be part > of a > terminology section, although that is a minor issue / > personal > preference). The words I'd suggest including, and > defining, would be: > > o Node -- is that a router, a host, or both= ? > Again, I was > given to understand that HOMENET > did not want to redefine > host behavior, and so I believe > that the right term would > be router? > > o Privat Link - Common Link -- If you > *insist* on having these > concepts, then they definitely > need a clear-cut definition > here ; I would prefer, though, to > not have those concepts. > > o External Interface > o Internal Interface > o Border > o Border router > > You "import" a lot of terminology from DNCP and from > [I-D.ietf-homenet-prefix-assignment], and I found myself > constantly > hunting through to figure out which terminology was from > where. Suggest > adding a paragraph to the terminology section (assuming > you make one) > which recapitulates something like: > > "Additionally, this document uses terminology fro= m > DNCP, > specificially the terms XXX, YYY, ZZZ are to be > interpreted as > described therein. > > This document also uses terminology from > [I-D.ietf-homenet-prefix-assignment], > specifically the terms WWW, > UUU, QQQ are to be interpreted as described > therein". > > Reason being: when I came across a term (say "Shared > Link"), I wanted > to make sure that I understood what that was. So I went t= o > the > terminology section. Well, there was none. So I went to > grep through > this document. Didn't really find a definition. So I > started looking > through the references to see if there might be something > that made > sense. Fortunately, my guess of what I-D to check first > was right, but > it still was more work than it should have been. > > > Major Issues: > > o I made this very same comment to draft-ietf-homenet-dncp, > as I am going > to make here. > > The introduction does not read well; it contains parts of > something that > could be considered as part of an applicability statement > (without it > being called out as such, and without forming a complete > applicability > statement), and does not actually introduce the protocol. > Reading just > the introduction and the abstract, it is very obscure wha= t > HNCP is > actually accomplishing, and why one would chose to use > HNCP. > > It does, however, transpire that "whatever it is", it > imposes a src-dst > routing protocol -- although, that is actually at odds > with the claim > (from the Abstract) that the use of HNCP allows > "...seamless use of a > routing protocol." ... given that, afaik, no standardize= d > src-dst > routing protocols currently exist. > > As I recommended for DNCP (hey, at least I'm being somewh= at > consistent...) I suggest that a proper introduction > consisting of three > parts would be beneficial: (i) what this document is, (ii= ) > what doing > HNCP actually gets you, and (iii) the operating condition= s > under which > HNCP is applicable. > > I am calling this out as a major issue, since I believe > that it is > not just editorial, but is a matter of scoping this > document correctly, > and in particular not falling into the trap of "claiming > applicability > where it's not". > > > o 4. Common Links > > From the document: > > "HNCP uses the concept of Common Links for some of its > applications. > A Common Link usually refers to a link layer broadcas= t > domain with > certain properties and is used, e.g., to determine > where prefixes > should be assigned or which neighboring nodes > participate in the > election of a DHCP(v6) server. The Common Link is > computed > separately for each local interface, and it always > contains the > local interface. Additionally, if the local interfac= e > is not in > ad-hoc mode, it also contains the set of interfaces > that are > bidirectionally reachable from the given local > interface, i.e. every > remote interface of a remote node meeting all of the > following > requirements:" > > > Several issues here: > > 0) "refers to a link layer broadcast domain" > -- sounds like a > "full broadcast link" or "something that > looks like an Ethernet" > 1) "some of its applications" -- what are > those? > 2) "usually refers to a ..." -- so, that > means that there are > situations where you use it to refer to > something else, then? > Please don't do that.... > 3) "is computed seperately for each local > interface" -- wait, in > 0) it was defined in terms of physical > properties, now it is > something which is computed? > 4) "which neighboring nodes participate in > the election of a > DHCP(v6) server" -- is that a hidden > requirement that slid in, > that DHCP(v6) servers are part of the > architecture? SLAAC is > out, then? Is that a conscious > architectural decision? > > Now, I actually read in section 5, bullet > number 2 that "if > an interface can receive a delegated > prefix by running a > DHCPv6 client on the interface, it must b= e > considered > external". So, at least, if a "common > link" connects "internal > interfaces" then if DHCPv6 servers are > active on a common > link, then this imposes constraints on > what these DHCPv6 > servers are allowed to serve ... This > *really* merits being > called out, the relationship DNCP-DHCP is > murky, at best. > > 5) "if the local interface is not in ad-hoc > mode" -- haaaaang on, > if we are talking about an 802.11/WiFi > interface, "ad hoc mode=E2=80=9D > does not result in links that look like i= n > 0) ....not at all, actually. > > 6) "if the local interface is not in ad-hoc > mode" -- I am not sure > that this is actually "the right term" no= r > that it is > universally understood. At least, I have > personally had a heck > of a time conveying what that meant when > charaterizing a link =E2=80=94 > especually within the IETF" > > 7) Reading forward in the document, there's > something more on that > in section 5 on page 6 where the document > talks about an "ad hoc > category", and where it actually says > something about > "transitivity properties" -- specifically > that it is not > assumed, then a reference to section 4 is > given as-if there was > any further discussion on this point. > > > 8) "set of interfaces that are > bidirectionally reachable from the > given local interface" -- I take it that > this means that the below > specifies a part of a protocol (HELLO > protocol), which only run > over "ad hoc interface types"? > > If "yes" to 8), then I would recommend that you define th= e > interface > types, and their behaviors, completely -- both what > characteristics you > expect from the interface (and "ad hoc mode" is not > sufficient...), and > what behaviors you exhibit across them. You have, in this > text, half-way > defined "broadcast link type" and half-way defined a > "non-transitive > non-reflexive link type" > > Also, I really do not understand the choice of "Common > Link" as section > header, and as a term. How is that definition different > from "an IP > link"? Are the protocol mechanisms that you provide for > what you call > "ad hoc mode" providing something which looks like an IP > limk to "the > rest of the protocol", etc. > > I am afraid that I do not understand what a common link > is. Are you > trying to define a link model? > > o 3. DNCP Profile > The document reads: > > "A node implementing HNCP > SHOULD generate and use a random node identifier. If > using a > random node identifier and there is a node identifier > collision, > the node MUST immediately generate and use a new random > node > identifier which is not used by any other node." > > Awesome, but that raises two questions: > 1) How does a node detect identifier > collision? > 2) How does a node generate an identifier > which is not used by any > other node? > > It would seem that if 2) is actually possible, then a > colission should > never ever happen. > Also, if 1) and 2) are done "by this protocol", put in a > forward > reference to where the corresponding mechanisms exist. Or > if done by > DNCP or something else, stick in a reference. > > As it is, it reads a little like: > "...and then some magic happens, and then poppies > and pink unicorns" > > ;) > > The document reads: > > "o HNCP nodes use the following Trickle > parameters: > > - k SHOULD be 1, as the timer reset when > data is updated and > further retransmissions should handle packet loss= ." > > I am wondering what the justification for "k=3D1" is here= ? > Actually, I can > infer what it is: the topology in a homenet is constitute= d > by > full-broadcast Ethernet links, with the assumption that > "if one station > receives a transmission, all stations on the link receive= d > the > transmission" -- if so, then this is actually part of the > applicability > statement for HNCP: "MUST only be used on Ethernet-like > links and MUST > NOT be used on non-transitive, non-reflexive, or on lossy= , > links". > > If this interpretation is correct, then you probably > should explain > yourself -- for once, I am mostly in agreement with the > use of a > SHOULD. > > One question, however: for a router with multiple > interface, do you run > the Trickle algorithm per interface? Would probably merit > clarification. > If it is already said in DNCP (I do not recall if it is, > and couldn't > immediately find it), perhaps a reminder and a pointer > would be good? > > o Section 4 & 5 > The document seems to define a set of interface types and > link types, > but without any clear relationship between them -- and, > worse, without > any discussion of what characterize each, what behaviors > are exhibited > over each, and what impacts on the system/network behavio= r > and > performance each has. Further, the definitions of the > different > interface/link types are incomplete, and seem tied to > (without naming > explicitly) specific L2's...hinted at, but not actually > referenced. > > o Section 5 > > The document reads: > "HNCP router's interfaces are either internal, externa= l > or of a > different category derived from the internal one." > > So, this text tells me that there are n different > categories of > interface, where n>=3D2 -- but does not tell me what defi= nes > those > different interface categories, or what the actual value > for n is. Nor > does this tell me if I should expect different behaviors > across these > interfaces, or not. > > Could the document be more specific? > > The text goes on: > "It is suitable for both IPv4 and IPv6 (single or > dual-stack) and > determines whether an HNCP interface is internal= , > external, or > uses another fixed category." > > So what's "another fixed category"? Is that different fro= m > "a different > category derived from the internal one" discussed > earlier? Again, what > behaviors to expect, exhibit, across these? > > With that being said, I would really recommend that the > document defines > what a border is, in this context. How do I identify it, > what > characterizes a boarder (which perhaps falls off from "wh= at > characterizes an internal and external interface). > > I assume that "internal interface" means "internal to the > Internet" > whereas "external" means "external to the internet, i.e., > part of the > homenet" -- right? Of course, I am yanking your chain > here, but you must > define precisely what these mean. External and Internal > are relative > terms... > > On that, reading through the algorithm that you give, > eseentially you > define as "external" anything on which a DHCPv4 or > DHCPv6-PD server > answers, correct? Other than having a hard time > reconciling that with > issue 4 under "common links" in Major Issues, that does > seem to assume > an architectural choice which imposes constraints ("thou > shalt not run > a DHCP server inside a homenet whilst running HNCP") > which, at least, > needs to be called out in the applicability statement for > HNCP, and > probably even merits more global discussion and decision > by the WG? > > But wait, then below the algorithm I read this: > > "In order to avoid conflicts between border > discovery and HNCP > routers running DHCPv4...." > > ...and then, requirements that such routers must include = a > User-Class > string. That actually means that the specified algorithm > is incorrect > -- underspecified: the algorithm must capture the > "...unless an > User-Class string of .... is included", where appropriate= . > > Sure, with efforts of the "...I thought this over, and I > am sure that > the authors must have meant XXXX", it's probably possible > to implement > but I'd much prefer to have the document tell me what to > implement, > rather than have it tell me to guess. > > The last paragraph in section 5 is hugely important: that > is where the > normative behavior for each interface category is detaile= d > - but, I > think, only part of the normative behavior is actually > specified > therein. This is relative to what I mentioned earlier, > that for an > interface/link type/category, it would be helpful to have > specified > precisely (i) how to determine if a given interface/link > falls within > it, (ii) what precise behaviors to expect over than > interface/link. > > > o Section 6 > Related to my last comment above to section 5, section 6 > brings out > "border routers" -- which is not actually defined in the > document. > Some specific behavior is specified for a "border router" > and that > brings me to expecting to see: > > o A precise definition of when a router is, > or is not, a > border router (given a router, how do I > determine if I > should configure it to exhibit that > "specific behavior" > > o A precise and complete definition of whic= h > behaviors a > "border router", once identified, should > expect and exhibit. > > The current text does not do that. Again, I could perhaps > try to guess, > but for a document aiming for std.track, I really should > not have to. > > > o Section 6.1 > "Each HNCP router MAY obtain external connection > information from > one or more sources, e.g., DHCPv6-PD [RFC3633], > NETCONF [RFC6241] > or static configuration. This section specifies > how such > information is encoded and advertised." > > What is "connection information"? Do you mean "prefixes, > addresses, > routing information, DNS resolvers" and such? Or does it > mean "bitrate, > error rate, propagation delay"? Or something else? Again, > I could > probably guess, and might even get it right, but in a > std.track document > I really shouldn't have to. > > > "o MAY contain at most one DHCPv6 Data TLV and a= t > most one DHCPv4 > Data TLV encoding options associated with the > External > Connection but MUST NOT contain more than one of > each otherwise > the External Connection TLV MUST be ignored. > > o MAY contain other TLVs for future use. Such > additional TLVs > MUST be ignored." > > Several comments to that specifically, and to the TLV > description in > general (please apply also to the other signals/TLVs as > appropriate, the comments to this TLV description / bulle= t > apply through > section 6): > > 0) You define a TLV "EXTERNAL-CONNECTION", > within which you have > other TLVs, correct? Would it not be > clearer if those "other > TLVs" be called "sub-TLVs" and that term > used systematically, > so as to distinguish them from the > top-level DNCP TLVs. > > I note that you then set up "sub-sub TLVs= " > such as "Prefix > Domain". So that means that we'll see: > > o An EXTERNAL-CONNECTION > TLV, containing > o A DELEGATED-PREFI= X > TLV, containing > o A > PREFIX-DOMAIN TLV > > Correct? > > The first question that springs to mind i= s > one of IANA > registries. Are you setting up, for each > TLV type, a new > registry for sub-TLV-types? Or, are all > TLV types out of one > global space? > > More importantly, if out of a global TLV > type space, what > happens if, say, a "PREFIX-DOMAIN" TLV is > received outside of > a "DELEGATED-PREFIX" TLV? Is that valid? > Should it be? What > behavior should I, as an implementer, > exhibit if I receive > that? > > This, really, is a question about what th= e > context for > processing each (sub)TLV os, or should be= , > which is not > specified in the document. It is also > related to issue 2) below. > > > 1) I would suggest a phrasing such as: > "MAY contain at most one ... and at most > one DHCPv4 ... with > the external connection." > > 2) The second part of the first bullet: > "MUST not contain more than one > ... MUST be ignored" > > That should, IMO, be a generic comment fo= r > all (sub)-TLVs, and > brought forward to section 6.0 or 6.1, fo= r > example some > wordsmithing on: > > "Any received TLV, which does not > satisfy the requirements > specified in the below, MUST be > silently discarded, and > MUST be ignored for processing. > > More to the point, these TLVs (and > (sub-)TLVs) are speicified as > being in a specific order, or at least in > a specific hierarchy > (TLV within another TLV) on transmission. > What are the > constraints on their processing? At what > point shall I discard > information based on it being received > "out of place" (such as > a "DELEGATED-PREFIX" TLV not contained in > an > "EXTERNAL-CONNECTIVITY" TLV)? > > 3) This leads to a general question: are all > the constraints on > the sub-TLVs contained in this TLV > completely specified? > > I would actually like to see a check-list > of "constraints" that > I could implement checks for, both when > generating and > processing protocol messages. > > 4) Generally, to the fields in the TLVs, I d= o > not see the encoding, > (unsigned/signed, endianness, ...) > stipulated. Rather important > for interoperability, this MUST be > clarified. > > 5) I am generally not a great fan of having > some constraints in the > picture (such as the length >=3D 9) and s= ome > in the text (such as > "MUST NOT have more than n occurences of > FOOBAR"). > > 6) "May contain other TLVs or future use" -- > sure, but then you go > on to say "these MUST be ignored". > Strictly speaking, that means > that you can't "future use" them either. > How about: > > "May contain TLVs of other type, > for future use. For the > purporse of the processing > specified in this document, > such TLVs of unknown TLV type > MUST be ignored". > > Note the subtlty here: "unknown TLV types= " > -- what does that > mean? We're actually back at the > IANA/hierarchical/sub-TLV > discussion. Assuming that you have just > one, flat IANA registry, > such as you actually have. An > EXTERNAL-CONNECTIVITY TLV sure is > a "known TLV Type". If you get a > DELEGATED-PREFIX TLV containing > an EXTERNAL-CONNECTIVITY TLV, is that > valid, or must that be > ignored? > > So, with the current set-up of IANA > registries, the "unknown TLV > types" is not the right phrase. > > My preference in this sort of situation i= s > actually to set up > hierarchical IANA registries: > > o DNCP sets up the top-leve= l > TLV type registry. > o HNCP specifies (from > within that regitry) the > EXTERNAL-CONNECTIVITY TLV > type, which: > o Sets up a > new registry for sub-TLV types > o Allocates > the DELEGATED-PREFIX from that new > registry > > (and so on). > > What it does is to set up a context in > which "unknown TLV type" > (and such) means something -- and also > solves the rest of the > processing context comments above > > Alternatively, sure, you could put > something like: > > > "May contain TLVs of other type, > for future use. For the > purporse of the processing > specified in this document, > TLVs of types other than FOO, > BAR, FOOBAR, and GNYF type > MUST be ignored". > > IMO this is less flexible and leads to > more repetition. > > > o Section 6.1.2 > > The document reads: > > "Valid Lifetime: The time in seconds the > delegated prefix is > valid. The value is relative to the point in tim= e > the Node-Data TLV > was last published. It MUST be updated whenever > the node > republishes its Node-Data TLV." > > I just can't parse that. Well, I can, but what I get doesn't make > sense to me: > > "relative to the point in time the Node-Data TLV was last > published" > > So, I publish a NODE-DATA TLV. Must I now remember when I di= d > that, say, > at t0, and then next time I publish a NODE-DATA TLV include > (t-t0) as Valid > Lifetime? That does look like what the text says, but it also > doesn't sound like a "Vaid Lifetime". Given the name of the > field, > Lifetime, I would expect it to mean "Upon receiving this TLV, > please > consider the information valid for this much time" -- but, > that's not what the text says. > > Same comment applies to Preferred Lifetime > > Also, from this section: > > "* Zero or more Prefix Domain TLVs. In absence > of any such TLV > the prefix is assumed to be generated by an > HNCP-router and for > internal use only." > > Could gain from being a little more specific: what is > "internal use > only" (internal to whom?) -- related to my previous > comment about > definition of External/Internal. Also "use" -- do you mea= n > that "this > prefix MUST NOT be leaked externally, i.e., addresses fro= m > within this > prefix MUST NOT be used as a source address for traffic > outside the > homenet? If so, does this mean that you allow a homenet > router to grab > any odd global prefix and treat as private? Or, is this a > matter of > simply reflecting the already existing "don't route > 192.168/16" (and > equiv.) rules? > > Either way, that needs to be clarified. > > o 6.2.1 > > "All HNCP nodes running the prefix assignment > algorithm MUST use the > following parameters:" > > First, I think that an element of clarification would be > good. These > parameters, where are they from? Do they come from > [I-D.ietf-homenet-prefix-assignment], are they in that > specification > given as "optional" (so that one might get the idea to no= t > use them), > or? > > Second, is it the parameters - or their values - that mus= t > be used? > > This goes a little bit deeper; I think that what you are > doing here is, > in part, to specify "which values to assign to the > different parameters > from [I-D.ietf-homenet-prefix-assignment]" -- although > that document > is not particularly clear on which parameters form the > interface to HNCP > and to other protocols. > > But, the question is, what does it mean to "MUST use the > following > parameters" here? I can see that using these > terms/definitions in > the description of HNCP makes sense, but that does not a > "MUST use > the following parameters" make. > > So, I simply do not understand what you intend with 6.2.1= . > > o Section 6.2.2, 6.3, etc.... > > This links in with previous comments regarding the > hierarchy and > location of protocol elements. The TLVs defined herin, ar= e > they > "top level TLVs" or are they sub-TLVs, to be carried > within another TLV? > And, what's the context of their processing. > > This point is particularly obscure since the protocol doe= s > not act > symmetric nor consistent here: > > o it defines an "EXTERNAL-CONNECTION" TLV > (which really > is what other protocols would call a > "messagge") which > carries sub-TLVs that have to do with > describing "EXTERNAL > CONNECTIONS". > > o But, for Prefix Assignments, it does, as > far as I can tell, > not define a "PREFIX-ASSIGNMENT" message > (apologies, TLV) > which contains the related sub-TLVs > > I would like to see this through through -- ideally, > re-engineered to > be homogenous and consistent, but (at the very strict > minimum) called > out and explained clearly. > > o 6.2.3. Making New Assignments > > "Whenever the Prefix Assignment Algorithm subroutine i= s > run on a > Common Link and whenever a new prefix may be > assigned (case 1 of the > subroutine), the decision of whether the assignment o= f > a new prefix > is desired MUST follow these rules: " > > Hold on there for a second: > > 1) What is "the Prefix Assignment Algorithm > subroutine"? Throw a > citation into > [I-D.ietf-homenet-prefix-assignment] here, so > the random reader knows what you're > talking about -- and, a > section reference, also. > > 2) This is exacerbated by the fact that the > descripton pointing to > "case 1 of the subroutine". > I guess that that correspinds to "bullet > number 1" on page 9 > in [I-D.ietf-homenet-prefix-assignment], > but in a proposed > standard, guessing should not be needed. > > 3) > That aside, subroutines are programming > constructs, not > specification elements. Just out of spite= , > I'll go implement > HNCP using GOTO's instead of "subroutines= " > > > 4) I notice that sometimes this is called th= e > "Distributed Prefix > Assignment Algorithm", at other times > "prefix assignment algorithm=E2=80=9D, > then "Prefix Assignment Algorithm > subroutine", etc. > > o Are they all the same? > o If yes, then why are they > written, and capitalized, > differently? > o If no, then what're the > differences between them? > > > Next, the document reads: > > "If the Delegated Prefix TLV contains a DHCPv4 or > DHCPv6 Data TLV, > and the meaning of one of the DHCP options is no= t > understood by > the HNCP router, the creation of a new prefix is > not desired. > This rule applies to TLVs inside Delegated Prefi= x > TLVs but not to > those inside External Connection TLVs." > > What does "is not desired" mean? > > "...a new prefix MUST NOT be created?" > "...a new prefix SHOULD NOT be created?" > "...a new prefix MAY be created, but is not > necessary?" > > The document reads: > > "If the remaining preferred lifetime of the prefi= x > is 0 and there > is another delegated prefix of the same IP > version used for prefix > assignment with a non-null preferred > lifetime, the creation of a > new prefix is not desired." > > Suggest replacing "non-null" by "non-zero" -- but, beyond > that, what > does "is not desired" mean? > > Same comment for the next paragraph: > > "Otherwise, the creation of a new prefix is > desired" > > > Am I right in reading these three paragraphs as: > > 1) If then new prefix > MUST NOT be created > 2) if then new prefix > MUST NOT be created > 3) Otherwise, if then > new prefix MUST be created > > That is how the text reads, which begs the question: > > Is it possible for , , an= d > > to all not be satisfied, and what happens in that > case? > > I *think* that this is a case of underspecification, or a= t > least where > it looks like there's a case of underspecification. > > > > o 6.2.4: > "MUST create an appropriate route ..." > > What's "an appropriate route"? > Do you mean "install entry into the routing table", or do > you mean to > launch a routing process to discover, calculate, or > otherwise obtain > that route? > Do you need the entire path, or just the "next hop toward= s > ..."? > > o 6.2.6 > "When an HNCP router receives a request for prefi= x > delegation ..." > > OK, how does a HNCP router receive such a request? > Grepping through the > document fpr "request" I see no protocol signals that > correspond to > this. > > Then, this: > "The assigned prefixes MUST NOT be given to > clients" > > made me wonder what a "client" is. I see DHCPv6/v4 client > used, > occasionally, and in other places I see just "client" -- > is this > intentionally, and, if so, what is a "client"? > > o 6.3 > > "Nodes MAY, at any time, try to reserve a new > address from any > applied Assigned Prefix" > > What is an "applied Assigned Prefix". Given > capitalization, it is an > "Assigned Prefix" that is applied somewhere, I suppose, > but where and > to what? > > The document reads: > > For any assigned prefix for which SLAAC cannot be > used, the first > quarter of the addresses are reserved for routers HNC= P > based address > assignments, whereas the last three quarters are left > to the DHCPv6 > (resp. DHCPv4) elected router (Section 10 specifies > the DHCP server > election process). For instance, if the prefix > 192.0.2.0/24 is > assigned and applied to a Common Link, addresses > included in > 192.0.2.0/26 are reserved for HNCP nodes and the > remaining addresses > are reserved for the elected DHCPv4 server. > > Why "the first quarter"? It seems a rather arbitrary > value? Is it known > to be enough/too much/too little? > > "HNCP routers assign themselves addresses using > the Node Address > TLV" > > > OK, but...do they send that TLV to themselves? Or do they > send it to > someone else, or ...? > Part of the answer to this question is embedded in the > text below the > picture in section 6.3, but not all -- and, I believe, > this is potentially another problem of more global scope. > > Generally, for each message (or TLV) it's good to know ho= w > it is formatted, but it's fantastic to know also how it's generated and > how it is processed. I fali to find that (through and > through) in this > document, and that makes it harder to implement. > > Would it be possible to do something like this, > (generally, for the TLV > types defined?): > > Section X. FOOBAR TLVs > > > Section X.1 Generation > A FOOBAR TLV is generated when a, b, c > happens. > > When generating a FOOBAR TLV, its content > is determined as > follows.... > > Section X.2 Processing > On receiving a FOOBAR TLV, take the > following steps ... > > That would also be the place (in X.1) to state where > to put information (for example, when a TLV must be insid= e > another TLV) > or constraints on processing (X.2) for example if a TLV i= s > invalid > unless if contained inside another TLV. > > o 9 Securing Third-Party Protocols > > I take issue with the below: > > "Pre-shared keys (PSKs) are often required to > secure IGPs and other > protocols which lack support for asymmetric > security." > > Pre-shared keys are chosen, in some scenarios and for > whatever reasons, > regardless of the capacity of the underlaying protocols -= - > even when > the protocol(s) (IGP or otherwise) are fully capable of > and completely > supports assymetric security. Please address this by a > less broad claim > for when PSK are used. > > But, I wonder, reading this section as a whole: you > generate, and > distribute through HNCP, a PSK? So all it takes to get > access to said > key is to sit by and passively listen to traffic for a > bit? That does strike me as a dangerous option to have...reading the > security > considerations section, there seems to be nothing securin= g > HNCP against > eavesdropping -- or, if there is, that's not called out. > > I note that the security considerations of DNCP start out > by saying: > > "If specified in the DNCP profile, either DTLS > [RFC6347] or TLS > [RFC5246] may be used to authenticate and encrypt > either some (if > specified optional in the profile), or all unicast > traffic" > > And, section 3 of HNCP states: > > o HNCP unicast traffic SHOULD be secured using DTLS > [RFC6347] as > described in DNCP if exchanged over unsecured > links. UDP on port > HNCP-DTLS-PORT is used for this purpose. A node > implementing HNCP > security MUST support the DNCP Pre-Shared Key > method, SHOULD > support the DNCP Certificate Based Trust Consensus > and MAY support > the PKI-based trust method. > > Note the "SHOULD" and the conditonals "unsecured links" > (not sure > what this would be, precisely). I do not know anything > meaningful about > DTLS, but I would imagine that sking the SEC-DIR folks > about its use > would make sense. > > All that said...sadly, in many conditions and scenarios > "getting > security to work is hard" and in a home scenario the > choice (to minimize > the amount of support calls, ...) it would not be hard to > imagine either > turning OFF or using lowest-common-denominator security. > > Say "nothing" over an Ethernet "because physical access > required", and > WEP for WiFi (yes, people still do that) and then declare > links "not > unsecured" and therfore consider it legitimate to not > implement the SHOULD. > > Effectively, what I fear here is that if HNCP "proposes t= o > share PSKs" > then a (slightly naive) process might actually trust thos= e > PSKs to be > useful for security -- which, in fact, they are not since > they can be > exposed by simple eavesdropping? > > I'd really like a bullet-proof guarantee that any shared > PSKs can't have > been (easily) eavesdropped on -- or, would ratehr that > HNCP does not > tempt the use of compromized PSKs. > > o Section 10 > What's the solution if the message format changes? For > example, that the > type field needs to grow/shrink? > > I've mentioned this in my DNCP review, but I strongly > believe that it is > required to have versioning also capture "the frame > format", and not > just the "payload". > > > Minor Issues: > > o General comments: > > o I recommend using "non-zero" when > referring to numerical values, > and not "non-null" > > o Abstract > > Questions: is it clear what "naming" referres to? Is it > "name resolution"? > Idem for "network borders", do you configure > those, or discover those? > > Routing-specific question here: > What does "seamless use of a routing protocol" > mean? That any IP > routing protocol can be used unmodified? I *think= * > that that's not > the case, given that the use-case that is often > trotted for homenet > includes a multi-homed home - and the introductio= n > says as much so > the abstract probably should reflect that. > > How about somehting like this for the abstract: > > "This document describes the Home Networking > Control Protocol > (HNCP), an extensible configuration protocol and = a > set of requirements for home network devices. HNCP is described as a > profile of and extension to the Distributed Node > Consensus Protocol (DNCP). HNCP enables automated configuration of > addresses, name > resolution, discovery of network borders, and the > use of any > src-dest-routing capable routing protocol. > > o Introduction > "HNCP synchronizes state across a small site in > order to allow..." > > What precisely is a "small site"? Can we qualify that in > terms of, say, > number of routers? > > "The protocol enables use of border discovery" > > I am not sure that I understand what this means -- in > which way is > border discovery *enabled*? Or, do you mean "This protoco= l > discovers > borders"? Or something else? > > "naming and other services across multiple links.= " > > So, the first paragraph teaches me that HNCP is applicabl= e > somewhere not > too big -- but, of course, I do not know what exactly > that is -- , and > it does "some stuff, and other services" -- but, of > course, I do not > know what those are, or how they are characterized. That'= s > a little > imprecise for an introduction. > > Suggest being extremely precise. Something like: > HNCP "Synchronizes state" by way of [dncp], and > specifies and uses > state for providing the following network service= s: > o FOO > o BAR > o FOOBAR > > All specified in this document. Additionally, HNC= P > enables other > services, characterized by ______, for example > prefix assignment as > defined by [I-D.ietf-homenet-prefix-assignment] > > Which brings me to a question. The abstract, and > introduction, state > that HNCP "enables automated configuration of addresses" > -- how is that > different from [I-D.ietf-homenet-prefix-assignment]? Or, > is the answer > "it isn't, that I-D is required to do that", in which cas= e > what does it > mean that HNCP "enables" it? > > [Of course, reading the document it becomes clear that > HNCP does this > by way of a normative reference to > [I-D.ietf-homenet-prefix-assignment], > but the abstract and introduction really are unfortunatel= y > phrased] > > Reading just the introduction, I'd like to be able to kno= w > what HNCP > would bring me, exactly? Implementing and turning on HNCP > would do what > to my network? > > o 3. DNCP Profile > > "HNCP is defined as a profile of DNCP..." > > Is it not more correctly to say that" > > "HNCP is a profile for DNCP..." > > ? > > "HNCP routers MUST assign a unique 32-bit endpoin= t > identifier to > each interface for which HNCP is enabled." > > Any additional requirements to that identifier? Reading > into DNCP, that > is actually not entirely clear there. I *think* that the > endpoint > identifier MUST be unique to the local node, but that > there's no > requirement beyond that -- correct? > Could that be called out both in this document, and > perhaps in DNCP more > clearly? > > Following the above: > > "The value zero is reserved for internal purposes= ." > > What internal purposes would that be? Reading through, > hidden in the > description of the frame format (6.2.2) I read: > > "The endpoint identifier of the local interface > that belongs to the Common Link the prefix is > assigned to, or 0 if > the Common Link is a Private Link (e.g., when the > prefix is > assigned for downstream prefix delegation)." > > OK, so leaving that slightly odd phrasing (and the notion > of "Common > Link" and "Private Link" -- both of which we will come > back to) for a > later comment, can we not bring this up to section 3, thu= s: > > > "HNCP routers MUST assign a 32-bit endpoint > identifier, unique to > the local node, to each interface for which HNCP > is enabled. The > value zero MUST NOT be used, except as endpoint > identifier for an > interface towards a Private Common Link" > > ? > > [but, I am no great fan of "Private Link" or "Common > Link", see other comments] > > About this: > "Received datagrams with an IPv6 source or > destination address which > is not link-local scoped" > > How about: > "Received datagrams where either or both of the > IPv6 source or > destination address is not link-local scoped" > > ? > > As a general comment, this section contains an unordered > set of bullets, > where a grouping and some common discussion probably woul= d > make sense. > For example, a few concern security directly (e.g., 3 & 5= ) > but are not > really DNCP parametrizations -- whereas others are (e.g., > 6, 7, 8). > The bullet-set reads somewhat like "the kitchen sink". > (Numbers indicate count from the first bullet in the > block). > > o 5. Border Discovery > > The document reads: > "A router MUST allow setting a category of either > auto-detected, > internal or external for each interface which is > suitable for both > internal and external connections. In addition the > following > specializations of the internal category are defined > to modify the > local router behavior:" > > What defines if an interface is "suitable" for an > external, or internal, > or both, connections? What does "connections" mean in thi= s > context? What > requirements are there for an interface to be "suitable" > respectively > "unsuitable"? > > As part of the discussion of the different categories, > some are declared > as SHOULD, others as OPTIONAL. I do not see any which are > MUST. I see > that the two SHOULD should be MUST > > > Also: > > Hybrid category: This declares an interface to b= e > internal while > still running DHCPv4 and DHCPv6-PD clients on it. It is > assumed > that the link is under control of a legacy, trustworthy > non-HNCP > router, still within the same network. Detection of this > category > automatically in addition to manual configuration is out > of scope > of this document. Support for this category is OPTIONAL. > > What makes a router "legacy"? What makes it "trustworthy"= ? > > > o In section 6.1.2 I see: > > "Nested TLVs: Other TLVs included in the > Delegated Prefix TLV and > starting at the next 32-bit boundary following > the end of the > encoded prefix:" > > "Prefix: Significant bits of the prefix padded > with zeroes up to > the next byte boundary." > > Question: > Other than "because historically that's how we di= d > things, > because, at the time, that was a good idea", is > there any good > reason that you're insisting on byte/32-bit > alignments here? It's > been a good while since I've personally written > code where 32 bit alignment was a major concern -- but, when generating a > packet I > sure could see it as a minor nuisance to do the > alignment. > So, I actually see this as "a nuisance introduced > in packet > generation, for no real gain in parsing". > > (Note that this is in the MINOR category, though) > > o 6.2.3: > > "In any case, a router MUST support a mechanism > suitable to > distribute addresses from the considered prefix > if the link is > intended to be used by clients. In this case a > router assigning an > IPv4 prefix MUST support the L-capability and a > router assigning an > IPv6 prefix MUST support serving router > advertisements. In > addition if an assigned IPv6 prefix is not > suitable for Stateless > Address Autoconfiguration the router MUST also > support the > H-capability as defined in Section 10. > > To your credit, you put a forward pointer to Section 10. > With that being said, would it not be more logical to discuss that (which > appears as "the overall message format of HNCP") somewhere earlier? > > > > Nits: > > o Any reason why some TLV types are written in ALL-CAPS > whereas others in > Hyphenated-Camel-Case? > > o I saw a few "e.g." and "i.e.", which I believe the style > guide > prescribes should be "i.e.," and "e.g.,". Yeah, the RFC > Editor will > catch this ultimately, but if you re-spin the document > then might as > well make their life just a bit easier ;) > > --001a11c1d8d6067612051b639b63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+VGhvbWFzLDxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgdGhlIHJldmlldyE8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgbG9vayBmb3J3 YXJkIHRvIHRoZSByZXN1bHRzIG9mIHRoZSBkaXNjdXNzaW9uIHdpdGggdGhlIGF1dGhvcnMuPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BbGlhPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxf ZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBKdWwgMjEsIDIwMTUg YXQgODo0OCBBTSwgVGhvbWFzIENsYXVzZW4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt YWlsdG86aWV0ZkB0aG9tYXNjbGF1c2VuLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAdGhvbWFz Y2xhdXNlbi5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPltBcG9sb2dpZXMgZm9yIHRoZSBhZnRlci1XR0xDIHJl dmlld108YnI+DQo8YnI+DQpIZWxsbyw8YnI+DQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUg Um91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRl ZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2 aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhl IHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3Ig bW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNl ZSA8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kv UnRnRGlyIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPjxicj4NCkFsdGhvdWdoIHRo ZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURz LCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdp dGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFu ZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGlu ZyB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaG9tZW5ldC1obmNw LTA3LnR4dDxicj4NClJldmlld2VyOiBUaG9tYXMgSGVpZGUgQ2xhdXNlbjxicj4NClJldmlldyBE YXRlOiBKdWx5IDIxLCAyMDE1PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTogJmx0O3JldmlldyBqdXN0 IGFmdGVyIFdHTEMmZ3Q7PGJyPg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2s8YnI+ DQo8YnI+DQpTdW1tYXJ5Ojxicj4NCsKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoEkgaGF2ZSBzaWdu aWZpY2FudCBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IGFuZCByZWNvbW1lbmQ8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0IHRoZSBSb3V0aW5nIEFEcyBkaXNjdXNzIHRoZXNl IGlzc3VlcyBmdXJ0aGVyIHdpdGggdGhlIGF1dGhvcnMuPGJyPg0KPGJyPg0KQ29tbWVudHM6PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgVGhpcyBkb2N1bWVudCBpcyBhIHByb2Zp bGUgZm9yIGFuZCBzcGVjaWFsaXphdGlvbiBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGRyYWZ0LWlldGYtaG9tZW5ldC1kbmNwLCBhbmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBoYXMgYSBub3JtYXRpdmUgZGVwZW5kZW5jeSBvbiB0aGF0IGRvY3VtZW50LiBOb3RlIHRoYXQg SSBwcm9kdWNlZCBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUlRHLURJUiByZXZpZXcg b2YgZHJhZnQtaWV0Zi1ob21lbmV0LWRuY3Agd2l0aCBzZXZlcmFsIHN1Z2dlc3Rpb25zIGE8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaG9ydCB3aGlsZSBhZ28sIHRvIHdoaWNoIHRoZSBh dXRob3JzIHJlY2VudGx5IHJlc3BvbmRlZCB3aXRoIGFuIHVwZGF0ZWQ8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBkb2N1bWVudC4gSSBoYXZlIG5vdCBoYWQgYSBjaGFuY2UgdG8gcmV2aWV3 IHRoYXQgdXBkYXRlLCBhbmQgaXRlcmF0ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHdp dGggdGhlIGF1dGhvcnMsIHlldC4gSSBhbHNvIG5vdGUgYSBSVEctRElSIHJldmlldyBieSBMZXMg R2luc2JlcmcsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXMgd2VsbCBhcyBzZXZlcmFs IHBvaW50cyByYWlzZWQgYnkgSnVsaXVzeiBDaHJvYm9jemVrIG9uIHRoZSB0b3BpYyBvZjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRyYWZ0LWlldGYtaG9tZW5ldC1kbmNwLCB0aGUgcmVz b2x1dGlvbiBvZiB3aGljaCBJIGJlbGlldmUgbWF5IGltcGFjdDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGRyYWZ0LWlldGYtaG9tZW5ldC1obmNwIHNvbWV3aGF0IHNpZ25pZmljYW50bHku PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhpcyBpcyBvbmUgcmVhc29uIGZv ciBteSBzdW1tYXJ5IChhYm92ZSkgb2YgJnF1b3Q7U2lnbmlmaWNhbnQgY29uY2VybnMuLi4mcXVv dDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLSBiZWZvcmUgdGhpcyBkb2N1bWVudCBj YW4gYmUgcHJvY2Vzc2VkLCBkcmFmdC1pZXRmLWhvbWVuZXQtZG5jcCBzaG91bGQ8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBiZSBzcXVhcmVkIG9mZi4gSXQgaXMgbm90LCBob3dldmVyLCB0 aGUgb25seSByZWFzb248YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqBBcyBhIGdl bmVyYWwgY29tbWVudCwgdGhlIGRvY3VtZW50IHdvdWxkIGRvIHdlbGwgd2l0aCBhIGdvb2QgZWRp dG9yaWFsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3ZlcmhhdWwgdG8gYnJpbmcgY29u c2lzdGVuY3kgaW4gbGFuZ3VhZ2UgdXNhZ2UsIGNvbnNpc3RlbmN5IGluIDIxMTk8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB0ZXJtaW5vbG9neSwgY29oZXJlbmNlIGluIGRlZmluZWQgdGVy bXMgYW5kIHRoZWlyIGRlZmluaXRpb24sIGRvY3VtZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgc3RydWN0dXJlLCBldGMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKg UmVsYXRlZCB0byB0aGlzLCBJIGZvdW5kIHRoYXQgdGhlIGxhY2sgb2YgYSB0ZXJtaW5vbG9neSBz ZWN0aW9uIHdhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVuZm9ydHVuYXRlLCBhbmQg ZW5kZWQgdXAgLS0gZm9yIGhlbHBpbmcgbXkgb3duIHJlYWRpbmcgb2YgdGhlIGRvY3VtZW50PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLS3CoCBtYWtpbmcgYSBuYXBraW4tdGVybWlub2xv Z3kgdG8gcmVmZXIgdG8gYXMgSSB3YWxrZWQgdGhyb3VnaCB0aGUgZG9jLjxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIChGV0lXLCBJIHBlcnNvbmFsbHkgcHJlZmVyIHRoZSAyMTE5LXBhcmFn cmFwaCB0byBiZSBwYXJ0IG9mIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0ZXJtaW5v bG9neSBzZWN0aW9uLCBhbHRob3VnaCB0aGF0IGlzIGEgbWlub3IgaXNzdWUgLyBwZXJzb25hbDxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByZWZlcmVuY2UpLiBUaGUgd29yZHMgSSYjMzk7 ZCBzdWdnZXN0IGluY2x1ZGluZywgYW5kIGRlZmluaW5nLCB3b3VsZCBiZTo8YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqBOb2RlIC0tIGlz IHRoYXQgYSByb3V0ZXIsIGEgaG9zdCwgb3IgYm90aD8gQWdhaW4sIEkgd2FzPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZ2l2 ZW4gdG8gdW5kZXJzdGFuZCB0aGF0IEhPTUVORVQgZGlkIG5vdCB3YW50IHRvIHJlZGVmaW5lPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaG9zdCBiZWhhdmlvciwgYW5kIHNvIEkgYmVsaWV2ZSB0aGF0IHRoZSByaWdodCB0ZXJt IHdvdWxkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYmUgcm91dGVyPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoFByaXZhdCBMaW5rIC0gQ29tbW9uIExpbmsgLS0g SWYgeW91ICppbnNpc3QqIG9uIGhhdmluZyB0aGVzZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbmNlcHRzLCB0aGVuIHRo ZXkgZGVmaW5pdGVseSBuZWVkIGEgY2xlYXItY3V0IGRlZmluaXRpb248YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBoZXJlIDsg SSB3b3VsZCBwcmVmZXIsIHRob3VnaCwgdG8gbm90IGhhdmUgdGhvc2UgY29uY2VwdHMuPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgRXh0 ZXJuYWwgSW50ZXJmYWNlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg b8KgIMKgIMKgIMKgSW50ZXJuYWwgSW50ZXJmYWNlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgQm9yZGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgQm9yZGVyIHJvdXRlcjxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFlvdSAmcXVvdDtpbXBvcnQmcXVvdDsgYSBsb3Qgb2YgdGVy bWlub2xvZ3kgZnJvbSBETkNQIGFuZCBmcm9tPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg W0ktRC5pZXRmLWhvbWVuZXQtcHJlZml4LWFzc2lnbm1lbnRdLCBhbmQgSSBmb3VuZCBteXNlbGYg Y29uc3RhbnRseTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGh1bnRpbmcgdGhyb3VnaCB0 byBmaWd1cmUgb3V0IHdoaWNoIHRlcm1pbm9sb2d5IHdhcyBmcm9tIHdoZXJlLiBTdWdnZXN0PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYWRkaW5nIGEgcGFyYWdyYXBoIHRvIHRoZSB0ZXJt aW5vbG9neSBzZWN0aW9uIChhc3N1bWluZyB5b3UgbWFrZSBvbmUpPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgd2hpY2ggcmVjYXBpdHVsYXRlcyBzb21ldGhpbmcgbGlrZTo8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtBZGRpdGlvbmFsbHks IHRoaXMgZG9jdW1lbnQgdXNlcyB0ZXJtaW5vbG9neSBmcm9tIEROQ1AsPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzcGVjaWZpY2lhbGx5IHRoZSB0ZXJtcyBYWFgs IFlZWSwgWlpaIGFyZSB0byBiZSBpbnRlcnByZXRlZCBhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVzY3JpYmVkIHRoZXJlaW4uPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBUaGlzIGRvY3VtZW50IGFsc28gdXNlcyB0 ZXJtaW5vbG9neSBmcm9tPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBbSS1ELmlldGYtaG9tZW5ldC1wcmVmaXgtYXNzaWdubWVudF0sIHNwZWNpZmljYWxseSB0aGUg dGVybXMgV1dXLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVVVV LCBRUVEgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCB0aGVyZWluJnF1b3Q7Ljxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJlYXNvbiBiZWluZzogd2hlbiBJIGNh bWUgYWNyb3NzIGEgdGVybSAoc2F5ICZxdW90O1NoYXJlZCBMaW5rJnF1b3Q7KSwgSSB3YW50ZWQ8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBtYWtlIHN1cmUgdGhhdCBJIHVuZGVyc3Rv b2Qgd2hhdCB0aGF0IHdhcy4gU28gSSB3ZW50IHRvIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHRlcm1pbm9sb2d5IHNlY3Rpb24uIFdlbGwsIHRoZXJlIHdhcyBub25lLiBTbyBJIHdl bnQgdG8gZ3JlcCB0aHJvdWdoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhpcyBkb2N1 bWVudC4gRGlkbiYjMzk7dCByZWFsbHkgZmluZCBhIGRlZmluaXRpb24uIFNvIEkgc3RhcnRlZCBs b29raW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhyb3VnaCB0aGUgcmVmZXJlbmNl cyB0byBzZWUgaWYgdGhlcmUgbWlnaHQgYmUgc29tZXRoaW5nIHRoYXQgbWFkZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHNlbnNlLiBGb3J0dW5hdGVseSwgbXkgZ3Vlc3Mgb2Ygd2hhdCBJ LUQgdG8gY2hlY2sgZmlyc3Qgd2FzIHJpZ2h0LCBidXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBpdCBzdGlsbCB3YXMgbW9yZSB3b3JrIHRoYW4gaXQgc2hvdWxkIGhhdmUgYmVlbi48YnI+ DQo8YnI+DQo8YnI+DQpNYWpvciBJc3N1ZXM6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKg IMKgIMKgSSBtYWRlIHRoaXMgdmVyeSBzYW1lIGNvbW1lbnQgdG8gZHJhZnQtaWV0Zi1ob21lbmV0 LWRuY3AsIGFzIEkgYW0gZ29pbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBtYWtl IGhlcmUuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlIGludHJvZHVjdGlv biBkb2VzIG5vdCByZWFkIHdlbGw7IGl0IGNvbnRhaW5zIHBhcnRzIG9mIHNvbWV0aGluZyB0aGF0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY291bGQgYmUgY29uc2lkZXJlZCBhcyBwYXJ0 IG9mIGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50ICh3aXRob3V0IGl0PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgYmVpbmcgY2FsbGVkIG91dCBhcyBzdWNoLCBhbmQgd2l0aG91dCBmb3Jt aW5nIGEgY29tcGxldGUgYXBwbGljYWJpbGl0eTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHN0YXRlbWVudCksIGFuZCBkb2VzIG5vdCBhY3R1YWxseSBpbnRyb2R1Y2UgdGhlIHByb3RvY29s LiBSZWFkaW5nIGp1c3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgaW50cm9kdWN0 aW9uIGFuZCB0aGUgYWJzdHJhY3QsIGl0IGlzIHZlcnkgb2JzY3VyZSB3aGF0IEhOQ1AgaXM8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhY3R1YWxseSBhY2NvbXBsaXNoaW5nLCBhbmQgd2h5 IG9uZSB3b3VsZCBjaG9zZSB0byB1c2UgSE5DUC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBJdCBkb2VzLCBob3dldmVyLCB0cmFuc3BpcmUgdGhhdCAmcXVvdDt3aGF0ZXZlciBp dCBpcyZxdW90OywgaXQgaW1wb3NlcyBhIHNyYy1kc3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCByb3V0aW5nIHByb3RvY29sIC0tIGFsdGhvdWdoLCB0aGF0IGlzIGFjdHVhbGx5IGF0IG9k ZHMgd2l0aCB0aGUgY2xhaW08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoZnJvbSB0aGUg QWJzdHJhY3QpIHRoYXQgdGhlIHVzZSBvZiBITkNQIGFsbG93cyAmcXVvdDsuLi5zZWFtbGVzcyB1 c2Ugb2YgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJvdXRpbmcgcHJvdG9jb2wuJnF1 b3Q7wqAgLi4uIGdpdmVuIHRoYXQsIGFmYWlrLCBubyBzdGFuZGFyZGl6ZWQgc3JjLWRzdDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJvdXRpbmcgcHJvdG9jb2xzIGN1cnJlbnRseSBleGlz dC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBcyBJIHJlY29tbWVuZGVkIGZv ciBETkNQIChoZXksIGF0IGxlYXN0IEkmIzM5O20gYmVpbmcgc29tZXdoYXQ8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBjb25zaXN0ZW50Li4uKSBJIHN1Z2dlc3QgdGhhdCBhIHByb3BlciBp bnRyb2R1Y3Rpb24gY29uc2lzdGluZyBvZiB0aHJlZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHBhcnRzIHdvdWxkIGJlIGJlbmVmaWNpYWw6IChpKSB3aGF0IHRoaXMgZG9jdW1lbnQgaXMs IChpaSkgd2hhdCBkb2luZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhOQ1AgYWN0dWFs bHkgZ2V0cyB5b3UsIGFuZCAoaWlpKSB0aGUgb3BlcmF0aW5nIGNvbmRpdGlvbnMgdW5kZXIgd2hp Y2g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBITkNQIGlzIGFwcGxpY2FibGUuPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSBhbSBjYWxsaW5nIHRoaXMgb3V0IGFzIGEg bWFqb3IgaXNzdWUsIHNpbmNlIEkgYmVsaWV2ZSB0aGF0IGl0IGlzPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgbm90IGp1c3QgZWRpdG9yaWFsLCBidXQgaXMgYSBtYXR0ZXIgb2Ygc2NvcGlu ZyB0aGlzIGRvY3VtZW50IGNvcnJlY3RseSw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBh bmQgaW4gcGFydGljdWxhciBub3QgZmFsbGluZyBpbnRvIHRoZSB0cmFwIG9mICZxdW90O2NsYWlt aW5nIGFwcGxpY2FiaWxpdHk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aGVyZSBpdCYj Mzk7cyBub3QmcXVvdDsuPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKg NC4gQ29tbW9uIExpbmtzPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRnJvbSB0 aGUgZG9jdW1lbnQ6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmcXVv dDtITkNQIHVzZXMgdGhlIGNvbmNlcHQgb2YgQ29tbW9uIExpbmtzIGZvciBzb21lIG9mIGl0cyBh cHBsaWNhdGlvbnMuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQSBDb21tb24g TGluayB1c3VhbGx5IHJlZmVycyB0byBhIGxpbmsgbGF5ZXIgYnJvYWRjYXN0IGRvbWFpbiB3aXRo PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2VydGFpbiBwcm9wZXJ0aWVzIGFu ZCBpcyB1c2VkLCBlLmcuLCB0byBkZXRlcm1pbmUgd2hlcmUgcHJlZml4ZXM8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaG91bGQgYmUgYXNzaWduZWQgb3Igd2hpY2ggbmVpZ2hi b3Jpbmcgbm9kZXMgcGFydGljaXBhdGUgaW4gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgZWxlY3Rpb24gb2YgYSBESENQKHY2KSBzZXJ2ZXIuwqAgVGhlIENvbW1vbiBMaW5r IGlzIGNvbXB1dGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2VwYXJhdGVs eSBmb3IgZWFjaCBsb2NhbCBpbnRlcmZhY2UsIGFuZCBpdCBhbHdheXMgY29udGFpbnMgdGhlPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbG9jYWwgaW50ZXJmYWNlLsKgIEFkZGl0 aW9uYWxseSwgaWYgdGhlIGxvY2FsIGludGVyZmFjZSBpcyBub3QgaW48YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBhZC1ob2MgbW9kZSwgaXQgYWxzbyBjb250YWlucyB0aGUgc2V0 IG9mIGludGVyZmFjZXMgdGhhdCBhcmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBiaWRpcmVjdGlvbmFsbHkgcmVhY2hhYmxlIGZyb20gdGhlIGdpdmVuIGxvY2FsIGludGVyZmFj ZSwgaS5lLiBldmVyeTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlbW90ZSBp bnRlcmZhY2Ugb2YgYSByZW1vdGUgbm9kZSBtZWV0aW5nIGFsbCBvZiB0aGUgZm9sbG93aW5nPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVxdWlyZW1lbnRzOiZxdW90Ozxicj4N Cjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNldmVyYWwgaXNzdWVzIGhlcmU6 PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMCnCoCDCoCDC oCAmcXVvdDtyZWZlcnMgdG8gYSBsaW5rIGxheWVyIGJyb2FkY2FzdCBkb21haW4mcXVvdDsgLS0g c291bmRzIGxpa2UgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICZxdW90O2Z1bGwgYnJvYWRjYXN0IGxpbmsmcXVvdDsgb3IgJnF1b3Q7c29tZXRo aW5nIHRoYXQgbG9va3MgbGlrZSBhbiBFdGhlcm5ldCZxdW90Ozxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDEpwqAgwqAgwqAgJnF1b3Q7c29tZSBvZiBpdHMgYXBwbGlj YXRpb25zJnF1b3Q7IC0tIHdoYXQgYXJlIHRob3NlPzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIDIpwqAgwqAgwqAgJnF1b3Q7dXN1YWxseSByZWZlcnMgdG8gYSAuLi4m cXVvdDsgLS0gc28sIHRoYXQgbWVhbnMgdGhhdCB0aGVyZSBhcmU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzaXR1YXRpb25zIHdoZXJlIHlvdSB1 c2UgaXQgdG8gcmVmZXIgdG8gc29tZXRoaW5nIGVsc2UsIHRoZW4/PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgUGxlYXNlIGRvbiYjMzk7dCBkbyB0 aGF0Li4uLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDMpwqAgwqAg wqAgJnF1b3Q7aXMgY29tcHV0ZWQgc2VwZXJhdGVseSBmb3IgZWFjaCBsb2NhbCBpbnRlcmZhY2Um cXVvdDsgLS0gd2FpdCwgaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAwKSBpdCB3YXMgZGVmaW5lZCBpbiB0ZXJtcyBvZiBwaHlzaWNhbCBwcm9w ZXJ0aWVzLCBub3cgaXQgaXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzb21ldGhpbmcgd2hpY2ggaXMgY29tcHV0ZWQ/PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgNCnCoCDCoCDCoCAmcXVvdDt3aGljaCBuZWlnaGJv cmluZyBub2RlcyBwYXJ0aWNpcGF0ZSBpbiB0aGUgZWxlY3Rpb24gb2YgYTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIERIQ1AodjYpIHNlcnZlciZx dW90OyAtLSBpcyB0aGF0IGEgaGlkZGVuIHJlcXVpcmVtZW50IHRoYXQgc2xpZCBpbiw8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0IERIQ1Ao djYpIHNlcnZlcnMgYXJlIHBhcnQgb2YgdGhlIGFyY2hpdGVjdHVyZT8gU0xBQUMgaXM8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvdXQsIHRoZW4/ IElzIHRoYXQgYSBjb25zY2lvdXMgYXJjaGl0ZWN0dXJhbCBkZWNpc2lvbj88YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOb3csIEkgYWN0 dWFsbHkgcmVhZCBpbiBzZWN0aW9uIDUsIGJ1bGxldCBudW1iZXIgMiB0aGF0ICZxdW90O2lmPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW4gaW50 ZXJmYWNlIGNhbiByZWNlaXZlIGEgZGVsZWdhdGVkIHByZWZpeCBieSBydW5uaW5nIGE8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBESENQdjYgY2xp ZW50IG9uIHRoZSBpbnRlcmZhY2UsIGl0IG11c3QgYmUgY29uc2lkZXJlZDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV4dGVybmFsJnF1b3Q7LiBT bywgYXQgbGVhc3QsIGlmIGEgJnF1b3Q7Y29tbW9uIGxpbmsmcXVvdDsgY29ubmVjdHMgJnF1b3Q7 aW50ZXJuYWw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBpbnRlcmZhY2VzJnF1b3Q7IHRoZW4gaWYgREhDUHY2IHNlcnZlcnMgYXJlIGFjdGl2ZSBv biBhIGNvbW1vbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIGxpbmssIHRoZW4gdGhpcyBpbXBvc2VzIGNvbnN0cmFpbnRzIG9uIHdoYXQgdGhlc2Ug REhDUHY2PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc2VydmVycyBhcmUgYWxsb3dlZCB0byBzZXJ2ZSAuLi4gVGhpcyAqcmVhbGx5KiBtZXJpdHMg YmVpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBjYWxsZWQgb3V0LCB0aGUgcmVsYXRpb25zaGlwIEROQ1AtREhDUCBpcyBtdXJreSwgYXQgYmVz dC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA1KcKgIMKg IMKgICZxdW90O2lmIHRoZSBsb2NhbCBpbnRlcmZhY2UgaXMgbm90IGluIGFkLWhvYyBtb2RlJnF1 b3Q7IC0tIGhhYWFhYW5nIG9uLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IGFuIDgwMi4xMS9XaUZpIGlu dGVyZmFjZSwgJnF1b3Q7YWQgaG9jIG1vZGXigJ08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkb2VzIG5vdCByZXN1bHQgaW4gbGlua3MgdGhhdCBs b29rIGxpa2UgaW4gMCkgLi4uLm5vdCBhdCBhbGwsIGFjdHVhbGx5Ljxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDYpwqAgwqAgwqAgJnF1b3Q7aWYgdGhlIGxv Y2FsIGludGVyZmFjZSBpcyBub3QgaW4gYWQtaG9jIG1vZGUmcXVvdDsgLS0gSSBhbSBub3Qgc3Vy ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRo YXQgdGhpcyBpcyBhY3R1YWxseSAmcXVvdDt0aGUgcmlnaHQgdGVybSZxdW90OyBub3IgdGhhdCBp dCBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHVuaXZlcnNhbGx5IHVuZGVyc3Rvb2QuIEF0IGxlYXN0LCBJIGhhdmUgcGVyc29uYWxseSBoYWQg YSBoZWNrPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgb2YgYSB0aW1lIGNvbnZleWluZyB3aGF0IHRoYXQgbWVhbnQgd2hlbiBjaGFyYXRlcml6aW5n IGEgbGluayDigJQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBlc3BlY3VhbGx5IHdpdGhpbiB0aGUgSUVURiZxdW90Ozxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDcpwqAgwqAgwqAgUmVhZGluZyBmb3J3YXJk IGluIHRoZSBkb2N1bWVudCwgdGhlcmUmIzM5O3Mgc29tZXRoaW5nIG1vcmUgb24gdGhhdDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluIHNlY3Rp b24gNSBvbiBwYWdlIDYgd2hlcmUgdGhlIGRvY3VtZW50IHRhbGtzIGFib3V0IGFuICZxdW90O2Fk IGhvYzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGNhdGVnb3J5JnF1b3Q7LCBhbmQgd2hlcmUgaXQgYWN0dWFsbHkgc2F5cyBzb21ldGhpbmcgYWJv dXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAm cXVvdDt0cmFuc2l0aXZpdHkgcHJvcGVydGllcyZxdW90OyAtLSBzcGVjaWZpY2FsbHkgdGhhdCBp dCBpcyBub3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBhc3N1bWVkLCB0aGVuIGEgcmVmZXJlbmNlIHRvIHNlY3Rpb24gNCBpcyBnaXZlbiBhcy1p ZiB0aGVyZSB3YXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBhbnkgZnVydGhlciBkaXNjdXNzaW9uIG9uIHRoaXMgcG9pbnQuPGJyPg0KPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOCnCoCDCoCDCoCAmcXVv dDtzZXQgb2YgaW50ZXJmYWNlcyB0aGF0IGFyZSBiaWRpcmVjdGlvbmFsbHkgcmVhY2hhYmxlIGZy b20gdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgZ2l2ZW7CoCBsb2NhbCBpbnRlcmZhY2UmcXVvdDsgLS0gSSB0YWtlIGl0IHRoYXQgdGhpcyBt ZWFucyB0aGF0IHRoZSBiZWxvdzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHNwZWNpZmllcyBhIHBhcnQgb2YgYSBwcm90b2NvbCAoSEVMTE8gcHJv dG9jb2wpLCB3aGljaCBvbmx5IHJ1bjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIG92ZXIgJnF1b3Q7YWQgaG9jIGludGVyZmFjZSB0eXBlcyZxdW90 Oz88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJZiAmcXVvdDt5ZXMmcXVvdDsg dG8gOCksIHRoZW4gSSB3b3VsZCByZWNvbW1lbmQgdGhhdCB5b3UgZGVmaW5lIHRoZSBpbnRlcmZh Y2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0eXBlcywgYW5kIHRoZWlyIGJlaGF2aW9y cywgY29tcGxldGVseSAtLSBib3RoIHdoYXQgY2hhcmFjdGVyaXN0aWNzIHlvdTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGV4cGVjdCBmcm9tIHRoZSBpbnRlcmZhY2UgKGFuZCAmcXVvdDth ZCBob2MgbW9kZSZxdW90OyBpcyBub3Qgc3VmZmljaWVudC4uLiksIGFuZDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHdoYXQgYmVoYXZpb3JzIHlvdSBleGhpYml0IGFjcm9zcyB0aGVtLiBZ b3UgaGF2ZSwgaW4gdGhpcyB0ZXh0LCBoYWxmLXdheTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGRlZmluZWQgJnF1b3Q7YnJvYWRjYXN0IGxpbmsgdHlwZSZxdW90OyBhbmQgaGFsZi13YXkg ZGVmaW5lZCBhICZxdW90O25vbi10cmFuc2l0aXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgbm9uLXJlZmxleGl2ZSBsaW5rIHR5cGUmcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBBbHNvLCBJIHJlYWxseSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgY2hvaWNlIG9m ICZxdW90O0NvbW1vbiBMaW5rJnF1b3Q7IGFzIHNlY3Rpb248YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBoZWFkZXIsIGFuZCBhcyBhIHRlcm0uIEhvdyBpcyB0aGF0IGRlZmluaXRpb24gZGlm ZmVyZW50IGZyb20gJnF1b3Q7YW4gSVA8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaW5r JnF1b3Q7PyBBcmUgdGhlIHByb3RvY29sIG1lY2hhbmlzbXMgdGhhdCB5b3UgcHJvdmlkZSBmb3Ig d2hhdCB5b3UgY2FsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O2FkIGhvYyBt b2RlJnF1b3Q7IHByb3ZpZGluZyBzb21ldGhpbmcgd2hpY2ggbG9va3MgbGlrZSBhbiBJUCBsaW1r IHRvICZxdW90O3RoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlc3Qgb2YgdGhlIHBy b3RvY29sJnF1b3Q7LCBldGMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSBh bSBhZnJhaWQgdGhhdCBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoYXQgYSBjb21tb24gbGluayBpcy4g QXJlIHlvdTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRyeWluZyB0byBkZWZpbmUgYSBs aW5rIG1vZGVsPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoDMuIEROQ1AgUHJv ZmlsZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZSBkb2N1bWVudCByZWFkczo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtBIG5vZGUg aW1wbGVtZW50aW5nIEhOQ1A8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFNIT1VMRCBn ZW5lcmF0ZSBhbmQgdXNlIGEgcmFuZG9tIG5vZGUgaWRlbnRpZmllci7CoCBJZiB1c2luZyBhPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqByYW5kb20gbm9kZSBpZGVudGlmaWVyIGFuZCB0 aGVyZSBpcyBhIG5vZGUgaWRlbnRpZmllciBjb2xsaXNpb24sPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqB0aGUgbm9kZSBNVVNUIGltbWVkaWF0ZWx5IGdlbmVyYXRlIGFuZCB1c2UgYSBu ZXcgcmFuZG9tIG5vZGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGlkZW50 aWZpZXIgd2hpY2ggaXMgbm90IHVzZWQgYnkgYW55IG90aGVyIG5vZGUuJnF1b3Q7PGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQXdlc29tZSwgYnV0IHRoYXQgcmFpc2VzIHR3byBx dWVzdGlvbnM6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMSnCoCDC oCDCoCBIb3cgZG9lcyBhIG5vZGUgZGV0ZWN0IGlkZW50aWZpZXIgY29sbGlzaW9uPzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDIpwqAgwqAgwqAgSG93IGRvZXMgYSBu b2RlIGdlbmVyYXRlIGFuIGlkZW50aWZpZXIgd2hpY2ggaXMgbm90IHVzZWQgYnkgYW55PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3RoZXIgbm9k ZT88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJdCB3b3VsZCBzZWVtIHRoYXQg aWYgMikgaXMgYWN0dWFsbHkgcG9zc2libGUsIHRoZW4gYSBjb2xpc3Npb24gc2hvdWxkPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbmV2ZXIgZXZlciBoYXBwZW4uPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgQWxzbywgaWYgMSkgYW5kIDIpIGFyZSBkb25lICZxdW90O2J5IHRoaXMg cHJvdG9jb2wmcXVvdDssIHB1dCBpbiBhIGZvcndhcmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCByZWZlcmVuY2UgdG8gd2hlcmUgdGhlIGNvcnJlc3BvbmRpbmcgbWVjaGFuaXNtcyBleGlz dC4gT3IgaWYgZG9uZSBieTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEROQ1Agb3Igc29t ZXRoaW5nIGVsc2UsIHN0aWNrIGluIGEgcmVmZXJlbmNlLjxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIEFzIGl0IGlzLCBpdCByZWFkcyBhIGxpdHRsZSBsaWtlOjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90Oy4uLmFuZCB0aGVuIHNvbWUgbWFn aWMgaGFwcGVucywgYW5kIHRoZW4gcG9wcGllcyBhbmQgcGluayB1bmljb3JucyZxdW90Ozxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDspPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgVGhlIGRvY3VtZW50IHJlYWRzOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O2/CoCBITkNQIG5vZGVzIHVzZSB0aGUgZm9sbG93 aW5nIFRyaWNrbGUgcGFyYW1ldGVyczo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAtwqAgwqAgwqAgwqBrIFNIT1VMRCBiZSAxLCBhcyB0aGUgdGltZXIgcmVz ZXQgd2hlbiBkYXRhIGlzIHVwZGF0ZWQgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgZnVydGhlciByZXRyYW5zbWlzc2lvbnMgc2hvdWxkIGhhbmRsZSBwYWNrZXQg bG9zcy4mcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIGFtIHdvbmRl cmluZyB3aGF0IHRoZSBqdXN0aWZpY2F0aW9uIGZvciAmcXVvdDtrPTEmcXVvdDsgaXMgaGVyZT8g QWN0dWFsbHksIEkgY2FuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5mZXIgd2hhdCBp dCBpczogdGhlIHRvcG9sb2d5IGluIGEgaG9tZW5ldCBpcyBjb25zdGl0dXRlZCBieTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZ1bGwtYnJvYWRjYXN0IEV0aGVybmV0IGxpbmtzLCB3aXRo IHRoZSBhc3N1bXB0aW9uIHRoYXQgJnF1b3Q7aWYgb25lIHN0YXRpb248YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCByZWNlaXZlcyBhIHRyYW5zbWlzc2lvbiwgYWxsIHN0YXRpb25zIG9uIHRo ZSBsaW5rIHJlY2VpdmVkIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRyYW5zbWlz c2lvbiZxdW90OyAtLSBpZiBzbywgdGhlbiB0aGlzIGlzIGFjdHVhbGx5IHBhcnQgb2YgdGhlIGFw cGxpY2FiaWxpdHk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdGF0ZW1lbnQgZm9yIEhO Q1A6ICZxdW90O01VU1Qgb25seSBiZSB1c2VkIG9uIEV0aGVybmV0LWxpa2UgbGlua3MgYW5kIE1V U1Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOT1QgYmUgdXNlZCBvbiBub24tdHJhbnNp dGl2ZSwgbm9uLXJlZmxleGl2ZSwgb3Igb24gbG9zc3ksIGxpbmtzJnF1b3Q7Ljxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElmIHRoaXMgaW50ZXJwcmV0YXRpb24gaXMgY29ycmVj dCwgdGhlbiB5b3UgcHJvYmFibHkgc2hvdWxkIGV4cGxhaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB5b3Vyc2VsZiAtLcKgIGZvciBvbmNlLCBJIGFtIG1vc3RseSBpbiBhZ3JlZW1lbnQg d2l0aCB0aGUgdXNlIG9mIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTSE9VTEQuPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT25lIHF1ZXN0aW9uLCBob3dldmVyOiBm b3IgYSByb3V0ZXIgd2l0aCBtdWx0aXBsZSBpbnRlcmZhY2UsIGRvIHlvdSBydW48YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgVHJpY2tsZSBhbGdvcml0aG0gcGVyIGludGVyZmFjZT8g V291bGQgcHJvYmFibHkgbWVyaXQgY2xhcmlmaWNhdGlvbi48YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBJZiBpdCBpcyBhbHJlYWR5IHNhaWQgaW4gRE5DUCAoSSBkbyBub3QgcmVjYWxsIGlm IGl0IGlzLCBhbmQgY291bGRuJiMzOTt0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW1t ZWRpYXRlbHkgZmluZCBpdCksIHBlcmhhcHMgYSByZW1pbmRlciBhbmQgYSBwb2ludGVyIHdvdWxk IGJlIGdvb2Q/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgU2VjdGlvbiA0ICZh bXA7IDU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGUgZG9jdW1lbnQgc2VlbXMgdG8g ZGVmaW5lIGEgc2V0IG9mIGludGVyZmFjZSB0eXBlcyBhbmQgbGluayB0eXBlcyw8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBidXQgd2l0aG91dCBhbnkgY2xlYXIgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlbSAtLSBhbmQsIHdvcnNlLCB3aXRob3V0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgYW55IGRpc2N1c3Npb24gb2Ygd2hhdCBjaGFyYWN0ZXJpemUgZWFjaCwgd2hhdCBiZWhh dmlvcnMgYXJlIGV4aGliaXRlZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG92ZXIgZWFj aCwgYW5kIHdoYXQgaW1wYWN0cyBvbiB0aGUgc3lzdGVtL25ldHdvcmsgYmVoYXZpb3IgYW5kPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcGVyZm9ybWFuY2UgZWFjaCBoYXMuIEZ1cnRoZXIs IHRoZSBkZWZpbml0aW9ucyBvZiB0aGUgZGlmZmVyZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgaW50ZXJmYWNlL2xpbmsgdHlwZXMgYXJlIGluY29tcGxldGUsIGFuZCBzZWVtIHRpZWQg dG8gKHdpdGhvdXQgbmFtaW5nPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZXhwbGljaXRs eSkgc3BlY2lmaWMgTDImIzM5O3MuLi5oaW50ZWQgYXQsIGJ1dCBub3QgYWN0dWFsbHkgcmVmZXJl bmNlZC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqBTZWN0aW9uIDU8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGUgZG9jdW1lbnQgcmVhZHM6PGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAmcXVvdDtITkNQIHJvdXRlciYjMzk7cyBpbnRlcmZh Y2VzIGFyZSBlaXRoZXIgaW50ZXJuYWwsIGV4dGVybmFsIG9yIG9mIGE8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBkaWZmZXJlbnQgY2F0ZWdvcnkgZGVyaXZlZCBmcm9tIHRoZSBp bnRlcm5hbCBvbmUuJnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU28s IHRoaXMgdGV4dCB0ZWxscyBtZSB0aGF0IHRoZXJlIGFyZSBuIGRpZmZlcmVudCBjYXRlZ29yaWVz IG9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW50ZXJmYWNlLCB3aGVyZSBuJmd0Oz0y IC0tIGJ1dCBkb2VzIG5vdCB0ZWxsIG1lIHdoYXQgZGVmaW5lcyB0aG9zZTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGRpZmZlcmVudCBpbnRlcmZhY2UgY2F0ZWdvcmllcywgb3Igd2hhdCB0 aGUgYWN0dWFsIHZhbHVlIGZvciBuIGlzLiBOb3I8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBkb2VzIHRoaXMgdGVsbCBtZSBpZiBJIHNob3VsZCBleHBlY3QgZGlmZmVyZW50IGJlaGF2aW9y cyBhY3Jvc3MgdGhlc2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbnRlcmZhY2VzLCBv ciBub3QuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ291bGQgdGhlIGRvY3Vt ZW50IGJlIG1vcmUgc3BlY2lmaWM/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg VGhlIHRleHQgZ29lcyBvbjo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAmcXVvdDtJdCBpcyBzdWl0YWJsZSBmb3IgYm90aCBJUHY0IGFuZCBJUHY2IChzaW5nbGUgb3Ig ZHVhbC1zdGFjaykgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqBkZXRlcm1pbmVzIHdoZXRoZXIgYW4gSE5DUCBpbnRlcmZhY2UgaXMgaW50ZXJuYWwsIGV4dGVy bmFsLCBvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdXNlcyBh bm90aGVyIGZpeGVkIGNhdGVnb3J5LiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFNvIHdoYXQmIzM5O3MgJnF1b3Q7YW5vdGhlciBmaXhlZCBjYXRlZ29yeSZxdW90Oz8g SXMgdGhhdCBkaWZmZXJlbnQgZnJvbSAmcXVvdDthIGRpZmZlcmVudDxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGNhdGVnb3J5wqAgZGVyaXZlZCBmcm9tIHRoZSBpbnRlcm5hbCBvbmUmcXVv dDsgZGlzY3Vzc2VkIGVhcmxpZXI/IEFnYWluLCB3aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgYmVoYXZpb3JzIHRvIGV4cGVjdCwgZXhoaWJpdCwgYWNyb3NzIHRoZXNlPzxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdpdGggdGhhdCBiZWluZyBzYWlkLCBJIHdvdWxk IHJlYWxseSByZWNvbW1lbmQgdGhhdCB0aGUgZG9jdW1lbnQgZGVmaW5lczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHdoYXQgYSBib3JkZXIgaXMsIGluIHRoaXMgY29udGV4dC4gSG93IGRv IEkgaWRlbnRpZnkgaXQsIHdoYXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjaGFyYWN0 ZXJpemVzIGEgYm9hcmRlciAod2hpY2ggcGVyaGFwcyBmYWxscyBvZmYgZnJvbSAmcXVvdDt3aGF0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgY2hhcmFjdGVyaXplcyBhbiBpbnRlcm5hbCBh bmQgZXh0ZXJuYWwgaW50ZXJmYWNlKS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBJIGFzc3VtZSB0aGF0ICZxdW90O2ludGVybmFsIGludGVyZmFjZSZxdW90OyBtZWFucyAmcXVv dDtpbnRlcm5hbCB0byB0aGUgSW50ZXJuZXQmcXVvdDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB3aGVyZWFzICZxdW90O2V4dGVybmFsJnF1b3Q7IG1lYW5zICZxdW90O2V4dGVybmFsIHRv IHRoZSBpbnRlcm5ldCwgaS5lLiwgcGFydCBvZiB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBob21lbmV0JnF1b3Q7IC0tIHJpZ2h0PyBPZiBjb3Vyc2UsIEkgYW0geWFua2luZyB5b3Vy IGNoYWluIGhlcmUsIGJ1dCB5b3UgbXVzdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRl ZmluZSBwcmVjaXNlbHkgd2hhdCB0aGVzZSBtZWFuLiBFeHRlcm5hbCBhbmQgSW50ZXJuYWwgYXJl IHJlbGF0aXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGVybXMuLi48YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiB0aGF0LCByZWFkaW5nIHRocm91Z2ggdGhlIGFs Z29yaXRobSB0aGF0IHlvdSBnaXZlLCBlc2VlbnRpYWxseSB5b3U8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBkZWZpbmUgYXMgJnF1b3Q7ZXh0ZXJuYWwmcXVvdDsgYW55dGhpbmcgb24gd2hp Y2ggYSBESENQdjQgb3IgREhDUHY2LVBEIHNlcnZlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGFuc3dlcnMsIGNvcnJlY3Q/IE90aGVyIHRoYW4gaGF2aW5nIGEgaGFyZCB0aW1lIHJlY29u Y2lsaW5nIHRoYXQgd2l0aDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzc3VlIDQgdW5k ZXIgJnF1b3Q7Y29tbW9uIGxpbmtzJnF1b3Q7IGluIE1ham9yIElzc3VlcywgdGhhdCBkb2VzIHNl ZW0gdG8gYXNzdW1lPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYW4gYXJjaGl0ZWN0dXJh bCBjaG9pY2Ugd2hpY2ggaW1wb3NlcyBjb25zdHJhaW50cyAoJnF1b3Q7dGhvdSBzaGFsdCBub3Qg cnVuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSBESENQIHNlcnZlciBpbnNpZGUgYSBo b21lbmV0IHdoaWxzdCBydW5uaW5nIEhOQ1AmcXVvdDspIHdoaWNoLCBhdCBsZWFzdCw8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBuZWVkcyB0byBiZSBjYWxsZWQgb3V0IGluIHRoZSBhcHBs aWNhYmlsaXR5IHN0YXRlbWVudCBmb3IgSE5DUCwgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgcHJvYmFibHkgZXZlbiBtZXJpdHMgbW9yZSBnbG9iYWwgZGlzY3Vzc2lvbiBhbmQgZGVj aXNpb24gYnkgdGhlIFdHPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEJ1dCB3 YWl0LCB0aGVuIGJlbG93IHRoZSBhbGdvcml0aG0gSSByZWFkIHRoaXM6PGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7SW4gb3JkZXIgdG8gYXZvaWQg Y29uZmxpY3RzIGJldHdlZW4gYm9yZGVyIGRpc2NvdmVyeSBhbmQgSE5DUDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJvdXRlcnMgcnVubmluZyBESENQdjQuLi4uJnF1 b3Q7PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLi4uYW5kIHRoZW4sIHJlcXVp cmVtZW50cyB0aGF0IHN1Y2ggcm91dGVycyBtdXN0IGluY2x1ZGUgYSBVc2VyLUNsYXNzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3RyaW5nLiBUaGF0IGFjdHVhbGx5IG1lYW5zIHRoYXQg dGhlIHNwZWNpZmllZCBhbGdvcml0aG0gaXMgaW5jb3JyZWN0PGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgLS0gdW5kZXJzcGVjaWZpZWQ6IHRoZSBhbGdvcml0aG0gbXVzdCBjYXB0dXJlIHRo ZSAmcXVvdDsuLi51bmxlc3MgYW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBVc2VyLUNs YXNzIHN0cmluZyBvZiAuLi4uIGlzIGluY2x1ZGVkJnF1b3Q7LCB3aGVyZSBhcHByb3ByaWF0ZS48 YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdXJlLCB3aXRoIGVmZm9ydHMgb2Yg dGhlICZxdW90Oy4uLkkgdGhvdWdodCB0aGlzIG92ZXIsIGFuZCBJIGFtIHN1cmUgdGhhdDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBhdXRob3JzIG11c3QgaGF2ZSBtZWFudCBYWFhY JnF1b3Q7LCBpdCYjMzk7cyBwcm9iYWJseSBwb3NzaWJsZSB0byBpbXBsZW1lbnQ8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBidXQgSSYjMzk7ZCBtdWNoIHByZWZlciB0byBoYXZlIHRoZSBk b2N1bWVudCB0ZWxsIG1lIHdoYXQgdG8gaW1wbGVtZW50LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHJhdGhlciB0aGFuIGhhdmUgaXQgdGVsbCBtZSB0byBndWVzcy48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGUgbGFzdCBwYXJhZ3JhcGggaW4gc2VjdGlvbiA1IGlz IGh1Z2VseSBpbXBvcnRhbnQ6IHRoYXQgaXMgd2hlcmUgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgbm9ybWF0aXZlIGJlaGF2aW9yIGZvciBlYWNoIGludGVyZmFjZSBjYXRlZ29yeSBp cyBkZXRhaWxlZCAtIGJ1dCwgSTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoaW5rLCBv bmx5IHBhcnQgb2YgdGhlIG5vcm1hdGl2ZSBiZWhhdmlvciBpcyBhY3R1YWxseSBzcGVjaWZpZWQ8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGVyZWluLiBUaGlzIGlzIHJlbGF0aXZlIHRv IHdoYXQgSSBtZW50aW9uZWQgZWFybGllciwgdGhhdCBmb3IgYW48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBpbnRlcmZhY2UvbGluayB0eXBlL2NhdGVnb3J5LCBpdCB3b3VsZCBiZSBoZWxw ZnVsIHRvIGhhdmUgc3BlY2lmaWVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcHJlY2lz ZWx5IChpKSBob3cgdG8gZGV0ZXJtaW5lIGlmIGEgZ2l2ZW4gaW50ZXJmYWNlL2xpbmsgZmFsbHMg d2l0aGluPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXQswqAgKGlpKSB3aGF0IHByZWNp c2UgYmVoYXZpb3JzIHRvIGV4cGVjdCBvdmVyIHRoYW4gaW50ZXJmYWNlL2xpbmsuPGJyPg0KPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgU2VjdGlvbiA2PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgUmVsYXRlZCB0byBteSBsYXN0IGNvbW1lbnQgYWJvdmUgdG8gc2VjdGlv biA1LCBzZWN0aW9uIDYgYnJpbmdzIG91dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZx dW90O2JvcmRlciByb3V0ZXJzJnF1b3Q7IC0tIHdoaWNoIGlzIG5vdCBhY3R1YWxseSBkZWZpbmVk IGluIHRoZSBkb2N1bWVudC48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTb21lIHNwZWNp ZmljIGJlaGF2aW9yIGlzIHNwZWNpZmllZCBmb3IgYSAmcXVvdDtib3JkZXIgcm91dGVyJnF1b3Q7 IGFuZCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYnJpbmdzIG1lIHRvIGV4cGVj dGluZyB0byBzZWU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgb8KgIMKgIMKgIMKgQSBwcmVjaXNlIGRlZmluaXRpb24gb2Ygd2hlbiBhIHJvdXRlciBpcywg b3IgaXMgbm90LCBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYm9yZGVyIHJvdXRlciAoZ2l2ZW4gYSByb3V0ZXIsIGhvdyBkbyBJIGRldGVybWlu ZSBpZiBJPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc2hvdWxkIGNvbmZpZ3VyZSBpdCB0byBleGhpYml0IHRoYXQgJnF1b3Q7c3BlY2lmaWMgYmVo YXZpb3ImcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBvwqAgwqAgwqAgwqBBIHByZWNpc2UgYW5kIGNvbXBsZXRlIGRlZmluaXRpb24gb2Ygd2hpY2gg YmVoYXZpb3JzIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmcXVvdDtib3JkZXIgcm91dGVyJnF1b3Q7LCBvbmNlIGlkZW50aWZpZWQsIHNob3Vs ZCBleHBlY3QgYW5kIGV4aGliaXQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg VGhlIGN1cnJlbnQgdGV4dCBkb2VzIG5vdCBkbyB0aGF0LiBBZ2FpbiwgSSBjb3VsZCBwZXJoYXBz IHRyeSB0byBndWVzcyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBidXQgZm9yIGEgZG9j dW1lbnQgYWltaW5nIGZvciBzdGQudHJhY2ssIEkgcmVhbGx5IHNob3VsZCBub3QgaGF2ZSB0by48 YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqBTZWN0aW9uIDYuMTxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O0VhY2ggSE5DUCByb3V0 ZXIgTUFZIG9idGFpbiBleHRlcm5hbCBjb25uZWN0aW9uIGluZm9ybWF0aW9uIGZyb208YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG9uZSBvciBtb3JlIHNvdXJjZXMs IGUuZy4sIERIQ1B2Ni1QRCBbUkZDMzYzM10sIE5FVENPTkYgW1JGQzYyNDFdPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBvciBzdGF0aWMgY29uZmlndXJhdGlvbi7C oCBUaGlzIHNlY3Rpb24gc3BlY2lmaWVzIGhvdyBzdWNoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqBpbmZvcm1hdGlvbiBpcyBlbmNvZGVkIGFuZCBhZHZlcnRpc2Vk LiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdoYXQgaXMgJnF1b3Q7 Y29ubmVjdGlvbiBpbmZvcm1hdGlvbiZxdW90Oz8gRG8geW91IG1lYW4gJnF1b3Q7cHJlZml4ZXMs IGFkZHJlc3Nlcyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByb3V0aW5nIGluZm9ybWF0 aW9uLCBETlMgcmVzb2x2ZXJzJnF1b3Q7IGFuZCBzdWNoP8KgIE9yIGRvZXMgaXQgbWVhbiAmcXVv dDtiaXRyYXRlLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVycm9yIHJhdGUsIHByb3Bh Z2F0aW9uIGRlbGF5JnF1b3Q7PyBPciBzb21ldGhpbmcgZWxzZT8gQWdhaW4sIEkgY291bGQ8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm9iYWJseSBndWVzcywgYW5kIG1pZ2h0IGV2ZW4g Z2V0IGl0IHJpZ2h0LCBidXQgaW4gYSBzdGQudHJhY2sgZG9jdW1lbnQ8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBJIHJlYWxseSBzaG91bGRuJiMzOTt0IGhhdmUgdG8uPGJyPg0KPGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7b8KgIE1BWSBj b250YWluIGF0IG1vc3Qgb25lIERIQ1B2NiBEYXRhIFRMViBhbmQgYXQgbW9zdCBvbmUgREhDUHY0 PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRGF0YSBUTFYgZW5jb2Rp bmcgb3B0aW9ucyBhc3NvY2lhdGVkIHdpdGggdGhlIEV4dGVybmFsPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ29ubmVjdGlvbiBidXQgTVVTVCBOT1QgY29udGFpbiBt b3JlIHRoYW4gb25lIG9mIGVhY2ggb3RoZXJ3aXNlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgdGhlIEV4dGVybmFsIENvbm5lY3Rpb24gVExWIE1VU1QgYmUgaWdub3Jl ZC48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG/CoCBNQVkgY29u dGFpbiBvdGhlciBUTFZzIGZvciBmdXR1cmUgdXNlLsKgIFN1Y2ggYWRkaXRpb25hbCBUTFZzPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTVVTVCBiZSBpZ25vcmVkLiZx dW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNldmVyYWwgY29tbWVudHMg dG8gdGhhdCBzcGVjaWZpY2FsbHksIGFuZCB0byB0aGUgVExWIGRlc2NyaXB0aW9uIGluPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZ2VuZXJhbCAocGxlYXNlIGFwcGx5IGFsc28gdG8gdGhl IG90aGVyIHNpZ25hbHMvVExWcyBhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFwcHJv cHJpYXRlLCB0aGUgY29tbWVudHMgdG8gdGhpcyBUTFYgZGVzY3JpcHRpb24gLyBidWxsZXQgYXBw bHkgdGhyb3VnaDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNlY3Rpb24gNik6PGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMCnCoCDCoCDCoCBZb3Ug ZGVmaW5lIGEgVExWICZxdW90O0VYVEVSTkFMLUNPTk5FQ1RJT04mcXVvdDssIHdpdGhpbiB3aGlj aCB5b3UgaGF2ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIG90aGVyIFRMVnMsIGNvcnJlY3Q/IFdvdWxkIGl0IG5vdCBiZSBjbGVhcmVyIGlmIHRo b3NlICZxdW90O290aGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgVExWcyZxdW90OyBiZSBjYWxsZWQgJnF1b3Q7c3ViLVRMVnMmcXVvdDsgYW5k IHRoYXQgdGVybSB1c2VkIHN5c3RlbWF0aWNhbGx5LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNvIGFzIHRvIGRpc3Rpbmd1aXNoIHRoZW0gZnJv bSB0aGUgdG9wLWxldmVsIEROQ1AgVExWcy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIG5vdGUgdGhhdCB5b3UgdGhlbiBzZXQgdXAg JnF1b3Q7c3ViLXN1YiBUTFZzJnF1b3Q7IHN1Y2ggYXMgJnF1b3Q7UHJlZml4PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRG9tYWluJnF1b3Q7LiBT byB0aGF0IG1lYW5zIHRoYXQgd2UmIzM5O2xsIHNlZTo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvwqAgwqAgwqAg wqBBbiBFWFRFUk5BTC1DT05ORUNUSU9OIFRMViwgY29udGFpbmluZzxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIG/CoCDCoCDCoCDCoEEgREVMRUdBVEVELVBSRUZJWCBUTFYsIGNvbnRhaW5pbmc8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqBBIFBSRUZJWC1ET01BSU4gVExW PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgQ29ycmVjdD88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBUaGUgZmlyc3QgcXVlc3Rpb24gdGhhdCBzcHJpbmdzIHRvIG1pbmQgaXMg b25lIG9mIElBTkE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCByZWdpc3RyaWVzLiBBcmUgeW91IHNldHRpbmcgdXAsIGZvciBlYWNoIFRMViB0eXBl LCBhIG5ldzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHJlZ2lzdHJ5IGZvciBzdWItVExWLXR5cGVzPyBPciwgYXJlIGFsbCBUTFYgdHlwZXMgb3V0 IG9mIG9uZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGdsb2JhbCBzcGFjZT88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBNb3JlIGltcG9ydGFudGx5LCBpZiBvdXQgb2YgYSBnbG9iYWwg VExWIHR5cGUgc3BhY2UsIHdoYXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBoYXBwZW5zIGlmLCBzYXksIGEgJnF1b3Q7UFJFRklYLURPTUFJTiZx dW90OyBUTFYgaXMgcmVjZWl2ZWQgb3V0c2lkZSBvZjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGEgJnF1b3Q7REVMRUdBVEVELVBSRUZJWCZxdW90 OyBUTFY/IElzIHRoYXQgdmFsaWQ/IFNob3VsZCBpdCBiZT8gV2hhdDxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJlaGF2aW9yIHNob3VsZCBJLCBh cyBhbiBpbXBsZW1lbnRlciwgZXhoaWJpdCBpZiBJIHJlY2VpdmU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0Pzxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXMsIHJlYWxseSwg aXMgYSBxdWVzdGlvbiBhYm91dCB3aGF0IHRoZSBjb250ZXh0IGZvcjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb2Nlc3NpbmcgZWFjaCAoc3Vi KVRMViBvcywgb3Igc2hvdWxkIGJlLCB3aGljaCBpcyBub3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzcGVjaWZpZWQgaW4gdGhlIGRvY3VtZW50 LiBJdCBpcyBhbHNvIHJlbGF0ZWQgdG8gaXNzdWUgMikgYmVsb3cuPGJyPg0KPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMSnCoCDCoCDCoCBJIHdvdWxkIHN1 Z2dlc3QgYSBwaHJhc2luZyBzdWNoIGFzOjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O01BWSBjb250YWluIGF0IG1vc3Qgb25lIC4uLiBh bmQgYXQgbW9zdCBvbmUgREhDUHY0IC4uLiB3aXRoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgZXh0ZXJuYWwgY29ubmVjdGlvbi4mcXVv dDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyKcKgIMKg IMKgIFRoZSBzZWNvbmQgcGFydCBvZiB0aGUgZmlyc3QgYnVsbGV0Ojxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O01V U1Qgbm90IGNvbnRhaW4gbW9yZSB0aGFuIG9uZSAuLi4gTVVTVCBiZSBpZ25vcmVkJnF1b3Q7PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg VGhhdCBzaG91bGQsIElNTywgYmUgYSBnZW5lcmljIGNvbW1lbnQgZm9yIGFsbCAoc3ViKS1UTFZz LCBhbmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBicm91Z2h0IGZvcndhcmQgdG8gc2VjdGlvbiA2LjAgb3IgNi4xLCBmb3IgZXhhbXBsZSBzb21l PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd29y ZHNtaXRoaW5nIG9uOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O0FueSByZWNlaXZlZCBUTFYsIHdoaWNo IGRvZXMgbm90IHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50czxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc3BlY2lmaWVkIGlu IHRoZSBiZWxvdywgTVVTVCBiZSBzaWxlbnRseSBkaXNjYXJkZWQsIGFuZDxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgTVVT VCBiZSBpZ25vcmVkIGZvciBwcm9jZXNzaW5nLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE1vcmUgdG8gdGhlIHBvaW50LCB0aGVzZSBU TFZzIChhbmQgKHN1Yi0pVExWcykgYXJlIHNwZWljaWZpZWQgYXM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZWluZyBpbiBhIHNwZWNpZmljIG9y ZGVyLCBvciBhdCBsZWFzdCBpbiBhIHNwZWNpZmljIGhpZXJhcmNoeTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChUTFYgd2l0aGluIGFub3RoZXIg VExWKSBvbiB0cmFuc21pc3Npb24uIFdoYXQgYXJlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnN0cmFpbnRzIG9uIHRoZWlyIHByb2Nl c3Npbmc/IEF0IHdoYXQgcG9pbnQgc2hhbGwgSSBkaXNjYXJkPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5mb3JtYXRpb24gYmFzZWQgb24gaXQg YmVpbmcgcmVjZWl2ZWQgJnF1b3Q7b3V0IG9mIHBsYWNlJnF1b3Q7IChzdWNoIGFzPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSAmcXVvdDtERUxF R0FURUQtUFJFRklYJnF1b3Q7IFRMViBub3QgY29udGFpbmVkIGluIGFuPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7RVhURVJOQUwtQ09O TkVDVElWSVRZJnF1b3Q7IFRMVik/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgMynCoCDCoCDCoCBUaGlzIGxlYWRzIHRvIGEgZ2VuZXJhbCBxdWVzdGlvbjog YXJlIGFsbCB0aGUgY29uc3RyYWludHMgb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgc3ViLVRMVnMgY29udGFpbmVkIGluIHRoaXMgVExW IGNvbXBsZXRlbHkgc3BlY2lmaWVkPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgd291bGQgYWN0dWFsbHkgbGlrZSB0byBzZWUgYSBj aGVjay1saXN0IG9mICZxdW90O2NvbnN0cmFpbnRzJnF1b3Q7IHRoYXQ8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIGNvdWxkIGltcGxlbWVudCBj aGVja3MgZm9yLCBib3RoIHdoZW4gZ2VuZXJhdGluZyBhbmQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm9jZXNzaW5nIHByb3RvY29sIG1lc3Nh Z2VzLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDQpwqAg wqAgwqAgR2VuZXJhbGx5LCB0byB0aGUgZmllbGRzIGluIHRoZSBUTFZzLCBJIGRvIG5vdCBzZWUg dGhlIGVuY29kaW5nLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgICh1bnNpZ25lZC9zaWduZWQsIGVuZGlhbm5lc3MsIC4uLikgc3RpcHVsYXRlZC4g UmF0aGVyIGltcG9ydGFudDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIGZvciBpbnRlcm9wZXJhYmlsaXR5LCB0aGlzIE1VU1QgYmUgY2xhcmlmaWVk Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDUpwqAgwqAg wqAgSSBhbSBnZW5lcmFsbHkgbm90IGEgZ3JlYXQgZmFuIG9mIGhhdmluZyBzb21lIGNvbnN0cmFp bnRzIGluIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHBpY3R1cmUgKHN1Y2ggYXMgdGhlIGxlbmd0aCAmZ3Q7PSA5KSBhbmQgc29tZSBpbiB0 aGUgdGV4dCAoc3VjaCBhczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZxdW90O01VU1QgTk9UIGhhdmUgbW9yZSB0aGFuIG4gb2NjdXJlbmNlcyBv ZiBGT09CQVImcXVvdDspLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIDYpwqAgwqAgwqAgJnF1b3Q7TWF5IGNvbnRhaW4gb3RoZXIgVExWcyBvciBmdXR1cmUg dXNlJnF1b3Q7IC0tIHN1cmUsIGJ1dCB0aGVuIHlvdSBnbzxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9uIHRvIHNheSAmcXVvdDt0aGVzZSBNVVNU IGJlIGlnbm9yZWQmcXVvdDsuIFN0cmljdGx5IHNwZWFraW5nLCB0aGF0IG1lYW5zPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCB5b3UgY2Fu JiMzOTt0ICZxdW90O2Z1dHVyZSB1c2UmcXVvdDsgdGhlbSBlaXRoZXIuIEhvdyBhYm91dDo8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCAmcXVvdDtNYXkgY29udGFpbiBUTFZzIG9mIG90aGVyIHR5cGUsIGZvciBmdXR1 cmUgdXNlLiBGb3IgdGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBwdXJwb3JzZSBvZiB0aGUgcHJvY2Vzc2luZyBzcGVj aWZpZWQgaW4gdGhpcyBkb2N1bWVudCw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN1Y2ggVExWcyBvZiB1bmtub3duIFRM ViB0eXBlIE1VU1QgYmUgaWdub3JlZCZxdW90Oy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOb3RlIHRoZSBzdWJ0bHR5IGhlcmU6ICZx dW90O3Vua25vd24gVExWIHR5cGVzJnF1b3Q7IC0tIHdoYXQgZG9lcyB0aGF0PGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbWVhbj8gV2UmIzM5O3Jl IGFjdHVhbGx5IGJhY2sgYXQgdGhlIElBTkEvaGllcmFyY2hpY2FsL3N1Yi1UTFY8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkaXNjdXNzaW9uLiBB c3N1bWluZyB0aGF0IHlvdSBoYXZlIGp1c3Qgb25lLCBmbGF0IElBTkEgcmVnaXN0cnksPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3VjaCBhcyB5 b3UgYWN0dWFsbHkgaGF2ZS4gQW4gRVhURVJOQUwtQ09OTkVDVElWSVRZIFRMViBzdXJlIGlzPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYSAmcXVv dDtrbm93biBUTFYgVHlwZSZxdW90Oy4gSWYgeW91IGdldCBhIERFTEVHQVRFRC1QUkVGSVggVExW IGNvbnRhaW5pbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBhbiBFWFRFUk5BTC1DT05ORUNUSVZJVFkgVExWLCBpcyB0aGF0IHZhbGlkLCBvciBt dXN0IHRoYXQgYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBpZ25vcmVkPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFNvLCB3aXRoIHRoZSBjdXJyZW50IHNldC11cCBvZiBJQU5BIHJl Z2lzdHJpZXMsIHRoZSAmcXVvdDt1bmtub3duIFRMVjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHR5cGVzJnF1b3Q7IGlzIG5vdCB0aGUgcmlnaHQg cGhyYXNlLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIE15IHByZWZlcmVuY2UgaW4gdGhpcyBzb3J0IG9mIHNpdHVhdGlvbiBpcyBhY3R1 YWxseSB0byBzZXQgdXA8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBoaWVyYXJjaGljYWwgSUFOQSByZWdpc3RyaWVzOjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG/C oCDCoCDCoCDCoEROQ1Agc2V0cyB1cCB0aGUgdG9wLWxldmVsIFRMViB0eXBlIHJlZ2lzdHJ5Ljxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIG/CoCDCoCDCoCDCoEhOQ1Agc3BlY2lmaWVzIChmcm9tIHdpdGhpbiB0aGF0IHJlZ2l0 cnkpIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEVYVEVSTkFMLUNPTk5FQ1RJVklUWSBUTFYgdHlw ZSwgd2hpY2g6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgU2V0 cyB1cCBhIG5ldyByZWdpc3RyeSBmb3Igc3ViLVRMViB0eXBlczxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoEFsbG9jYXRlcyB0aGUgREVMRUdBVEVELVBSRUZJWCBm cm9tIHRoYXQgbmV3PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg cmVnaXN0cnk8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAoYW5kIHNvIG9uKS48YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBXaGF0IGl0IGRvZXMgaXMgdG8g c2V0IHVwIGEgY29udGV4dCBpbiB3aGljaCAmcXVvdDt1bmtub3duIFRMViB0eXBlJnF1b3Q7PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKGFuZCBz dWNoKSBtZWFucyBzb21ldGhpbmcgLS0gYW5kIGFsc28gc29sdmVzIHRoZSByZXN0IG9mIHRoZTxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByb2Nl c3NpbmcgY29udGV4dCBjb21tZW50cyBhYm92ZTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFsdGVybmF0aXZlbHksIHN1cmUsIHlvdSBj b3VsZCBwdXQgc29tZXRoaW5nIGxpa2U6PGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7TWF5IGNv bnRhaW4gVExWcyBvZiBvdGhlciB0eXBlLCBmb3IgZnV0dXJlIHVzZS4gRm9yIHRoZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgcHVycG9yc2Ugb2YgdGhlIHByb2Nlc3Npbmcgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQs PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBUTFZzIG9mIHR5cGVzIG90aGVyIHRoYW4gRk9PLCBCQVIsIEZPT0JBUiwgYW5k IEdOWUYgdHlwZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgTVVTVCBiZSBpZ25vcmVkJnF1b3Q7Ljxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElNTyB0aGlzIGlz IGxlc3MgZmxleGlibGUgYW5kIGxlYWRzIHRvIG1vcmUgcmVwZXRpdGlvbi48YnI+DQo8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqBTZWN0aW9uIDYuMS4yPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhlIGRvY3VtZW50IHJlYWRzOjxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O1ZhbGlkIExpZmV0aW1lOsKgIMKg VGhlIHRpbWUgaW4gc2Vjb25kcyB0aGUgZGVsZWdhdGVkIHByZWZpeCBpczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdmFsaWQuIFRoZSB2YWx1ZSBpcyByZWxhdGl2 ZSB0byB0aGUgcG9pbnQgaW4gdGltZSB0aGUgTm9kZS1EYXRhIFRMVjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgd2FzIGxhc3QgcHVibGlzaGVkLsKgIEl0IE1VU1Qg YmUgdXBkYXRlZCB3aGVuZXZlciB0aGUgbm9kZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgcmVwdWJsaXNoZXPCoCBpdHMgTm9kZS1EYXRhIFRMVi4mcXVvdDs8YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCBJIGp1c3QgY2FuJiMzOTt0IHBhcnNlIHRoYXQuIFdlbGwsIEkg Y2FuLCBidXQgd2hhdCBJIGdldCBkb2VzbiYjMzk7dCBtYWtlPGJyPg0KwqAgwqAgwqAgwqAgc2Vu c2UgdG8gbWU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7cmVsYXRp dmUgdG8gdGhlIHBvaW50IGluIHRpbWUgdGhlIE5vZGUtRGF0YSBUTFYgd2FzIGxhc3QgcHVibGlz aGVkJnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgU28swqAgSSBwdWJsaXNoIGEg Tk9ERS1EQVRBIFRMVi4gTXVzdCBJIG5vdyByZW1lbWJlciB3aGVuIEkgZGlkIHRoYXQsIHNheSw8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBhdCB0MCwgYW5kIHRoZW4gbmV4dCB0aW1lIEkgcHVibGlz aCBhIE5PREUtREFUQSBUTFYgaW5jbHVkZSAodC10MCkgYXMgVmFsaWQ8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCBMaWZldGltZT8gVGhhdCBkb2VzIGxvb2sgbGlrZSB3aGF0IHRoZSB0ZXh0IHNheXMs IGJ1dCBpdCBhbHNvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgZG9lc24mIzM5O3Qgc291bmQgbGlr ZSBhICZxdW90O1ZhaWQgTGlmZXRpbWUmcXVvdDsuIEdpdmVuIHRoZSBuYW1lIG9mIHRoZSBmaWVs ZCw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCBMaWZldGltZSwgSSB3b3VsZCBleHBlY3QgaXQgdG8g bWVhbiAmcXVvdDtVcG9uIHJlY2VpdmluZyB0aGlzIFRMViwgcGxlYXNlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgY29uc2lkZXIgdGhlIGluZm9ybWF0aW9uIHZhbGlkIGZvciB0aGlzIG11Y2ggdGlt ZSZxdW90OyAtLSBidXQsIHRoYXQmIzM5O3Mgbm90IHdoYXQgdGhlIHRleHQgc2F5cy48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTYW1lIGNvbW1lbnQgYXBwbGllcyB0byBQcmVm ZXJyZWQgTGlmZXRpbWU8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBbHNvLCBm cm9tIHRoaXMgc2VjdGlvbjo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmcXVvdDsqwqAgWmVybyBvciBtb3JlIFByZWZpeCBEb21haW4gVExWcy7CoCBJbiBh YnNlbmNlIG9mIGFueSBzdWNoIFRMVjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHRoZSBwcmVmaXggaXMgYXNzdW1lZCB0byBiZSBnZW5lcmF0ZWQgYnkgYW4gSE5DUC1y b3V0ZXIgYW5kIGZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlu dGVybmFsIHVzZSBvbmx5LiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IENvdWxkIGdhaW4gZnJvbSBiZWluZyBhIGxpdHRsZSBtb3JlIHNwZWNpZmljOiB3aGF0IGlzICZx dW90O2ludGVybmFsIHVzZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG9ubHkmcXVvdDsg KGludGVybmFsIHRvIHdob20/KSAtLSByZWxhdGVkIHRvIG15IHByZXZpb3VzIGNvbW1lbnQgYWJv dXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkZWZpbml0aW9uIG9mIEV4dGVybmFsL0lu dGVybmFsLiBBbHNvICZxdW90O3VzZSZxdW90OyAtLSBkbyB5b3UgbWVhbiB0aGF0ICZxdW90O3Ro aXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcmVmaXggTVVTVCBOT1QgYmUgbGVha2Vk IGV4dGVybmFsbHksIGkuZS4sIGFkZHJlc3NlcyBmcm9tIHdpdGhpbiB0aGlzPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgcHJlZml4IE1VU1QgTk9UIGJlIHVzZWQgYXMgYSBzb3VyY2UgYWRk cmVzcyBmb3IgdHJhZmZpYyBvdXRzaWRlIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGhvbWVuZXQ/IElmIHNvLCBkb2VzIHRoaXMgbWVhbiB0aGF0IHlvdSBhbGxvdyBhIGhvbWVuZXQg cm91dGVyIHRvIGdyYWI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbnkgb2RkIGdsb2Jh bCBwcmVmaXggYW5kIHRyZWF0IGFzIHByaXZhdGU/IE9yLCBpcyB0aGlzIGEgbWF0dGVyIG9mPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc2ltcGx5IHJlZmxlY3RpbmcgdGhlIGFscmVhZHkg ZXhpc3RpbmcgJnF1b3Q7ZG9uJiMzOTt0IHJvdXRlIDE5Mi4xNjgvMTYmcXVvdDsgKGFuZDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGVxdWl2LikgcnVsZXM/PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgRWl0aGVyIHdheSwgdGhhdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQu PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgNi4yLjE8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtBbGwgSE5DUCBub2RlcyBydW5u aW5nIHRoZSBwcmVmaXggYXNzaWdubWVudCBhbGdvcml0aG0gTVVTVCB1c2UgdGhlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZm9sbG93aW5nIHBhcmFtZXRlcnM6JnF1b3Q7PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRmlyc3QsIEkgdGhpbmsgdGhhdCBhbiBl bGVtZW50IG9mIGNsYXJpZmljYXRpb24gd291bGQgYmUgZ29vZC4gVGhlc2U8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBwYXJhbWV0ZXJzLCB3aGVyZSBhcmUgdGhleSBmcm9tPyBEbyB0aGV5 IGNvbWUgZnJvbTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtJLUQuaWV0Zi1ob21lbmV0 LXByZWZpeC1hc3NpZ25tZW50XSwgYXJlIHRoZXkgaW4gdGhhdCBzcGVjaWZpY2F0aW9uPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZ2l2ZW4gYXMgJnF1b3Q7b3B0aW9uYWwmcXVvdDsgKHNv IHRoYXQgb25lIG1pZ2h0IGdldCB0aGUgaWRlYSB0byBub3QgdXNlIHRoZW0pLDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIG9yPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFNlY29uZCwgaXMgaXQgdGhlIHBhcmFtZXRlcnMgLSBvciB0aGVpciB2YWx1ZXMgLSB0aGF0IG11 c3QgYmUgdXNlZD88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGlzIGdvZXMg YSBsaXR0bGUgYml0IGRlZXBlcjsgSSB0aGluayB0aGF0IHdoYXQgeW91IGFyZSBkb2luZyBoZXJl IGlzLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluIHBhcnQsIHRvIHNwZWNpZnkgJnF1 b3Q7d2hpY2ggdmFsdWVzIHRvIGFzc2lnbiB0byB0aGUgZGlmZmVyZW50IHBhcmFtZXRlcnM8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBmcm9tIFtJLUQuaWV0Zi1ob21lbmV0LXByZWZpeC1h c3NpZ25tZW50XSZxdW90OyAtLSBhbHRob3VnaCB0aGF0IGRvY3VtZW50PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgaXMgbm90IHBhcnRpY3VsYXJseSBjbGVhciBvbiB3aGljaCBwYXJhbWV0 ZXJzIGZvcm0gdGhlIGludGVyZmFjZSB0byBITkNQPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYW5kIHRvIG90aGVyIHByb3RvY29scy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBCdXQsIHRoZSBxdWVzdGlvbiBpcywgd2hhdCBkb2VzIGl0IG1lYW4gdG8gJnF1b3Q7TVVT VCB1c2UgdGhlIGZvbGxvd2luZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBhcmFtZXRl cnMmcXVvdDsgaGVyZT8gSSBjYW4gc2VlIHRoYXQgdXNpbmcgdGhlc2UgdGVybXMvZGVmaW5pdGlv bnMgaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGUgZGVzY3JpcHRpb24gb2YgSE5D UCBtYWtlcyBzZW5zZSwgYnV0IHRoYXQgZG9lcyBub3QgYSAmcXVvdDtNVVNUIHVzZTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyZxdW90OyBtYWtl Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNvLCBJIHNpbXBseSBkbyBub3Qg dW5kZXJzdGFuZCB3aGF0IHlvdSBpbnRlbmQgd2l0aCA2LjIuMS48YnI+DQo8YnI+DQrCoCDCoCDC oCDCoCBvwqAgwqAgwqAgwqBTZWN0aW9uIDYuMi4yLCA2LjMsIGV0Yy4uLi48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGlzIGxpbmtzIGluIHdpdGggcHJldmlvdXMgY29tbWVu dHMgcmVnYXJkaW5nIHRoZSBoaWVyYXJjaHkgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgbG9jYXRpb24gb2YgcHJvdG9jb2wgZWxlbWVudHMuIFRoZSBUTFZzIGRlZmluZWQgaGVyaW4s IGFyZSB0aGV5PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7dG9wIGxldmVsIFRM VnMmcXVvdDsgb3IgYXJlIHRoZXkgc3ViLVRMVnMsIHRvIGJlIGNhcnJpZWQgd2l0aGluIGFub3Ro ZXIgVExWPzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFuZCwgd2hhdCYjMzk7cyB0aGUg Y29udGV4dCBvZiB0aGVpciBwcm9jZXNzaW5nLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFRoaXMgcG9pbnQgaXMgcGFydGljdWxhcmx5IG9ic2N1cmUgc2luY2UgdGhlIHByb3Rv Y29sIGRvZXMgbm90IGFjdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN5bW1ldHJpYyBu b3IgY29uc2lzdGVudCBoZXJlOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIG/CoCDCoCDCoCDCoGl0IGRlZmluZXMgYW4gJnF1b3Q7RVhURVJOQUwtQ09OTkVD VElPTiZxdW90OyBUTFYgKHdoaWNoIHJlYWxseTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIHdoYXQgb3RoZXIgcHJvdG9jb2xzIHdvdWxkIGNh bGwgYSAmcXVvdDttZXNzYWdnZSZxdW90Oykgd2hpY2g8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjYXJyaWVzwqAgc3ViLVRMVnMgdGhhdCBoYXZl IHRvIGRvIHdpdGggZGVzY3JpYmluZyAmcXVvdDtFWFRFUk5BTDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENPTk5FQ1RJT05TJnF1b3Q7Ljxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoEJ1 dCwgZm9yIFByZWZpeCBBc3NpZ25tZW50cywgaXQgZG9lcywgYXMgZmFyIGFzIEkgY2FuIHRlbGws PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbm90 IGRlZmluZSBhICZxdW90O1BSRUZJWC1BU1NJR05NRU5UJnF1b3Q7IG1lc3NhZ2UgKGFwb2xvZ2ll cywgVExWKTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHdoaWNoIGNvbnRhaW5zIHRoZSByZWxhdGVkIHN1Yi1UTFZzPGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHRocm91Z2ggdGhyb3Vn aCAtLSBpZGVhbGx5LCByZS1lbmdpbmVlcmVkIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgYmUgaG9tb2dlbm91cyBhbmQgY29uc2lzdGVudCwgYnV0IChhdCB0aGUgdmVyeSBzdHJpY3Qg bWluaW11bSkgY2FsbGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb3V0IGFuZCBleHBs YWluZWQgY2xlYXJseS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqA2LjIuMy7C oCBNYWtpbmcgTmV3IEFzc2lnbm1lbnRzPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAmcXVvdDtXaGVuZXZlciB0aGUgUHJlZml4IEFzc2lnbm1lbnQgQWxnb3JpdGhtIHN1 YnJvdXRpbmUgaXMgcnVuIG9uIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBDb21tb24gTGluayBhbmQgd2hlbmV2ZXIgYSBuZXcgcHJlZml4IG1heSBiZSBhc3NpZ25l ZCAoY2FzZSAxIG9mIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHN1YnJv dXRpbmUpLCB0aGUgZGVjaXNpb24gb2Ygd2hldGhlciB0aGUgYXNzaWdubWVudCBvZiBhIG5ldyBw cmVmaXg8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpcyBkZXNpcmVkIE1VU1Qg Zm9sbG93IHRoZXNlIHJ1bGVzOsKgIMKgIMKgIMKgIMKgJnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSG9sZCBvbiB0aGVyZSBmb3IgYSBzZWNvbmQ6PGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMSnCoCDCoCDCoCBXaGF0IGlzICZx dW90O3RoZSBQcmVmaXggQXNzaWdubWVudCBBbGdvcml0aG0gc3Vicm91dGluZSZxdW90Oz8gVGhy b3cgYTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IGNpdGF0aW9uIGludG8gW0ktRC5pZXRmLWhvbWVuZXQtcHJlZml4LWFzc2lnbm1lbnRdIGhlcmUs IHNvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg dGhlIHJhbmRvbSByZWFkZXIga25vd3Mgd2hhdCB5b3UmIzM5O3JlIHRhbGtpbmcgYWJvdXQgLS0g YW5kLCBhPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgc2VjdGlvbiByZWZlcmVuY2UsIGFsc28uPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgMinCoCDCoCDCoCBUaGlzIGlzIGV4YWNlcmJhdGVkIGJ5IHRoZSBm YWN0IHRoYXQgdGhlIGRlc2NyaXB0b24gcG9pbnRpbmcgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtjYXNlIDEgb2YgdGhlIHN1YnJv dXRpbmUmcXVvdDsuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgSSBndWVzcyB0aGF0IHRoYXQgY29ycmVzcGluZHMgdG8gJnF1b3Q7YnVsbGV0IG51 bWJlciAxJnF1b3Q7IG9uIHBhZ2UgOTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGluIFtJLUQuaWV0Zi1ob21lbmV0LXByZWZpeC1hc3NpZ25tZW50 XSwgYnV0IGluIGEgcHJvcG9zZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBzdGFuZGFyZCwgZ3Vlc3Npbmcgc2hvdWxkIG5vdCBiZSBuZWVkZWQu PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMynCoCDCoCDC oCAmbHQ7Z2VuZXJhbCByYW50Jmd0Ozxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFRoYXQgYXNpZGUsIHN1YnJvdXRpbmVzIGFyZSBwcm9ncmFtbWlu ZyBjb25zdHJ1Y3RzLCBub3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBzcGVjaWZpY2F0aW9uIGVsZW1lbnRzLiBKdXN0IG91dCBvZiBzcGl0ZSwg SSYjMzk7bGwgZ28gaW1wbGVtZW50PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgSE5DUCB1c2luZyBHT1RPJiMzOTtzIGluc3RlYWQgb2YgJnF1b3Q7 c3Vicm91dGluZXMmcXVvdDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAmbHQ7L2dlbmVyYWwgcmFudCZndDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA0KcKgIMKgIMKgIEkgbm90aWNlIHRoYXQgc29tZXRp bWVzIHRoaXMgaXMgY2FsbGVkIHRoZSAmcXVvdDtEaXN0cmlidXRlZCBQcmVmaXg8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBc3NpZ25tZW50IEFs Z29yaXRobSZxdW90OywgYXQgb3RoZXIgdGltZXMgJnF1b3Q7cHJlZml4IGFzc2lnbm1lbnQgYWxn b3JpdGht4oCdLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHRoZW4gJnF1b3Q7UHJlZml4IEFzc2lnbm1lbnQgQWxnb3JpdGhtIHN1YnJvdXRpbmUm cXVvdDssIGV0Yy48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqBBcmUgdGhleSBhbGwgdGhlIHNh bWU/PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgSWYgeWVzLCB0aGVuIHdoeSBhcmUgdGhleSB3cml0dGVu LCBhbmQgY2FwaXRhbGl6ZWQsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGlmZmVyZW50bHk/PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgb8KgIMKgIMKgIMKgSWYgbm8sIHRoZW4gd2hhdCYjMzk7cmUgdGhlIGRpZmZlcmVuY2VzIGJl dHdlZW4gdGhlbT88YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBOZXh0 LCB0aGUgZG9jdW1lbnQgcmVhZHM6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgJnF1b3Q7SWYgdGhlIERlbGVnYXRlZCBQcmVmaXggVExWIGNvbnRhaW5zIGEg REhDUHY0IG9yIERIQ1B2NiBEYXRhIFRMViw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoGFuZCB0aGUgbWVhbmluZyBvZiBvbmUgb2YgdGhlIERIQ1Agb3B0aW9ucyBp cyBub3QgdW5kZXJzdG9vZCBieTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgdGhlIEhOQ1Agcm91dGVyLCB0aGUgY3JlYXRpb24gb2YgYSBuZXcgcHJlZml4IGlzIG5v dCBkZXNpcmVkLjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgVGhp cyBydWxlIGFwcGxpZXMgdG8gVExWcyBpbnNpZGUgRGVsZWdhdGVkIFByZWZpeCBUTFZzIGJ1dCBu b3QgdG88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRob3NlIGlu c2lkZSBFeHRlcm5hbCBDb25uZWN0aW9uIFRMVnMuJnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgV2hhdCBkb2VzICZxdW90O2lzIG5vdCBkZXNpcmVkJnF1b3Q7IG1lYW4/ PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7Li4u YSBuZXcgcHJlZml4IE1VU1QgTk9UIGJlIGNyZWF0ZWQ/JnF1b3Q7PGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7Li4uYSBuZXcgcHJlZml4IFNIT1VMRCBOT1Qg YmUgY3JlYXRlZD8mcXVvdDs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAmcXVvdDsuLi5hIG5ldyBwcmVmaXggTUFZIGJlIGNyZWF0ZWQsIGJ1dCBpcyBub3QgbmVjZXNz YXJ5PyZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZSBkb2N1bWVu dCByZWFkczo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAm cXVvdDtJZiB0aGUgcmVtYWluaW5nIHByZWZlcnJlZCBsaWZldGltZSBvZiB0aGUgcHJlZml4IGlz IDAgYW5kIHRoZXJlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBpcyBhbm90aGVyIGRlbGVnYXRlZCBwcmVmaXggb2YgdGhlIHNhbWUgSVAgdmVyc2lvbiB1 c2VkIGZvciBwcmVmaXg8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoGFzc2lnbm1lbnQgd2l0aCBhIG5vbi1udWxsIHByZWZlcnJlZCBsaWZldGltZSwgdGhl IGNyZWF0aW9uIG9mIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoG5ldyBwcmVmaXggaXMgbm90IGRlc2lyZWQuJnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgU3VnZ2VzdCByZXBsYWNpbmcgJnF1b3Q7bm9uLW51bGwmcXVvdDsg YnkgJnF1b3Q7bm9uLXplcm8mcXVvdDsgLS0gYnV0LCBiZXlvbmQgdGhhdCwgd2hhdDxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRvZXMgJnF1b3Q7aXMgbm90IGRlc2lyZWQmcXVvdDsgbWVh bj88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTYW1lIGNvbW1lbnQgZm9yIHRo ZSBuZXh0IHBhcmFncmFwaDo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmcXVvdDtPdGhlcndpc2UsIHRoZSBjcmVhdGlvbiBvZiBhIG5ldyBwcmVmaXggaXMg ZGVzaXJlZCZxdW90Ozxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFt IEkgcmlnaHQgaW4gcmVhZGluZyB0aGVzZSB0aHJlZSBwYXJhZ3JhcGhzIGFzOjxicj4NCjxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDEpwqAgwqAg wqAgSWYgJmx0O2NvbmRpdGlvbjEmZ3Q7IHRoZW4gbmV3IHByZWZpeCBNVVNUIE5PVCBiZSBjcmVh dGVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg MinCoCDCoCDCoCBpZiAmbHQ7Y29uZGl0aW9uMiZndDsgdGhlbiBuZXcgcHJlZml4IE1VU1QgTk9U IGJlIGNyZWF0ZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAzKcKgIMKgIMKgIE90aGVyd2lzZSwgaWYgJmx0O2NvbmRpdGlvbiAzJmd0OyB0aGVu IG5ldyBwcmVmaXggTVVTVCBiZSBjcmVhdGVkPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgVGhhdCBpcyBob3cgdGhlIHRleHQgcmVhZHMsIHdoaWNoIGJlZ3MgdGhlIHF1ZXN0aW9u Ojxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElzIGl0IHBv c3NpYmxlIGZvciAmbHQ7Y29uZGl0aW9uMSZndDssICZsdDtjb25kaXRpb24yJmd0OywgYW5kICZs dDtjb25kdGlvbjMmZ3Q7PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg dG8gYWxsIG5vdCBiZSBzYXRpc2ZpZWQsIGFuZCB3aGF0IGhhcHBlbnMgaW4gdGhhdCBjYXNlPzxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgKnRoaW5rKiB0aGF0IHRoaXMgaXMg YSBjYXNlIG9mIHVuZGVyc3BlY2lmaWNhdGlvbiwgb3IgYXQgbGVhc3Qgd2hlcmU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBpdCBsb29rcyBsaWtlIHRoZXJlJiMzOTtzIGEgY2FzZSBvZiB1 bmRlcnNwZWNpZmljYXRpb24uPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8Kg IMKgIMKgIMKgNi4yLjQ6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg JnF1b3Q7TVVTVCBjcmVhdGUgYW4gYXBwcm9wcmlhdGUgcm91dGUgLi4uJnF1b3Q7PGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV2hhdCYjMzk7cyAmcXVvdDthbiBhcHByb3ByaWF0 ZSByb3V0ZSZxdW90Oz88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEbyB5b3UgbWVhbiAm cXVvdDtpbnN0YWxsIGVudHJ5IGludG8gdGhlIHJvdXRpbmcgdGFibGUmcXVvdDssIG9yIGRvIHlv dSBtZWFuIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbGF1bmNoIGEgcm91dGluZyBw cm9jZXNzIHRvIGRpc2NvdmVyLCBjYWxjdWxhdGUsIG9yIG90aGVyd2lzZSBvYnRhaW48YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0aGF0IHJvdXRlPzxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIERvIHlvdSBuZWVkIHRoZSBlbnRpcmUgcGF0aCwgb3IganVzdCB0aGUgJnF1b3Q7bmV4 dCBob3AgdG93YXJkcyAuLi4mcXVvdDs/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKg IMKgNi4yLjY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtX aGVuIGFuIEhOQ1Agcm91dGVyIHJlY2VpdmVzIGEgcmVxdWVzdCBmb3IgcHJlZml4IGRlbGVnYXRp b24gLi4uJnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT0ssIGhvdyBk b2VzIGEgSE5DUCByb3V0ZXIgcmVjZWl2ZSBzdWNoIGEgcmVxdWVzdD8gR3JlcHBpbmcgdGhyb3Vn aCB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkb2N1bWVudCBmcHIgJnF1b3Q7cmVx dWVzdCZxdW90OyBJIHNlZSBubyBwcm90b2NvbCBzaWduYWxzIHRoYXQgY29ycmVzcG9uZCB0bzxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoaXMuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgVGhlbiwgdGhpczo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmcXVvdDtUaGUgYXNzaWduZWQgcHJlZml4ZXMgTVVTVCBOT1QgYmUgZ2l2ZW4gdG8g Y2xpZW50cyZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG1hZGUgbWUg d29uZGVyIHdoYXQgYSAmcXVvdDtjbGllbnQmcXVvdDsgaXMuIEkgc2VlIERIQ1B2Ni92NCBjbGll bnQgdXNlZCw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBvY2Nhc2lvbmFsbHksIGFuZCBp biBvdGhlciBwbGFjZXMgSSBzZWUganVzdCAmcXVvdDtjbGllbnQmcXVvdDsgLS0gaXMgdGhpczxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGludGVudGlvbmFsbHksIGFuZCwgaWYgc28sIHdo YXQgaXMgYSAmcXVvdDtjbGllbnQmcXVvdDs/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKg IMKgIMKgNi4zPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg JnF1b3Q7Tm9kZXMgTUFZLCBhdCBhbnkgdGltZSwgdHJ5IHRvIHJlc2VydmUgYSBuZXcgYWRkcmVz cyBmcm9tIGFueTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXBwbGllZCBB c3NpZ25lZCBQcmVmaXgmcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBX aGF0IGlzIGFuICZxdW90O2FwcGxpZWQgQXNzaWduZWQgUHJlZml4JnF1b3Q7LiBHaXZlbiBjYXBp dGFsaXphdGlvbiwgaXQgaXMgYW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtB c3NpZ25lZCBQcmVmaXgmcXVvdDsgdGhhdCBpcyBhcHBsaWVkIHNvbWV3aGVyZSwgSSBzdXBwb3Nl LCBidXQgd2hlcmUgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gd2hhdD88YnI+ DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGUgZG9jdW1lbnQgcmVhZHM6PGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRm9yIGFueSBhc3NpZ25l ZCBwcmVmaXggZm9yIHdoaWNoIFNMQUFDIGNhbm5vdCBiZSB1c2VkLCB0aGUgZmlyc3Q8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBxdWFydGVyIG9mIHRoZSBhZGRyZXNzZXMgYXJl IHJlc2VydmVkIGZvciByb3V0ZXJzIEhOQ1AgYmFzZWQgYWRkcmVzczxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGFzc2lnbm1lbnRzLCB3aGVyZWFzIHRoZSBsYXN0IHRocmVlIHF1 YXJ0ZXJzIGFyZSBsZWZ0IHRvIHRoZSBESENQdjY8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAocmVzcC7CoCBESENQdjQpIGVsZWN0ZWQgcm91dGVyIChTZWN0aW9uIDEwIHNwZWNp ZmllcyB0aGUgREhDUCBzZXJ2ZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBl bGVjdGlvbiBwcm9jZXNzKS7CoCBGb3IgaW5zdGFuY2UsIGlmIHRoZSBwcmVmaXggPGEgaHJlZj0i aHR0cDovLzE5Mi4wLjIuMC8yNCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+MTky LjAuMi4wLzI0PC9hPiBpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFzc2ln bmVkIGFuZCBhcHBsaWVkIHRvIGEgQ29tbW9uIExpbmssIGFkZHJlc3NlcyBpbmNsdWRlZCBpbjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMC4y LjAvMjYiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPjE5Mi4wLjIuMC8yNjwvYT4g YXJlIHJlc2VydmVkIGZvciBITkNQIG5vZGVzIGFuZCB0aGUgcmVtYWluaW5nIGFkZHJlc3Nlczxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGFyZSByZXNlcnZlZCBmb3IgdGhlIGVs ZWN0ZWQgREhDUHY0IHNlcnZlci48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBX aHkgJnF1b3Q7dGhlIGZpcnN0IHF1YXJ0ZXImcXVvdDs/IEl0IHNlZW1zIGEgcmF0aGVyIGFyYml0 cmFyeSB2YWx1ZT8gSXMgaXQga25vd248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBi ZSBlbm91Z2gvdG9vIG11Y2gvdG9vIGxpdHRsZT88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtITkNQIHJvdXRlcnMgYXNzaWduIHRoZW1zZWx2ZXMg YWRkcmVzc2VzIHVzaW5nIHRoZSBOb2RlIEFkZHJlc3M8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCBUTFYmcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBPSywgYnV0Li4uZG8gdGhleSBzZW5kIHRoYXQgVExWIHRvIHRoZW1zZWx2ZXM/ IE9yIGRvIHRoZXkgc2VuZCBpdCB0bzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNvbWVv bmUgZWxzZSwgb3IgLi4uPzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFBhcnQgb2YgdGhl IGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uIGlzIGVtYmVkZGVkIGluIHRoZSB0ZXh0IGJlbG93IHRo ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBpY3R1cmUgaW4gc2VjdGlvbiA2LjMsIGJ1 dCBub3QgYWxsIC0tIGFuZCwgSSBiZWxpZXZlLCB0aGlzIGlzIHBvdGVudGlhbGx5IGFub3RoZXIg cHJvYmxlbSBvZiBtb3JlIGdsb2JhbCBzY29wZS48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBHZW5lcmFsbHksIGZvciBlYWNoIG1lc3NhZ2UgKG9yIFRMVikgaXQmIzM5O3MgZ29v ZCB0byBrbm93IGhvdyBpdCBpcyBmb3JtYXR0ZWQsIGJ1dCBpdCYjMzk7cyBmYW50YXN0aWMgdG8g a25vdyBhbHNvIGhvdyBpdCYjMzk7cyBnZW5lcmF0ZWQgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgaG93IGl0IGlzIHByb2Nlc3NlZC4gSSBmYWxpIHRvIGZpbmQgdGhhdCAodGhyb3Vn aCBhbmQgdGhyb3VnaCkgaW4gdGhpczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRvY3Vt ZW50LCBhbmQgdGhhdCBtYWtlcyBpdCBoYXJkZXIgdG8gaW1wbGVtZW50Ljxicj4NCjxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGRvIHNvbWV0aGlu ZyBsaWtlIHRoaXMsIChnZW5lcmFsbHksIGZvciB0aGUgVExWPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgdHlwZXMgZGVmaW5lZD8pOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFNlY3Rpb24gWC4gRk9PQkFSIFRMVnM8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmbHQ7ZGVzY3JpcHRpb24mZ3Q7PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU2VjdGlvbiBYLjEg R2VuZXJhdGlvbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIEEgRk9PQkFSIFRMViBpcyBnZW5lcmF0ZWQgd2hlbiBhLCBiLCBjIGhhcHBlbnMuPGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg V2hlbiBnZW5lcmF0aW5nIGEgRk9PQkFSIFRMViwgaXRzIGNvbnRlbnQgaXMgZGV0ZXJtaW5lZCBh czxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZv bGxvd3MuLi4uPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg U2VjdGlvbiBYLjIgUHJvY2Vzc2luZzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIE9uIHJlY2VpdmluZyBhIEZPT0JBUiBUTFYsIHRha2UgdGhlIGZv bGxvd2luZyBzdGVwcyAuLi48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGF0 IHdvdWxkIGFsc28gYmUgdGhlIHBsYWNlIChpbiBYLjEpIHRvIHN0YXRlIHdoZXJlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgdG8gcHV0IGluZm9ybWF0aW9uIChmb3IgZXhhbXBsZSwgd2hl biBhIFRMViBtdXN0IGJlIGluc2lkZSBhbm90aGVyIFRMVik8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBvciBjb25zdHJhaW50cyBvbiBwcm9jZXNzaW5nIChYLjIpIGZvciBleGFtcGxlIGlm IGEgVExWIGlzIGludmFsaWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB1bmxlc3MgaWYg Y29udGFpbmVkIGluc2lkZSBhbm90aGVyIFRMVi48YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBvwqAg wqAgwqAgwqA5IFNlY3VyaW5nIFRoaXJkLVBhcnR5IFByb3RvY29sczxicj4NCjxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIEkgdGFrZSBpc3N1ZSB3aXRoIHRoZSBiZWxvdzo8YnI+DQo8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtQcmUtc2hhcmVkIGtl eXMgKFBTS3MpIGFyZSBvZnRlbiByZXF1aXJlZCB0byBzZWN1cmUgSUdQcyBhbmQgb3RoZXI8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHByb3RvY29scyB3aGljaCBs YWNrIHN1cHBvcnQgZm9yIGFzeW1tZXRyaWMgc2VjdXJpdHkuJnF1b3Q7PGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgUHJlLXNoYXJlZCBrZXlzIGFyZSBjaG9zZW4sIGluIHNvbWUg c2NlbmFyaW9zIGFuZCBmb3Igd2hhdGV2ZXIgcmVhc29ucyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCByZWdhcmRsZXNzIG9mIHRoZSBjYXBhY2l0eSBvZiB0aGUgdW5kZXJsYXlpbmcgcHJv dG9jb2xzIC0tIGV2ZW4gd2hlbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBwcm90 b2NvbChzKSAoSUdQIG9yIG90aGVyd2lzZSkgYXJlIGZ1bGx5IGNhcGFibGUgb2YgYW5kIGNvbXBs ZXRlbHk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzdXBwb3J0cyBhc3N5bWV0cmljIHNl Y3VyaXR5LiBQbGVhc2UgYWRkcmVzcyB0aGlzIGJ5IGEgbGVzcyBicm9hZCBjbGFpbTxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIGZvciB3aGVuIFBTSyBhcmUgdXNlZC48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBCdXQsIEkgd29uZGVyLCByZWFkaW5nIHRoaXMgc2VjdGlv biBhcyBhIHdob2xlOiB5b3UgZ2VuZXJhdGUsIGFuZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGRpc3RyaWJ1dGUgdGhyb3VnaCBITkNQLCBhIFBTSz8gU28gYWxsIGl0IHRha2VzIHRvIGdl dCBhY2Nlc3MgdG8gc2FpZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGtleSBpcyB0byBz aXQgYnkgYW5kIHBhc3NpdmVseSBsaXN0ZW4gdG8gdHJhZmZpYyBmb3IgYSBiaXQ/IFRoYXQgZG9l cyBzdHJpa2UgbWUgYXMgYSBkYW5nZXJvdXMgb3B0aW9uIHRvIGhhdmUuLi5yZWFkaW5nIHRoZSBz ZWN1cml0eTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNvbnNpZGVyYXRpb25zIHNlY3Rp b24sIHRoZXJlIHNlZW1zIHRvIGJlIG5vdGhpbmcgc2VjdXJpbmcgSE5DUCBhZ2FpbnN0PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZWF2ZXNkcm9wcGluZyAtLSBvciwgaWYgdGhlcmUgaXMs IHRoYXQmIzM5O3Mgbm90IGNhbGxlZCBvdXQuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgSSBub3RlIHRoYXQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIEROQ1Agc3Rh cnQgb3V0IGJ5IHNheWluZzo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAmcXVvdDtJZiBzcGVjaWZpZWQgaW4gdGhlIEROQ1AgcHJvZmlsZSwgZWl0aGVyIERU TFMgW1JGQzYzNDddIG9yIFRMUzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtS RkM1MjQ2XSBtYXkgYmUgdXNlZCB0byBhdXRoZW50aWNhdGUgYW5kIGVuY3J5cHQgZWl0aGVyIHNv bWUgKGlmPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3BlY2lmaWVkIG9wdGlv bmFsIGluIHRoZSBwcm9maWxlKSwgb3IgYWxsIHVuaWNhc3QgdHJhZmZpYyZxdW90Ozxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFuZCwgc2VjdGlvbiAzIG9mIEhOQ1Agc3RhdGVz Ojxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgb8KgIEhOQ1AgdW5pY2Fz dCB0cmFmZmljIFNIT1VMRCBiZSBzZWN1cmVkIHVzaW5nIERUTFMgW1JGQzYzNDddIGFzPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGVzY3JpYmVkIGluIEROQ1AgaWYgZXhj aGFuZ2VkIG92ZXIgdW5zZWN1cmVkIGxpbmtzLsKgIFVEUCBvbiBwb3J0PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSE5DUC1EVExTLVBPUlQgaXMgdXNlZCBmb3IgdGhpcyBw dXJwb3NlLsKgIEEgbm9kZSBpbXBsZW1lbnRpbmcgSE5DUDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHNlY3VyaXR5IE1VU1Qgc3VwcG9ydCB0aGUgRE5DUCBQcmUtU2hhcmVk IEtleSBtZXRob2QsIFNIT1VMRDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHN1cHBvcnQgdGhlIEROQ1AgQ2VydGlmaWNhdGUgQmFzZWQgVHJ1c3QgQ29uc2Vuc3VzIGFuZCBN QVkgc3VwcG9ydDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBQS0kt YmFzZWQgdHJ1c3QgbWV0aG9kLjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5v dGUgdGhlICZxdW90O1NIT1VMRCZxdW90OyBhbmQgdGhlIGNvbmRpdG9uYWxzICZxdW90O3Vuc2Vj dXJlZCBsaW5rcyZxdW90OyAobm90IHN1cmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3 aGF0IHRoaXMgd291bGQgYmUsIHByZWNpc2VseSkuIEkgZG8gbm90IGtub3cgYW55dGhpbmcgbWVh bmluZ2Z1bCBhYm91dDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIERUTFMsIGJ1dCBJIHdv dWxkIGltYWdpbmUgdGhhdCBza2luZyB0aGUgU0VDLURJUiBmb2xrcyBhYm91dCBpdHMgdXNlPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd291bGQgbWFrZSBzZW5zZS48YnI+DQo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBBbGwgdGhhdCBzYWlkLi4uc2FkbHksIGluIG1hbnkgY29u ZGl0aW9ucyBhbmQgc2NlbmFyaW9zICZxdW90O2dldHRpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBzZWN1cml0eSB0byB3b3JrIGlzIGhhcmQmcXVvdDsgYW5kIGluIGEgaG9tZSBzY2Vu YXJpbyB0aGUgY2hvaWNlICh0byBtaW5pbWl6ZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHRoZSBhbW91bnQgb2Ygc3VwcG9ydCBjYWxscywgLi4uKSBpdCB3b3VsZCBub3QgYmUgaGFyZCB0 byBpbWFnaW5lIGVpdGhlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHR1cm5pbmcgT0ZG IG9yIHVzaW5nIGxvd2VzdC1jb21tb24tZGVub21pbmF0b3Igc2VjdXJpdHkuPGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU2F5ICZxdW90O25vdGhpbmcmcXVvdDsgb3ZlciBhbiBF dGhlcm5ldCAmcXVvdDtiZWNhdXNlIHBoeXNpY2FsIGFjY2VzcyByZXF1aXJlZCZxdW90OywgYW5k PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV0VQIGZvciBXaUZpICh5ZXMsIHBlb3BsZSBz dGlsbCBkbyB0aGF0KSBhbmQgdGhlbiBkZWNsYXJlIGxpbmtzICZxdW90O25vdDxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHVuc2VjdXJlZCZxdW90OyBhbmQgdGhlcmZvcmUgY29uc2lkZXIg aXQgbGVnaXRpbWF0ZSB0byBub3QgaW1wbGVtZW50IHRoZSBTSE9VTEQuPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgRWZmZWN0aXZlbHksIHdoYXQgSSBmZWFyIGhlcmUgaXMgdGhh dCBpZiBITkNQICZxdW90O3Byb3Bvc2VzIHRvIHNoYXJlIFBTS3MmcXVvdDs8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB0aGVuIGEgKHNsaWdodGx5IG5haXZlKSBwcm9jZXNzIG1pZ2h0IGFj dHVhbGx5IHRydXN0IHRob3NlIFBTS3MgdG8gYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB1c2VmdWwgZm9yIHNlY3VyaXR5IC0tIHdoaWNoLCBpbiBmYWN0LCB0aGV5IGFyZSBub3Qgc2lu Y2UgdGhleSBjYW4gYmU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBleHBvc2VkIGJ5IHNp bXBsZSBlYXZlc2Ryb3BwaW5nPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkm IzM5O2QgcmVhbGx5IGxpa2UgYSBidWxsZXQtcHJvb2YgZ3VhcmFudGVlIHRoYXQgYW55IHNoYXJl ZCBQU0tzIGNhbiYjMzk7dCBoYXZlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYmVlbiAo ZWFzaWx5KSBlYXZlc2Ryb3BwZWQgb24gLS0gb3IsIHdvdWxkIHJhdGVociB0aGF0IEhOQ1AgZG9l cyBub3Q8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0ZW1wdCB0aGUgdXNlIG9mIGNvbXBy b21pemVkIFBTS3MuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgbyBTZWN0aW9uIDEwPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgV2hhdCYjMzk7cyB0aGUgc29sdXRpb24gaWYgdGhlIG1lc3Nh Z2UgZm9ybWF0IGNoYW5nZXM/IEZvciBleGFtcGxlLCB0aGF0IHRoZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHR5cGUgZmllbGQgbmVlZHMgdG8gZ3Jvdy9zaHJpbms/PGJyPg0KPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSYjMzk7dmUgbWVudGlvbmVkIHRoaXMgaW4gbXkgRE5D UCByZXZpZXcsIGJ1dCBJIHN0cm9uZ2x5IGJlbGlldmUgdGhhdCBpdCBpczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHJlcXVpcmVkIHRvIGhhdmUgdmVyc2lvbmluZyBhbHNvIGNhcHR1cmUg JnF1b3Q7dGhlIGZyYW1lIGZvcm1hdCZxdW90OywgYW5kIG5vdDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIGp1c3QgdGhlICZxdW90O3BheWxvYWQmcXVvdDsuPGJyPg0KPGJyPg0KPGJyPg0K TWlub3IgSXNzdWVzOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoEdlbmVyYWwg Y29tbWVudHM6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg b8KgIMKgIMKgIMKgSSByZWNvbW1lbmQgdXNpbmcgJnF1b3Q7bm9uLXplcm8mcXVvdDsgd2hlbiBy ZWZlcnJpbmcgdG8gbnVtZXJpY2FsIHZhbHVlcyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhbmQgbm90ICZxdW90O25vbi1udWxsJnF1b3Q7PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgQWJzdHJhY3Q8YnI+DQo8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBRdWVzdGlvbnM6IGlzIGl0IGNsZWFyIHdoYXQgJnF1b3Q7bmFt aW5nJnF1b3Q7IHJlZmVycmVzIHRvPyBJcyBpdCAmcXVvdDtuYW1lIHJlc29sdXRpb24mcXVvdDs/ PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSWRlbSBmb3IgJnF1b3Q7 bmV0d29yayBib3JkZXJzJnF1b3Q7LCBkbyB5b3UgY29uZmlndXJlIHRob3NlLCBvciBkaXNjb3Zl ciB0aG9zZT88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSb3V0aW5nLXNwZWNp ZmljIHF1ZXN0aW9uIGhlcmU6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgV2hhdCBkb2VzICZxdW90O3NlYW1sZXNzIHVzZSBvZiBhIHJvdXRpbmcgcHJvdG9jb2wmcXVv dDsgbWVhbj8gVGhhdCBhbnkgSVA8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCByb3V0aW5nIHByb3RvY29sIGNhbiBiZSB1c2VkIHVubW9kaWZpZWQ/IEkgKnRoaW5rKiB0 aGF0IHRoYXQmIzM5O3Mgbm90PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgdGhlIGNhc2UsIGdpdmVuIHRoYXQgdGhlIHVzZS1jYXNlIHRoYXQgaXMgb2Z0ZW4gdHJvdHRl ZCBmb3IgaG9tZW5ldDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlu Y2x1ZGVzIGEgbXVsdGktaG9tZWQgaG9tZSAtIGFuZCB0aGUgaW50cm9kdWN0aW9uIHNheXMgYXMg bXVjaCBzbzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRoZSBhYnN0 cmFjdCBwcm9iYWJseSBzaG91bGQgcmVmbGVjdCB0aGF0Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIEhvdyBhYm91dCBzb21laHRpbmcgbGlrZSB0aGlzIGZvciB0aGUgYWJzdHJh Y3Q6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7 VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIEhvbWUgTmV0d29ya2luZyBDb250cm9sIFByb3Rv Y29sPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKEhOQ1ApLCBhbiBl eHRlbnNpYmxlIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgYW5kIGEgc2V0IG9mIHJlcXVpcmVtZW50 cyBmb3IgaG9tZSBuZXR3b3JrIGRldmljZXMuIEhOQ1AgaXMgZGVzY3JpYmVkIGFzIGE8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwcm9maWxlIG9mIGFuZCBleHRlbnNp b24gdG8gdGhlIERpc3RyaWJ1dGVkIE5vZGUgQ29uc2Vuc3VzIFByb3RvY29sIChETkNQKS7CoCBI TkNQIGVuYWJsZXMgYXV0b21hdGVkIGNvbmZpZ3VyYXRpb24gb2YgYWRkcmVzc2VzLCBuYW1lPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVzb2x1dGlvbiwgZGlzY292 ZXJ5IG9mIG5ldHdvcmsgYm9yZGVycywgYW5kIHRoZSB1c2Ugb2YgYW55PGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgc3JjLWRlc3Qtcm91dGluZyBjYXBhYmxlIHJvdXRp bmcgcHJvdG9jb2wuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgSW50cm9kdWN0 aW9uPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7SE5DUCBz eW5jaHJvbml6ZXMgc3RhdGUgYWNyb3NzIGEgc21hbGwgc2l0ZSBpbiBvcmRlciB0byBhbGxvdy4u LiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdoYXQgcHJlY2lzZWx5 IGlzIGEgJnF1b3Q7c21hbGwgc2l0ZSZxdW90Oz8gQ2FuIHdlIHF1YWxpZnkgdGhhdCBpbiB0ZXJt cyBvZiwgc2F5LDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIG51bWJlciBvZiByb3V0ZXJz Pzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O1Ro ZSBwcm90b2NvbCBlbmFibGVzIHVzZSBvZiBib3JkZXIgZGlzY292ZXJ5JnF1b3Q7PGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSBhbSBub3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFu ZCB3aGF0IHRoaXMgbWVhbnMgLS0gaW4gd2hpY2ggd2F5IGlzPGJyPg0KwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgYm9yZGVyIGRpc2NvdmVyeSAqZW5hYmxlZCo/IE9yLCBkbyB5b3UgbWVhbiAmcXVv dDtUaGlzIHByb3RvY29sIGRpc2NvdmVyczxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGJv cmRlcnMmcXVvdDs/IE9yIHNvbWV0aGluZyBlbHNlPzxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O25hbWluZyBhbmQgb3RoZXIgc2VydmljZXMgYWNy b3NzIG11bHRpcGxlIGxpbmtzLiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFNvLCB0aGUgZmlyc3QgcGFyYWdyYXBoIHRlYWNoZXMgbWUgdGhhdCBITkNQIGlzIGFwcGxp Y2FibGUgc29tZXdoZXJlIG5vdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRvbyBiaWcg LS0gYnV0LCBvZiBjb3Vyc2UswqAgSSBkbyBub3Qga25vdyB3aGF0IGV4YWN0bHkgdGhhdCBpcyAt LSAsIGFuZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGl0IGRvZXMgJnF1b3Q7c29tZSBz dHVmZiwgYW5kIG90aGVyIHNlcnZpY2VzJnF1b3Q7IC0tIGJ1dCwgb2YgY291cnNlLMKgIEkgZG8g bm90PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAga25vdyB3aGF0IHRob3NlIGFyZSwgb3Ig aG93IHRoZXkgYXJlIGNoYXJhY3Rlcml6ZWQuIFRoYXQmIzM5O3MgYSBsaXR0bGU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBpbXByZWNpc2UgZm9yIGFuIGludHJvZHVjdGlvbi48YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdWdnZXN0IGJlaW5nIGV4dHJlbWVseSBwcmVj aXNlLiBTb21ldGhpbmcgbGlrZTo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBITkNQICZxdW90O1N5bmNocm9uaXplcyBzdGF0ZSZxdW90OyBieSB3YXkgb2YgW2RuY3Bd LCBhbmQgc3BlY2lmaWVzIGFuZCB1c2VzPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgc3RhdGUgZm9yIHByb3ZpZGluZyB0aGUgZm9sbG93aW5nIG5ldHdvcmsgc2Vydmlj ZXM6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg b8KgIMKgIMKgIMKgRk9PPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgQkFSPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgRk9PQkFSPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQWxsIHNwZWNpZmllZCBpbiB0aGlzIGRv Y3VtZW50LiBBZGRpdGlvbmFsbHksIEhOQ1AgZW5hYmxlcyBvdGhlcjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHNlcnZpY2VzLCBjaGFyYWN0ZXJpemVkIGJ5IF9fX19f XywgZm9yIGV4YW1wbGUgcHJlZml4IGFzc2lnbm1lbnQgYXM8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBkZWZpbmVkIGJ5IFtJLUQuaWV0Zi1ob21lbmV0LXByZWZpeC1h c3NpZ25tZW50XTxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdoaWNoIGJyaW5n cyBtZSB0byBhIHF1ZXN0aW9uLiBUaGUgYWJzdHJhY3QsIGFuZCBpbnRyb2R1Y3Rpb24sIHN0YXRl PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCBITkNQICZxdW90O2VuYWJsZXMgYXV0 b21hdGVkIGNvbmZpZ3VyYXRpb24gb2YgYWRkcmVzc2VzJnF1b3Q7IC0tIGhvdyBpcyB0aGF0PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGlmZmVyZW50IGZyb20gW0ktRC5pZXRmLWhvbWVu ZXQtcHJlZml4LWFzc2lnbm1lbnRdPyBPciwgaXMgdGhlIGFuc3dlcjxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZxdW90O2l0IGlzbiYjMzk7dCwgdGhhdCBJLUQgaXMgcmVxdWlyZWQgdG8g ZG8gdGhhdCZxdW90OywgaW4gd2hpY2ggY2FzZSB3aGF0IGRvZXMgaXQ8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBtZWFuIHRoYXQgSE5DUCAmcXVvdDtlbmFibGVzJnF1b3Q7IGl0Pzxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtPZiBjb3Vyc2UsIHJlYWRpbmcgdGhlIGRv Y3VtZW50IGl0IGJlY29tZXMgY2xlYXIgdGhhdCBITkNQIGRvZXMgdGhpczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGJ5IHdheSBvZiBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gW0ktRC5p ZXRmLWhvbWVuZXQtcHJlZml4LWFzc2lnbm1lbnRdLDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGJ1dCB0aGUgYWJzdHJhY3QgYW5kIGludHJvZHVjdGlvbiByZWFsbHkgYXJlIHVuZm9ydHVu YXRlbHkgcGhyYXNlZF08YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZWFkaW5n IGp1c3QgdGhlIGludHJvZHVjdGlvbiwgSSYjMzk7ZCBsaWtlIHRvIGJlIGFibGUgdG8ga25vdyB3 aGF0IEhOQ1A8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3b3VsZCBicmluZyBtZSwgZXhh Y3RseT8gSW1wbGVtZW50aW5nIGFuZCB0dXJuaW5nIG9uIEhOQ1Agd291bGQgZG8gd2hhdDxicj4N CsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHRvIG15IG5ldHdvcms/PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgb8KgIMKgIMKgIMKgMy4gRE5DUCBQcm9maWxlPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7SE5DUCBpcyBkZWZpbmVkIGFzIGEgcHJvZmls ZSBvZiBETkNQLi4uJnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSXMg aXQgbm90IG1vcmUgY29ycmVjdGx5IHRvIHNheSB0aGF0JnF1b3Q7PGJyPg0KPGJyPg0KwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7SE5DUCBpcyBhIHByb2ZpbGUgZm9y IEROQ1AuLi4mcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA/PGJyPg0K PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7SE5DUCByb3V0 ZXJzIE1VU1QgYXNzaWduIGEgdW5pcXVlIDMyLWJpdCBlbmRwb2ludCBpZGVudGlmaWVyIHRvPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBlYWNoIGludGVyZmFjZSBm b3Igd2hpY2ggSE5DUCBpcyBlbmFibGVkLiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIEFueSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0byB0aGF0IGlkZW50aWZpZXI/ IFJlYWRpbmcgaW50byBETkNQLCB0aGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaXMg YWN0dWFsbHkgbm90IGVudGlyZWx5IGNsZWFyIHRoZXJlLiBJICp0aGluayogdGhhdCB0aGUgZW5k cG9pbnQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpZGVudGlmaWVyIE1VU1QgYmUgdW5p cXVlIHRvIHRoZSBsb2NhbCBub2RlLCBidXQgdGhhdCB0aGVyZSYjMzk7cyBubzxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHJlcXVpcmVtZW50IGJleW9uZCB0aGF0IC0tIGNvcnJlY3Q/PGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQ291bGQgdGhhdCBiZSBjYWxsZWQgb3V0IGJvdGgg aW4gdGhpcyBkb2N1bWVudCwgYW5kIHBlcmhhcHMgaW4gRE5DUCBtb3JlPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgY2xlYXJseT88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBGb2xsb3dpbmcgdGhlIGFib3ZlOjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICZxdW90O1RoZSB2YWx1ZSB6ZXJvIGlzIHJlc2VydmVkIGZvciBpbnRlcm5h bCBwdXJwb3Nlcy4mcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBXaGF0 IGludGVybmFsIHB1cnBvc2VzIHdvdWxkIHRoYXQgYmU/IFJlYWRpbmcgdGhyb3VnaCwgaGlkZGVu IGluIHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGRlc2NyaXB0aW9uIG9mIHRoZSBm cmFtZSBmb3JtYXQgKDYuMi4yKSBJIHJlYWQ6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7VGhlIGVuZHBvaW50IGlkZW50aWZpZXIgb2YgdGhlIGxv Y2FsIGludGVyZmFjZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgdGhhdCBi ZWxvbmdzIHRvIHRoZSBDb21tb24gTGluayB0aGUgcHJlZml4IGlzIGFzc2lnbmVkIHRvLCBvciAw IGlmPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0aGUgQ29tbW9uIExpbmsg aXMgYSBQcml2YXRlIExpbmsgKGUuZy4sIHdoZW4gdGhlIHByZWZpeCBpczxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXNzaWduZWQgZm9yIGRvd25zdHJlYW0gcHJlZml4IGRl bGVnYXRpb24pLiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE9LLCBz byBsZWF2aW5nIHRoYXQgc2xpZ2h0bHkgb2RkIHBocmFzaW5nIChhbmQgdGhlIG5vdGlvbiBvZiAm cXVvdDtDb21tb248YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBMaW5rJnF1b3Q7IGFuZCAm cXVvdDtQcml2YXRlIExpbmsmcXVvdDsgLS0gYm90aCBvZiB3aGljaCB3ZSB3aWxsIGNvbWUgYmFj ayB0bykgZm9yIGE8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsYXRlciBjb21tZW50LCBj YW4gd2Ugbm90IGJyaW5nIHRoaXMgdXAgdG8gc2VjdGlvbiAzLCB0aHVzOjxicj4NCjxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O0hOQ1Agcm91dGVy cyBNVVNUIGFzc2lnbiBhIDMyLWJpdCBlbmRwb2ludCBpZGVudGlmaWVyLCB1bmlxdWUgdG88YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHRoZSBsb2NhbCBub2RlLCB0 byBlYWNoIGludGVyZmFjZSBmb3Igd2hpY2ggSE5DUCBpcyBlbmFibGVkLiBUaGU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHZhbHVlIHplcm8gTVVTVCBOT1QgYmUg dXNlZCwgZXhjZXB0IGFzIGVuZHBvaW50IGlkZW50aWZpZXIgZm9yIGFuPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbnRlcmZhY2UgdG93YXJkcyBhIFByaXZhdGUg Q29tbW9uIExpbmsmcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA/PGJy Pg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW2J1dCwgSSBhbSBubyBncmVhdCBmYW4g b2YgJnF1b3Q7UHJpdmF0ZSBMaW5rJnF1b3Q7IG9yICZxdW90O0NvbW1vbiBMaW5rJnF1b3Q7LCBz ZWUgb3RoZXIgY29tbWVudHNdPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQWJv dXQgdGhpczo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtS ZWNlaXZlZCBkYXRhZ3JhbXMgd2l0aCBhbiBJUHY2IHNvdXJjZSBvciBkZXN0aW5hdGlvbiBhZGRy ZXNzIHdoaWNoPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpcyBu b3QgbGluay1sb2NhbCBzY29wZWQmcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBIb3cgYWJvdXQ6PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg JnF1b3Q7UmVjZWl2ZWQgZGF0YWdyYW1zIHdoZXJlIGVpdGhlciBvciBib3RoIG9mIHRoZSBJUHY2 IHNvdXJjZSBvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZGVz dGluYXRpb24gYWRkcmVzc8KgIGlzIG5vdCBsaW5rLWxvY2FsIHNjb3BlZCZxdW90Ozxicj4NCjxi cj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgID88YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBBcyBhIGdlbmVyYWwgY29tbWVudCwgdGhpcyBzZWN0aW9uIGNvbnRhaW5zIGFuIHVu b3JkZXJlZCBzZXQgb2YgYnVsbGV0cyw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aGVy ZSBhIGdyb3VwaW5nIGFuZCBzb21lIGNvbW1vbiBkaXNjdXNzaW9uIHByb2JhYmx5IHdvdWxkIG1h a2Ugc2Vuc2UuPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRm9yIGV4YW1wbGUsIGEgZmV3 IGNvbmNlcm4gc2VjdXJpdHkgZGlyZWN0bHkgKGUuZy4sIDMgJmFtcDsgNSkgYnV0IGFyZSBub3Q8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCByZWFsbHkgRE5DUCBwYXJhbWV0cml6YXRpb25z IC0tIHdoZXJlYXMgb3RoZXJzIGFyZSAoZS5nLiwgNiwgNywgOCkuPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgVGhlIGJ1bGxldC1zZXQgcmVhZHMgc29tZXdoYXQgbGlrZSAmcXVvdDt0aGUg a2l0Y2hlbiBzaW5rJnF1b3Q7Ljxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIChOdW1iZXJz IGluZGljYXRlIGNvdW50IGZyb20gdGhlIGZpcnN0IGJ1bGxldCBpbiB0aGUgYmxvY2spLjxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoDUuwqAgQm9yZGVyIERpc2NvdmVyeTxicj4N Cjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZSBkb2N1bWVudCByZWFkczo8YnI+DQrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtBIHJvdXRlciBNVVNUIGFs bG93IHNldHRpbmcgYSBjYXRlZ29yeSBvZiBlaXRoZXIgYXV0by1kZXRlY3RlZCw8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGludGVybmFsIG9yIGV4dGVybmFsIGZvciBlYWNo IGludGVyZmFjZSB3aGljaCBpcyBzdWl0YWJsZSBmb3IgYm90aDxicj4NCsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgaW50ZXJuYWwgYW5kIGV4dGVybmFsIGNvbm5lY3Rpb25zLsKgIElu IGFkZGl0aW9uIHRoZSBmb2xsb3dpbmc8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHNwZWNpYWxpemF0aW9ucyBvZiB0aGUgaW50ZXJuYWwgY2F0ZWdvcnkgYXJlIGRlZmluZWQg dG8gbW9kaWZ5IHRoZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbG9jYWwg cm91dGVyIGJlaGF2aW9yOiZxdW90Ozxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IFdoYXQgZGVmaW5lcyBpZiBhbiBpbnRlcmZhY2UgaXMgJnF1b3Q7c3VpdGFibGUmcXVvdDsgZm9y IGFuIGV4dGVybmFsLCBvciBpbnRlcm5hbCw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBv ciBib3RoLCBjb25uZWN0aW9ucz8gV2hhdCBkb2VzICZxdW90O2Nvbm5lY3Rpb25zJnF1b3Q7IG1l YW4gaW4gdGhpcyBjb250ZXh0PyBXaGF0PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcmVx dWlyZW1lbnRzIGFyZSB0aGVyZSBmb3IgYW4gaW50ZXJmYWNlIHRvIGJlICZxdW90O3N1aXRhYmxl JnF1b3Q7IHJlc3BlY3RpdmVseTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O3Vu c3VpdGFibGUmcXVvdDs/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQXMgcGFy dCBvZiB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgZGlmZmVyZW50IGNhdGVnb3JpZXMsIHNvbWUgYXJl IGRlY2xhcmVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgYXMgU0hPVUxELCBvdGhlcnMg YXMgT1BUSU9OQUwuIEkgZG8gbm90IHNlZSBhbnkgd2hpY2ggYXJlIE1VU1QuIEkgc2VlPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdGhhdCB0aGUgdHdvIFNIT1VMRCBzaG91bGQgYmUgTVVT VDxicj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEFsc286PGJyPg0KPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSHlicmlkIGNhdGVnb3J5OsKg IFRoaXMgZGVjbGFyZXMgYW4gaW50ZXJmYWNlIHRvIGJlIGludGVybmFsIHdoaWxlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgc3RpbGwgcnVubmluZyBESENQdjQgYW5kIERIQ1B2Ni1QRCBj bGllbnRzIG9uIGl0LsKgIEl0IGlzIGFzc3VtZWQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCB0aGF0 IHRoZSBsaW5rIGlzIHVuZGVyIGNvbnRyb2wgb2YgYSBsZWdhY3ksIHRydXN0d29ydGh5IG5vbi1I TkNQPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcm91dGVyLCBzdGlsbCB3aXRoaW4gdGhl IHNhbWUgbmV0d29yay7CoCBEZXRlY3Rpb24gb2YgdGhpcyBjYXRlZ29yeTxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGF1dG9tYXRpY2FsbHkgaW4gYWRkaXRpb24gdG8gbWFudWFsIGNvbmZp Z3VyYXRpb24gaXMgb3V0IG9mIHNjb3BlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgb2Yg dGhpcyBkb2N1bWVudC7CoCBTdXBwb3J0IGZvciB0aGlzIGNhdGVnb3J5IGlzIE9QVElPTkFMLjxi cj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdoYXQgbWFrZXMgYSByb3V0ZXIgJnF1 b3Q7bGVnYWN5JnF1b3Q7PyBXaGF0IG1ha2VzIGl0ICZxdW90O3RydXN0d29ydGh5JnF1b3Q7Pzxi cj4NCjxicj4NCjxicj4NCsKgIMKgIMKgIMKgIG/CoCDCoCDCoCDCoEluIHNlY3Rpb24gNi4xLjIg SSBzZWU6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1 b3Q7TmVzdGVkIFRMVnM6wqAgT3RoZXIgVExWcyBpbmNsdWRlZCBpbiB0aGUgRGVsZWdhdGVkIFBy ZWZpeCBUTFYgYW5kPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBz dGFydGluZyBhdCB0aGUgbmV4dCAzMi1iaXQgYm91bmRhcnkgZm9sbG93aW5nIHRoZSBlbmQgb2Yg dGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBlbmNvZGVkIHBy ZWZpeDomcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCAmcXVvdDtQcmVmaXg6wqAgwqBTaWduaWZpY2FudCBiaXRzIG9mIHRoZSBwcmVmaXggcGFkZGVk IHdpdGggemVyb2VzIHVwIHRvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgdGhlIG5leHQgYnl0ZSBib3VuZGFyeS4mcXVvdDs8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBRdWVzdGlvbjo8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBPdGhlciB0aGFuICZxdW90O2JlY2F1c2UgaGlzdG9yaWNhbGx5IHRoYXQmIzM5O3MgaG93 IHdlIGRpZCB0aGluZ3MsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg YmVjYXVzZSwgYXQgdGhlIHRpbWUsIHRoYXQgd2FzIGEgZ29vZCBpZGVhJnF1b3Q7LCBpcyB0aGVy ZSBhbnkgZ29vZDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlYXNv biB0aGF0IHlvdSYjMzk7cmUgaW5zaXN0aW5nIG9uIGJ5dGUvMzItYml0IGFsaWdubWVudHMgaGVy ZT8gSXQmIzM5O3M8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiZWVu IGEgZ29vZCB3aGlsZSBzaW5jZSBJJiMzOTt2ZSBwZXJzb25hbGx5IHdyaXR0ZW4gY29kZSB3aGVy ZSAzMiBiaXQgYWxpZ25tZW50IHdhcyBhIG1ham9yIGNvbmNlcm4gLS0gYnV0LCB3aGVuIGdlbmVy YXRpbmcgYSBwYWNrZXQgSTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHN1cmUgY291bGQgc2VlIGl0IGFzIGEgbWlub3IgbnVpc2FuY2UgdG8gZG8gdGhlIGFsaWdubWVu dC48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTbywgSSBhY3R1YWxs eSBzZWUgdGhpcyBhcyAmcXVvdDthIG51aXNhbmNlIGludHJvZHVjZWQgaW4gcGFja2V0PGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZ2VuZXJhdGlvbiwgZm9yIG5vIHJl YWwgZ2FpbiBpbiBwYXJzaW5nJnF1b3Q7Ljxicj4NCjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIChOb3RlIHRoYXQgdGhpcyBpcyBpbiB0aGUgTUlOT1IgY2F0ZWdvcnks IHRob3VnaCk8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCBvwqAgwqAgwqAgwqA2LjIuMzo8YnI+DQo8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVvdDtJbiBhbnkgY2Fz ZSwgYSByb3V0ZXIgTVVTVCBzdXBwb3J0IGEgbWVjaGFuaXNtIHN1aXRhYmxlIHRvPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkaXN0cmlidXRlIGFkZHJlc3NlcyBm cm9tIHRoZSBjb25zaWRlcmVkIHByZWZpeCBpZiB0aGUgbGluayBpczxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaW50ZW5kZWQgdG8gYmUgdXNlZCBieSBjbGllbnRz LsKgIEluIHRoaXMgY2FzZSBhIHJvdXRlciBhc3NpZ25pbmcgYW48YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoElQdjQgcHJlZml4IE1VU1Qgc3VwcG9ydCB0aGUgTC1j YXBhYmlsaXR5IGFuZCBhIHJvdXRlciBhc3NpZ25pbmcgYW48YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoElQdjYgcHJlZml4IE1VU1Qgc3VwcG9ydCBzZXJ2aW5nIHJv dXRlciBhZHZlcnRpc2VtZW50cy7CoCBJbjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgYWRkaXRpb24gaWYgYW4gYXNzaWduZWQgSVB2NiBwcmVmaXggaXMgbm90IHN1 aXRhYmxlIGZvciBTdGF0ZWxlc3M8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24gdGhlIHJvdXRlciBNVVNUIGFsc28gc3Vw cG9ydCB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEgtY2Fw YWJpbGl0eSBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMTAuPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgVG8geW91ciBjcmVkaXQsIHlvdSBwdXQgYSBmb3J3YXJkIHBvaW50ZXIgdG8g U2VjdGlvbiAxMC4gV2l0aCB0aGF0IGJlaW5nIHNhaWQsIHdvdWxkIGl0IG5vdCBiZSBtb3JlIGxv Z2ljYWwgdG8gZGlzY3VzcyB0aGF0ICh3aGljaCBhcHBlYXJzIGFzICZxdW90O3RoZSBvdmVyYWxs IG1lc3NhZ2UgZm9ybWF0IG9mIEhOQ1AmcXVvdDspIHNvbWV3aGVyZSBlYXJsaWVyPzxicj4NCjxi cj4NCjxicj4NCjxicj4NCk5pdHM6PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKg QW55IHJlYXNvbiB3aHkgc29tZSBUTFYgdHlwZXMgYXJlIHdyaXR0ZW4gaW4gQUxMLUNBUFMgd2hl cmVhcyBvdGhlcnMgaW48YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBIeXBoZW5hdGVkLUNh bWVsLUNhc2U/PGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgb8KgIMKgIMKgIMKgSSBzYXcgYSBmZXcg JnF1b3Q7ZS5nLiZxdW90OyBhbmQgJnF1b3Q7aS5lLiZxdW90Oywgd2hpY2ggSSBiZWxpZXZlIHRo ZSBzdHlsZSBndWlkZTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHByZXNjcmliZXMgc2hv dWxkIGJlICZxdW90O2kuZS4sJnF1b3Q7IGFuZCAmcXVvdDtlLmcuLCZxdW90Oy4gWWVhaCwgdGhl IFJGQyBFZGl0b3Igd2lsbDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGNhdGNoIHRoaXMg dWx0aW1hdGVseSwgYnV0IGlmIHlvdSByZS1zcGluIHRoZSBkb2N1bWVudCB0aGVuIG1pZ2h0IGFz PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgd2VsbCBtYWtlIHRoZWlyIGxpZmUganVzdCBh IGJpdCBlYXNpZXIgOyk8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K --001a11c1d8d6067612051b639b63-- From nobody Wed Jul 22 05:56:20 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EE91A89B0; Tue, 21 Jul 2015 08:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 ZXtQstYQaqAg; Tue, 21 Jul 2015 08:23:48 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 244661B2FA3; Tue, 21 Jul 2015 08:21:59 -0700 (PDT) Received: from [31.133.179.67] (dhcp-b343.meeting.ietf.org [31.133.179.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t6LFLoam008006 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2015 08:21:52 -0700 To: Jamal Hadi Salim , Erik Nordmark References: <559AB820.9000309@acm.org> From: Erik Nordmark Message-ID: <55AE638E.3000302@acm.org> Date: Tue, 21 Jul 2015 17:21:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZU9aOH1UdqbUYtp8AofoIKORAMkOX7Q6R8qCJFJi7pR0ffdhZo0r+8dZ9wGOVmsz0W3RSONY1d2oFHPkH9i+je X-Sonic-ID: C;ZvrSNbwv5RGAgIM848vClw== M;XAOhNrwv5RGAgIM848vClw== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 05:56:11 -0700 Cc: draft-rtg-dt-encap , "rtg-dir@ietf.org" , "rtgwg@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-rtg-dt-encap-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:23:49 -0000 On 7/13/15 1:52 PM, Jamal Hadi Salim wrote: > Erik, > Sorry for the latency - this got buried because i wasnt on the cc so > my filters > gave it low prio. > > > On Mon, Jul 6, 2015 at 1:17 PM, Erik Nordmark > wrote: > > On 6/30/15 2:20 PM, Jamal Hadi Salim wrote: > > > [..] > > The design team tried to stay away from potentially contentions > discussion by putting firm recommendations in place. Thus > currently the document is more of "things to think about" and some > tradeoffs, and less of recommendations (and no requirements). > > Alia has asked for more of a list of choices for the protocol > designers, and this is definitely something which folks can help > with as we continue this work in the RTGWG. But I also think we > need to let the specific in-flight WGs (NVO3, SFC, and BIER) use > this document as input but figure out their own tradeoffs and answers. > > > Generally the message was as you described. > I probably should have used the term "guidelines" instead of > "recommendations". > I was looking for guidelines and i sometimes didnt grok them. > I liked some of the format in section 18. It provides context ("Here's > what a NIC does for TSO") > and then provides guidelines ("optional protocol fields should not > contain values that must > be updated on a per segment basis .."). I realize that this specific > example is > closer to implementation details - which may change (or get obsolete) > over time but it serves > as a good example of what i was trying to say. > I also realize this may be hard to keep consistent across the document > - so take it as input > of where it may make sense to use such formatting. I just realized the subject line saying draft-rtg-dt-encap-02. We did add some bullets at the end of most sections in draft-ietf-rtgwg-dt-encap-00. I don't know if those help, but hopefully they can serve as a prompt for getting even more concrete guidelines. > > > > Many Internet protocols use fixed values (typically > managed by the > IANA function) for their next-protocol field. That > facilitates > interpretation of packets by middleboxes and e.g., for > debugging > purposes, but might make the protocol evolution > inflexible. Our > collective experience with MPLS shows an alternative where > the label > can be viewed as an index to a table containing processing > instructions and the table content can be managed in > different ways. > Would it not be useful to provide a reference here? Just > reading this > has questions popping for me - who populates this tag-indexed > table of > instructions and could interop be impacted? > > The DT added the above text based on comments at the mike from > Stewart Bryant. I don't know if there is any reference for the > general concept. Anybody else know? > > In general this implies some control-plane mechanism to populate > the table. > > > Maybe an addendum to describe that the control-plane or some human > would administer > this would be useful. Let me ask for volunteers to craft some text tomorrow. > > Is there a reference to work which says quiet periods (which i > am implicitly > reading that in the text above) can be used to change the hash > selection? > I would think that one needs to closely observe packet trends > to make > such a decision. So please provide some ref to some scholarly or > engineering work. > > I don't know of citations to such work; perhaps my co-authors have > some. > I recall reading about using markers, but that was a long time ago. > > It would help i think to have some reference. I am not sure if this > applies: > http://simula.stanford.edu/~alizade/papers/conga-sigcomm14.pdf > Let me have a look. Thanks again, Erik > > cheers, > jamal From nobody Tue Jul 28 08:45:38 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3C41ACCFE; Tue, 28 Jul 2015 08:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_LOW=-0.7, 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 vosMNam60wcI; Tue, 28 Jul 2015 08:45:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6451A88D9; Tue, 28 Jul 2015 08:45:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 80217253724; Tue, 28 Jul 2015 08:45:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E0935253721; Tue, 28 Jul 2015 08:45:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8AE078D4-BFBF-494A-B1CE-D41254A36386" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Thomas Clausen In-Reply-To: <55857123.90205@openwrt.org> Date: Tue, 28 Jul 2015 17:45:17 +0200 Message-Id: <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> References: <55857123.90205@openwrt.org> To: Steven Barth X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" , "homenet@ietf.org Group" , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 15:45:36 -0000 --Apple-Mail=_8AE078D4-BFBF-494A-B1CE-D41254A36386 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Steven, all, [I am looping RTG-DIR and RTG-ADs back in on this, just so that they do = not feel that we do not love them any more =E2=80=A6 ;) ] > On Jun 20, 2015, at 15:56, Steven Barth wrote: >=20 > Hello Thomas, >=20 > thanks a lot for your elaborate review, we have just pushed revision = -06 And I see that you have pushed ore than that in the month-or-so since my = review. Thank you for that.=20 I will state outright that I am taking this email as an excuse for = =E2=80=9Cgoing back and looking at -08=E2=80=9D, in part as I go = through the new I-D, and commenting as I go along. I still think that = there may be reason to spin a -09, so I will hold back making the = =E2=80=9Cofficial RTG-DIR follow-up review=E2=80=9D until that=E2=80=99s = either done, or I am convinced otherwise ;) But, guys, thanks for your efforts in both updating the doc and = rebutting my comments. And congratulations on having produced something = which =E2=80=94 for the most part =E2=80=94 is *almost* there, and = where it=E2=80=99s going to be easy to push it over the finishing line, = I think. Highlights of what I still think is needed (with details below, of = course) from this document: o A handful or so of =E2=80=9Calmost there, why don=E2=80=99= t we add a sentence on =E2=80=A6=E2=80=9D that should be really easy to do, and should make me shut up on a great = number of topics. o An applicability statement [sorry, I=E2=80=99m insisting = here, I feel this is important] o Workable definition of =E2=80=9CEndpoint=E2=80=9D in = terminology o Still need versioning [sorry, I=E2=80=99m insisting = here, I feel this is important] As I said, details below =E2=80=94 but good job getting from -05 to -08, = and thanks to you both for having taken time to address and answer to my = review in so painstaking detail, both in the draft, and in this = exchange. Authors, for all the points where I have said =E2=80=9Cfine=E2=80=9D, if = you reply to this mail feel free to cut those points out and retain only = outstanding issues. > of DNCP addressing your issues and comments and that of other = reviewers. >=20 > Please see more detailed comments inline. >=20 >=20 > Cheers, >=20 > Steven & Markus >=20 >=20 >=20 > On 16.06.2015 17:45, Thomas Clausen wrote: >> Comments: >>=20 >> o Is there any good reason why the authors have no listed = affiliation? > As we are independent consultants, an affiliation would probably not = be > much more useful than our names themselves. OK, was just wondering if it was xml2rfc acting up. >=20 >> =09 >> o It is somewhat contradictory that the abstract talks = about >> "...describes a protocol" and then later "...leaves some = details >> to be specified in profiles, which define actual = implementable DNCP >> based protocols" >> =09 >> Does that not mean, then, that this document specifies = an algorithm, >> a framework, and not a protocol? > This was debated publicly and tbh. we are not sure what the correct > phrase would be, maybe =E2=80=9Cabstract protocol=E2=80=9D, but even = that was not liked > by everyone. Other than that we tried to clear up the introduction and > abstract in that regard. OK; on a personal-preferences level, the separation between HNCP and = DNCP seems artificial, and it probably is part of the reason why this is = hard to describe. I probably would not have made that separation myself = =E2=80=94 but I am not suggesting that the WG goes back on that decision = (just to be clear), rather that it be called out. I can live with what is there. >> o On that, I see "DNCP protocol" several places. Expanded, = that becomes >> "Dynamic Network Configuration Protocol Protocol" ... > Fixed, found only one. (long form is wrong btw.) >=20 I expected so ;) >> =09 >> o In general, and despite actually knowing some of the = core algorithms >> somewhat before this review, I found the document really = tough to >> read, with convoluted sentences, inconsistent = requirements-language, >> and a lack of introductory "here's the 1000ft view of = the protocol, >> what it does, how it works, and under which conditions = it works". >> =09 >> o On that, I do not find the chosen structure of the = document to be >> optimal for conveying an unambiguous protocol = specification. For one, >> the same concepts are occasionally described slightly = differently. >> For another, it is often hard to find the information = needed to >> parse a specific mandated processing (for example). I = provide an >> example of what I would suggest a better structure in = the below. >> =09 >> The goal is to provide first concepts and an overview, = followed by a >> single, easy to identify place for "precise and = unambiguous definitions >> of concepts", and then use those in the detailed = expression of the >> protocol. Note that this is just an example, of course: >> =09 >> Section "Terminology:" >> The Network State Hash is a hash value = which represents the >> current state of the network, as known = by a node. >> =09 >> Section "Protocol Overview and Functioning" >> =09 >> When receiving a FOO TLV, the DNCP node = compares the received >> Network State Hash with its own Network = State Hash. This >> represents the consistency check rom = RFC6206. If same, >> then...if not, then .... >> =09 >> Section "Protocol Information Bases" >> For the purpose of this specification, = the Protocol >> Information Bases are orgnaized as sets = of tuples ... any >> implementation can chose = whatever representation it wants. >> =09 >> The Network State Information = Base in a DNCP node is a set >> of tuples: >> (x, y, z, w) >> =09 >> where x is ..., y is ..., z is = ..., and w is ... >> =09 >> Section "How to calculate the Network State = Hash": >> =09 >> The network State Hash is calculated = using the information >> from the Network State Information = Base, as follows: >> =09 >> 1. First, the tuples in = that information base are sorted >> in ascending order = based on .... >> =09 >> 2. Second, .... = (concatenation) >> =09 >> 3. Third, the hash = function from is used >> =09 >> 4. Fourth, the first n = bits of the resulting hash value, >> are retained, witn n = being from . >>=20 >> And then, in remaining sections simply reference = the Network >> State Hash, which is now ubiquitously defined in = a single place. >> =09 >> I am taking this example, since when reading = section 5.3 I found >> myself chasing through the document, finding = multiple slightly >> different definitions of "Network State Hash" -- = but beyond this >> example, it generally does apply to the document = as a whole, and >> certainly to all of the processing and = generation considerations in >> section 5. >>=20 > We reorganised the document a bit, wrote a better abstract and > introduction and provided a =E2=80=9CProtocol Overview=E2=80=9D = section, on top of that > we reorganised the details in an =E2=80=9COperations=E2=80=9D section. OK; I am a good deal more happy now, although not perfectly happy just = yet.=20 I still think that it would be fantastic to have an applicability = statement included. Reading the document without any context [as it = might down the line if it was to become an RFC], it=E2=80=99s hard to = understand if =E2=80=9Chey, I have a problem, is DNCP the right lump of = metal to use to make a hammer for it?=E2=80=9D As I said in my original review, I think that this is a matter of = scoping the work right. The abstract, and the into, calls out =E2=80=9Ca = generic state synchronization protocol=E2=80=9D =E2=80=94 I=E2=80=99ve = heard OSPF described as such, also (hi Fred!) =E2=80=94 which sounds = very much like =E2=80=9Cboiling the ocean=E2=80=9D, and which I think = the WG is not trying to actually do. Why don=E2=80=99t you put a subsection before the last paragraph of the = Introduction =E2=80=9CApplicability=E2=80=9D and then expand on that? I just want to note that I enjoyed the expanded terminology - thank you! = There may be a small formatting snafu, at least in the HTML version, = about missing blank lines between (for example) =E2=80=9CAddress=E2=80=9D = and =E2=80=9CEndpoint=E2=80=9D Going back and looking at that, does it make sense to talk about =E2=80=9C= DNCP network=E2=80=9D, out in the real world, or just in this document? An HNCP network and a TNCP network (that=E2=80=99d be for "Thomas' Neat = Configuration Protocol=E2=80=9D) sure, and such two could co-exist (but = not interoperate) so while they =E2=80=9Cin the abstract=E2=80=9D would = both be instances of DNCP networks, that=E2=80=99d be an abstract = construction altogether. Could I suggest that to the definition of =E2=80=9CDNCP network=E2=80=9D = some verbiage to that effect be added? Now we=E2=80=99re at tightening up on terminology, I am finding myself = wondering about =E2=80=9CDNCP profile=E2=80=9D and =E2=80=9CDNCP-based = protocol=E2=80=9D as terms, just a little. A DNCP profile is=20 a definition of the set of rules and values defining the behavior of a fully specified, implementable protocol which uses DNCP. The DNCP profile specifies transport method to be used, which optional parts of the DNCP specification are required by that particular protocol, and various parameters and optional behaviors. In this document any parameter that a DNCP profile specifies is prefixed with DNCP_. Contents of a DNCP profile are specified in Section 9. Could we be a little bit more succinct: =E2=80=9CA DNCP profile consists of: o The values for the set of parameters, = given in section 9. o The set of optional parts of this = specification, which are to be used.=E2=80=9D For DNCP-based protocol, the doc says: A DNCP-based protocol is: a protocol which provides a DNCP profile, and potentially much more, e.g., protocol-specific = TLVs and guidance on how they should be used. Could we be more precise (than =E2=80=9Cpotentially much more=E2=80=9D) = on =E2=80=9CDNCP-based profile=E2=80=9D =E2=80=9CA DNCP-based protocol is: o A DNCP profile, according to Section 9, o Zero or more TLV assignments from the = registries set up by this specification o generation and processing rules for = these TLVs ? On the definition of =E2=80=9CAddress=E2=80=9D: o What does it mean to be =E2=80=9Crelatively transport = agnostic=E2=80=9D? I=E2=80=99d=20 say that it=E2=80=99s a little bit like being = =E2=80=9Crelatively pregnant=E2=80=9D =E2=80=94 either you are, or you = are not? o Why not define an =E2=80=9CAddress=E2=80=9D as = (IPv6-address, Transport, Port)? (and then, if someone comes along with something that = doesn=E2=80=99t fit that tuple form down the line, deal with it then?) Address, by the way, uses =E2=80=9Cendpoint=E2=80=9D which is defined = below.=20 Endpoint, then, ends up being defined almost as an =E2=80=9Caddress=E2=80=9D= *except* that there=E2=80=99s the clause =E2=80=9Cmay be bound to a set = of predefined unicast addresses=E2=80=9D [would those be addresses as = previously defined?] When I read =E2=80=9CEndpoint=E2=80=9D I end up simply thinking = =E2=80=9CSocket, expressed as (IPv6-address, Transport, Port)=E2=80=9D = but as that was defined above it can=E2=80=99t be it?=20 Could you clear that up, please? [Note, it=E2=80=99s better than the = -05, but still confusing] >> o As a general comment, the document would do well with a = good editorial >> overhaul to bring consistency in language usage, = consistency in 2119 >> terminology, coherence in defined terms and their = definition, document >> structure, etc. >=20 > We did another editing round with focus on normative language. Much better, thanks. I=E2=80=99ll holler if I see something to fix on = this front >=20 >=20 >> =09 >> Major Issues: >> =09 >> o The introduction does not read well; it contains parts = of something that >> could be considered as part of an applicability = statement (without it >> being called out as such, and without forming a complete = applicability >> statement), and does not actually introduce the = protocol. Reading just >> the introduction and the abstract, it is very obscure if >> this is a framework, a protocol, a building block, an = architecture, an >> algorithm -- and, if either of those, what it is = actually accomplishing, >> and why one would chose to use DNCP. It does, however, = transpire that >> "whatever it is", it has two "modes" and that it = requires something >> (presumably a routing protocol) to provide each "node" = with a topology >> map. >> =09 >> Suggest that a proper introduction consisting of three = parts would be >> beneficial: (i) what this document is, (ii) what doing = DNCP actually >> gets you, and (iii) the operating conditions under which = the >> DNCP is applicable. >> =09 >> On the latter point, given that you state that DNCP = requires profiles >> to provide "actual implementable DNCP based protocols", = it appears >> important to understand what the limits for "what a = profile can give >> you" are. >> =09 >> I am calling this out as a major issue, since I believe = that it is >> not just editorial, but is a matter of scoping this = document correctly, >> and in particular not falling into the trap of "claiming = applicability >> where it's not". >=20 > As noted earlier, the introduction has been reworded and separated = from > protocol overview also considering your suggestions. So this is good, thank you for doing that effort =E2=80=94 it=E2=80=99s = tedious, but it helped. To section 3, therefore, a few suggestions: 1) Throw an initial paragraph in stating what DNCP does = =E2=80=9Cstate synchronization=E2=80=9D and all that. 2) =E2=80=9CDNCP discovers the topology of its nodes and = =E2=80=A6=E2=80=9D Argh=E2=80=A6almost there =E2=80=9Cits nodes=E2=80=9D? - would that be =E2=80=9Cthe nodes in the = DNCP network=E2=80=9D (which has been defined=E2=80=A6)? - you=E2=80=99re discovering the topology = (i.e., you actually produce a topology graph?) or just the presence or absence of nodes = in the network (i.e., a destination list)? Just state what you do, and it=E2=80=99ll be good. 3) =E2=80=9Cbidirectionally reachable=E2=80=9D =E2=80=94 = call out if that means =E2=80=9Cover one IP hop=E2=80=9D (as in =E2=80=9Co= n the same link=E2=80=9D) or if it can be =E2=80=9Cbidirectionally reachable, = possibly through a multi-hop path=E2=80=9D Actually, why don=E2=80=99t you define that term in the = terminology section, since it appears also in section 4, and it=E2=80=99d make me go away with this = comment in more places than one ;) 4) =E2=80=9CA hash tree is maintained by each node=E2=80=9D = =E2=80=94 I=E2=80=99ve thought about that, and I think that you may want to expand a little more. =E2=80=9CA hash tree, = rooted in itself, is maintained by each node=E2=80=9D? 5) And then, again, the text is almost there, bit just need = a nudge=E2=80=A6how is the tree constructed? You start fine =E2=80=9Ca node starts with a hash tree = only consisting of itself=E2=80=9D. Then it announces that, and gets updates. How are those = =E2=80=9Cintegrated=E2=80=9D into the receiving nodes=E2=80=99 hash tree.=20 Yes I know how it=E2=80=99d work out (I may be dense, = but not *that* dense ;) ), but I think that it=E2=80=99d be=20 easy to capture all here and being complete, since = it=E2=80=99s so close. By the way, I would state that the hash tree is height 1 in this = section, and add a forward reference to 4.1. Overall, I really like section 3. It might be a good litmus test to ask someone with no previous = understanding of Trickle to give it a read-through and explain it back = to you, though, just to be sure. But I really like section 3. Thank you. Section 4, I really like what you have done with it also. As a purely = subjective matter, could there between 4 and 4.1 be some educational = text that describes how the 6 subsections to 4 =E2=80=9Cfit together=E2=80= =9D? As it is right now, it=E2=80=99s a little abrupt. >> o The document, in my understanding, defines an exchange = format with >> limited ability to evolve, as simply "a steam of TLVs". >>=20 >> As long as there's never a need to evolve the TLV format = itself, and >> as long as you do not run out of TLV types, that's not = going to be >> a problem. The doc sets aside a 16bit TLV type space, = that's reasonable >> enough, but I worry if eventually a DNCPv2 will need to = evolve the >> format. One purely hypothetical example could be if a = "sequence number" >> would be needed in each DNCP message to detect "link = success rates", or >> something of that sort. >=20 > I think on this front we have to agree to disagree; as it is a stream = of > _unrelated_ TLVs with some rare exceptions (node endpoint ID =3D> = network > state), a later spec such as DNCPv2 can specify if it wants to that > every DNCP 'message' contains TLV of type $FOO and uses disjoint set = of > TLVs to do X. Hell, we do that in HNCP already. >=20 OK, then, in that case what you call a TLV is what I would call a = =E2=80=9CMessage=E2=80=9D =E2=80=94 fair enough, I can do that mental = substitution. Now=E2=80=A6that still doesn=E2=80=99t change the fact that you may end = up having to evolve your Message format =E2=80=94 I=E2=80=99m sorry, = your TLV format =E2=80=94 as it appears on the wire, as well as some of = the behaviors that you exhibit through DNCP processing. For that, you=E2=80=99ll need a version number. And again, I am sorry, I = cannot come up with a concrete example and =E2=80=94 again =E2=80=94 = that=E2=80=99s part of the dilemma: a future extension that we have not = thought about is, by definition, a future extension that we have not = thought about and so therefore we can=E2=80=99t predict if it will be = interoperable with a what we have now. >=20 >> =09 >> I do not have an actual example in mind -- and that's = exactly the point: >> to be evolutive for the unknown future and (at the very = least) be able >> to discriminate between "old" and "new". >> =09 >> A discussion could be had if a "version number" in each = TLV would do, >> or if a concept of "protocol message with a version = number" is >> preferential. I do not believe, however, that "no = version number" is >> viable. >=20 > Since DNCP is an abstract protocol, a concrete protocol on top of it > might probably want to do versioning for its own purposes (i.e. > different versions on top of the same DNCP version). In this case = having > versioning in both DNCP and the derived protocol serves little = purpose. > HNCP - as first derived protocol - defines a Version-TLV btw. >=20 Yes but that is a =E2=80=9Cversion TLV=E2=80=9D =E2=80=94 what happens = if the TLV format itself, or some of the DNCP specific processing. This, incidentally, goes to the crux of why I =E2=80=94 personally =E2=80=94= would not have done the split. Had DNCP *exclusively* been an = algorithm, or such, then I could see not needing a version in DNCP, but = in the DNCP-based protocol (HNCP) only. Or, for that matter, had DNCP = been just a frame format with no processing, or something, then I could = see one sequence number sufficing. By DNCP being part-signals-part-procesing-part-behavior-part-framework, = which cannot exist on its own but which requires =E2=80=9Canother = protocol which profiles it and which also defines its own signals, = processing, and behavior=E2=80=9D, yes, you actually having this = =E2=80=9Cversion number conundrum=E2=80=9D. You could not fix all this by having a DNCP version number only, but = having a sufficiently large TLV type space? That way, you=E2=80=99d not = need (say) HNCP version numbers, but a HNCPv2 would use TLV types A, B = and D (but not C) from HNCPv1, and would reserve and define TLV types X, = Y, Z ? >>=20 >> o Noting that the "overhearing n reduncant transmissions" = is a key >> retransmission suppression mechanism in Trickle, and = that this >> seems to assume broad/multicast, using unicast seems to = contradict >> the statement of "consists of Trickle", at least in the = way the >> algorithm is defined in RFC6206. Note: it's fine to use = an algorithm >> outside of its initial scope, but it should be with the = caveat of >> "which of the characteristics still hold, and which do = not" > If k < 2, even on point-to-point link, Trickle does reap benefits and > provides exponential backoff timer. Obviously, we can spell this out > more explicitly if it helps. >=20 YES, that sort of explanation would be good. >>=20 >> o DNCP claims to be trickle based, yet supports unicast. = It also >> (apparently) is a request/reply protocol. It doesn't = have messages. >> This document needs a good, and pedagogical, "protocol = overview and >> functioning" section somewhere: one needs to get through = the end of >> Section 5 before having even a vague idea of how DNCP = works. > Protocol overview added. Perfect, as I said, I like what you did in section 3. =09 >> o The use of normative language is not as tight as could = be desired. >> For example, a number of SHOULDs seem to really ought to = be "MAYs" since >> not following the SHOULD won't break the algorithm. It = would be good >> to walk through the document and take a careful look at = these to >> either MUST/MAY the SHOULDs, or to qualify the SHOULDs = remaining. >> =09 > Reworked. That seems to have helped a great deal. >> o I am going to go out on a limb here, and say that "the = protocol is >> underspecified". That's a deliberately provocative = statement, but it >> was honestly how I felt upon having completed the = review. >> =09 >> The document does not help the reader get an intuitive = understanding >> of the protocol functioning, but jumps right into minute = details -- >> requiring the reader to "build up her or his own model = of how DNCP >> works". On having read the document a few times, I think = that I >> understand it -- but there's nothing permitting me to = verify my >> understanding, and thereby I'd not feel confident to be = able to >> provide an interoperable and independent implementation. = I've given >> some comments in the "Comments" section as to what I = think would be >> viable ways to improve this point. >>=20 > Addressed. Indeed you did. It seems a LOT better, and I appreciate your efforts = here. As I said, I am trying to respond to those issues that seem to be = outstanding in this email; I=E2=80=99ll go through the document once = more in all its nitpicking detail once we=E2=80=99ve resolved those few = issues that I think are still pending. >=20 >> o Section 5.3, penultimate paragraph: >> =09 >> "If keep-alives specified in Section 6.1 are NOT = sent by the peer >> (either the DNCP profile does not specify the use = of keep-alives or >> the particular peer chooses not to send = keep-alives), some other >> means MUST be employed to ensure its presence. = When the peer is no >> longer present, the Neighbor TLV and the local DNCP = peer state MUST >> be removed." >> =09 >> "...some other means MUST be employed to ensure its = presence." -- >> followed by more MUST verage when a peer disappears...I = am not sure that >> that's conductive to interoperable implementations. >> =09 >> Two implementatons may chose different "means" and then = turn off keep- >> alives - and be non-interoperable. >> =09 >> For interoperability, we need: >> =09 >> o A mandatory to implement = mechanism, that always is >> present, but can be complemented = by another "means", or >> =09 >> o A mandatory to implement = mechanism, which by way of a >> specified negotiation mechanism = can be turned off between >> two peers, to allow them to use = another "means". >> =09 >> If you argument is "...this will be specified in the = profile", then >> you still should provide the two above in this document, = with the note >> that "...and a profile may specify which from among = these MUST be >> used in a given deployment" >=20 > Clarified that =E2=80=9Cother means=E2=80=9D, refers to existing = transport-provided > mechanism, e.g. Ethernet carrier-detection, TCP keep-alives etc. Alright, good. Now where is it specified which is to be used? Is that = part of the profile, or should it be? If so, call that out here. I=E2=80=99m trying to avoid interoperability issues, for example if I am = using =E2=80=9CTCP keep-alives=E2=80=9D and you are using something = else, can we work together? If this is not a problem, call that out as = something which a device can do as it sees fit (although, for example. = TCP keep-alives presumably expects TCP which is a profile matter =E2=80=A6= ) I *think* that we are almost there also with this point, so convince me = that the text there won=E2=80=99t cause interoperability issues? Hiving = it off to a profile to specify would do just that (of course, I=E2=80=99d = come back on that in HNCP, instead ;) ). >=20 >>=20 >> o Section 8: >> Interesting; I am not a security expert, but I am very = curious to >> see the SEC-DIR review of this document. That said, = section 8.3.1 >> contains normative verbage: >> =09 >> "A node MUST be trusted for participating in the = DNCP network if and >> only if..." >> =09 >> Which I think needs a qualifier of the "If the = certificate based >> trust model is used, then a node must be trusted for = ...." >> =09 >> Same goes for the subsequent SHOULD - it really reads = as-if this >> certificate based mechanism initially was intended as = MTI, but then >> was backed away from subsequently without a complete = cleanup of the >> text? >=20 > It was never intended to be MTI, the intention was that nodes not > participating in the mechanism would ignore the whole section (and > normative language), that is now explicitly stated in normative = language > in the beginning. OK, this is not a comment, then, for the authors to action, but for the = WG chairs: I would strongly recommend that you reach out to the SEC ADs = to understand what their expectations are to this. Speaking from not-so-ancient-experiences, the SEC-ADs have become more = =E2=80=9Cstrict=E2=80=9D with what they let through, and what might have = passed a year ago would not fly today.=20 I am NOT a security expert, though, but as they say, a burnt child ... >> =09 >> I do actually question the value of having a = laundry-list of trust >> management methods, and for one of those (certs) a = laundry-list >> of all sorts of trust relationship establishment = methods, in this >> document; this in no small part as the lists are = explicitly indicated >> as "non-exhaustive" and that none are listed as = "mandatory to >> implement". Was any thought given to factoring this into = a seperate >> document, and focusing in this document on one, = mandatory-to-implement, >> security mechanism? >=20 > This set is a 'useful base set' that e.g. HNCP requires. While I agree > it is not exhaustive, as the original goal was just to split DNCP and > HNCP, I consider it a success. Not sure that I agree, but I think I will fold this into =E2=80=9Cdiscuss = with SEC-ADs=E2=80=9D since that=E2=80=99s for the most part not in my = scope of competencies. >> Minor Issues: >>=20 >> Introduction: >> o 1st paragraph: "reachable nodes"; two things: >> =09 >> - I always have a problem with the = term "node"; it is often >> used as a shorthand for "routers = and hosts, both". I was >> given to understand that homenet = specifically did not want >> to consider host changes? > DNCP is not strictly speaking about homenet (but a strict requirement > for HNCP which is). Also even in homenet-case non-routers may join the > network temporarily in order to e.g. do monitoring. But, would those =E2=80=9Cnon-routers=E2=80=9D not speak at least part = of the =E2=80=9Chome net specific protocols=E2=80=9D and thereby not be = =E2=80=9Chosts=E2=80=9D in the =E2=80=9Cgot them from Best Buy and just = clicked OK=E2=80=9D sort of sense?=20 So is the crux that we have =E2=80=9Chomenet-aware devices=E2=80=9D and = =E2=80=9Clegacy hosts=E2=80=9D, and that either of us just need to get = with the program? If so, can I insist (gently) on =E2=80=9Chomenet-aware = devices=E2=80=9D [with a suitable definition] instead of =E2=80=9Cnodes=E2= =80=9D since =E2=80=9Cnodes=E2=80=9D are such an overloaded term that = it=E2=80=99s not even fun any more. >> =09 >> - "Reachable" - does that mean = something as in "radio range", >> does it mean "on the same link", = does it mean within a >> specific (DNCP?) domain, or does = it mean simply "on the >> Internet somewhere"? >=20 > Clarified in the text as =E2=80=9Cbidirectionally reachable=E2=80=9D, = also added > fwd-references to actual definition. Suggest also defining in Terminology, and clarifying if this is a = one-hop, or a multi-hop-within-the-homenet, concept. In section 1, I do = not see a forward reference, btw, at least not in latest rev. >=20 >> =09 >> o 2nd paragraph: "nodes that are currently = accounted for": >> - What does that mean? >> =09 >> - Also, the conclusion "Therefore = unlike Time-To-Live (TTL) =09 >> based solutions, it does not = require periodic re-publishing >> of the data by the nodes" does = actually not follow from >> the previous sentence in that = paragraph. >>=20 >> - I actually do not think that the = introduction describes >> what DNCP does, and so the = comparison to TTL-based >> solutions is rather hard to get = here. > Fixed.=09 Indeed it is. >=20 >> =09 >> - Continuing: >> =09 >> "On the other hand, it = does require the topology >> to be visible to every = node that wants to be able to >> identify unreachable = nodes and therefore remove old, >> stale data." >> =09 >> This reads a lot more like an = applicability statement than >> an introduction; the take-away = when reading this is: >> =09 >> "Each node must have = something that maintains >> a topology map of the = entire network, such as >> a (LS) routing = protocol, for DNCP to function" >> =09 >> Is that actually the intent = here? >> =09 > Clarified, it was intended to be read as DNCP itself providing that > topology. >=20 OK. >=20 >> - "DNCP is most suitable for data = that changes only gradually" >> How is the reader to interpret = "gradually"? Do you mean >> "infrequently", or do you really = mean "gradualy"? > Clarified. >=20 OK >=20 >> =09 >> o Last paragraph: >> "DNCP has relatively few requirements = for the underlying >> transport; it requires some way of = transmitting either unicast >> datagram or stream data to a peer" >> =09 >> This is a bit of a forward comment, but we now = have "nodes >> that are accounted for" and "peers". I see = neither defined in >> the terminology section. >> =09 >> "and, if used in multicast mode, a way = of >> sending multicast datagrams." >> =09 >> This is the first mention of two "modes" of this = protocol. This >> loops back to an earlier comment, that the = introduction actually >> does not introduce the protocol, but rather is = an incomplete >> applicability statement. > Fixed and moved to more appropriate sections. >=20 And, it reads much better now. Thank you. >=20 >> =09 >> "If security is desired and one of the >> built-in security methods is to be = used, support for some >> TLS-derived transport scheme - such as = TLS [RFC5246] on top of >> TCP or DTLS [RFC6347] on top of UDP - is = also required." >>=20 >> I am not pretending to be a security expert, but = "some >> TLS-derived...such as ... on top of TCP or = DTLS..." (i) does not >> sound like it could lead to interoperable = implementations, and (ii) >> does not sound sufficiently tight as a MTI = security mechanism to >> pass security reviews. Again, I am no security = expert, but perhaps >> getting one looped in early would be advicable? > Clarified that profile MUST define details. >=20 Also good, thank you. >> =09 >> Terminology: >> o Suggest adding "In this document ..." somewhere = to this text: >>=20 >> "For readability, any DNCP profile = specific >> parameters with a profile-specific = fixed value are >> prefixed with DNCP_." > Fixed. Thanks >=20 >> =09 >> o DNCP network: I read this twice, and came away = with two different >> understandings, perhaps you can clarify which it = is: >>=20 >> o A set of nodes running DNCP, = within the same domain, and >> for which a path betwen any two = DNCP nodes includes only >> other DNCP nodes; i.e., a DNCP = network forms a connected >> component with only other DNCP = nodes. >> =09 >> o A set of nodes running DNCP. = They may be anywhere on the >> Internet, they are part of the = same DNCP network as long >> as they (through other means) = have learned of each others >> addresses. >> =09 >> In the former, that'd be (for example) a = deployment within my >> home -- in the latter, it could be a node in my = home and a node in >> your home forming a DNCP network. >> =09 >> The text is not quite clear on this point. > Both are valid use cases; hopefully clarified. >=20 OK, sadly you clarified it ;) Well, no, not sadly, but you clarified it = to be understandable to me in the above sense. But, if I come up with = the aforementioned TNCP and I use the same transport as HNCP, would a = TNCP and a HNCP node be on the same DNCP network, then? >> =09 >> o Link: a point of clarification here. In "DNCP = network", there was >> talk about "unidirectional links" and = "bidirectional links"; in >> "Link" the definition is somewhat vague = "directly connected" and >> "can communicate". Could something like "without = decrementing TTL/ >> hop-count" be added, and could a statement on = bidirectionality >> (IOW, that this is just an IP link) be added? > This isn=E2=80=99t IP specific as such; however, some better = definition is > welcome. some types of IP links are not strictly bidirectional either > (hello, mesh).=09 Hi, you rang? ;) Actually =E2=80=9Csome mesh protocols=E2=80=9D do go through the = exercise of verifying bidirectionally before even considering them as = useful for whatever the protocol tries to do. What I am trying to get at, though, is not this discussion but rather: = what does this Link present to the IP layer, in terms of properties? >> =09 >> o "Interface" is overloading the term "port" (IP = port) which can be >> confusing > Done (stole definition from some RFC that is =E2=80=98port free=E2=80=99= ) It=E2=80=99s, indeed, a very good idea to steal a good idea. =09 >> o "Endpoint" - The definition "locally configured = use of DNCP" is not >> clear -- are you really not talking about a DNCP = process? >> =09 >> I am not sure that it is clear how a DNCP = process can be "attached >> to ... a specific remote unicast address, or to = a range of unicast >> addresses that are allowed to contact" >>=20 >> I can see how a DNCP process can be configured = to allow connections >> from a specific range of addresses, or can be = configured to connect >> to a specific remote unicast address. Is that = what you mean instead? >> =09 > Clarified, endpoint most likely resembles network socket, i.e. bound = to > interface or connected to certain remote address etc. >=20 OK, I addressed that earlier in my comments. >=20 >> =09 >> o "Peer" - states that two peers "communicate = directly". For link, >> the definition is "directly connected nodes can = communicate". >> Would it then not be easier to say "a DNCP node = on the same link >> as ..." ? >> =09 > It is not. Removed directly if it helps. Ah, so now it is just =E2=80=9Csomeone out there in the network with = whom I communicate=E2=80=9D - fine, it=E2=80=99s clear. >=20 >> o "Node state" >> "The hash function and the number of = bits used are defined >> in the DNCP profile." >> =09 >> Suggest: >> "The hash function and the length of the = hash value are defined >> in the DNCP profile." >> =09 > Done. Thanks. >> =09 >> o "Network state hash" - same comment as for node = state (above) >=20 > Done. Thanks. >> =09 >> Data model: >> o "Latest update sequence number" >> This may just be my personal taste, but does it = hurt to mandate >> a specific way of doing the looping comparison? = The reason I >> suggest this is, that it's one of those things = where creativity >> in an implementation seems to simply be an = invitation for bugs, >> and for little gain >> =09 > Done. Thanks >=20 >> o "Relative time delta" >> Document talks about "a 32 bit number on the = wire" -- does that >> mean that wireless links are excluded? > I thought this was an expression, but guess not, replaced with > =E2=80=98transmitted as=E2=80=99 (both here + fragment stuff) I=E2=80=99ve spent a good chunk of my career =E2=80=9Coff the wire=E2=80=9D= so I=E2=80=99m perhaps specially sensitive to that. Thanks for catering = to my special sensitivities ;) >=20 >=20 >> =09 >> o Related to terminology, there seems to be some = fuzzyness around >> node and endpoint. For example, in data model = one of the things that >> a DNCP node may have is: >>=20 >> "Unicast address: the DNCP node it = should connect with" >> =09 >> Does that mean *any* DNCP process (i.e., *any* = endpoint) at that >> address, or a *specific* DNCP process at that = address? >> =09 >> The same, but inverse, for "Range of addresses: = the DNCP nodes that >> are allowed to connect" - is this "any DHCP = process (i.e., *any* >> endpoint) on any of these addresses? >> =09 >> Following, the same section reads: >>=20 >> "For each remote (peer, endpoint) pair = detected on a local >> endpoint, a DNCP node has..." >> =09 >> the following text indicating that there's some = sort of distinction >> between which endpoint. >> =09 >> This whole thing needs some clarification. > I think there was a general misconception about the term endpoint, = which > is hopefully cleared up in the latest revision. >=20 Hm, it was cleared somewhat, but there are still murky areas; see = previous comment. I am still confused after having read through the = relevant bits again, but I am confused in a different way now, than I = was last time. That may be an improvement after all. I think the crux is = the distinction between =E2=80=9CAddress=E2=80=9D and =E2=80=9CEndpoint=E2= =80=9D in the terminology, and once that is settled the rest will likely = fall into place. > =09 >> =09 >> Operation >> =09 >> o First a generic comment that Trickle itself has = some operating >> conditions which scopes its applicability, and = it would behove >> this document to, in its own applicability = statement, call out >> those. > Added some comments regarding applicability. Better, but I would like to see that reflected also in a dedicated = applicability statement. >> =09 >> o On the same token, while the use of Trickle in = an unicast fashion >> is possible, I wonder if (in general) unicast = use is advicable. I >> appreciate that some links are point-to-point = and so a broadcast >> across it becomes an unicast -- but, does that = necessitate being >> called out? >> =09 >> IF the reason for this "because we can use TCP", = then be explicit >> about this - but, also, that you're then not = exactly using Trickle >> where and how it was intended. I wonder if you = could be explicit >> as to what consequences this "alternate use of = Trickle" have? It >> seems that the use of unicast is directly = contradicting the main >> operating consideration of Trickle? >=20 > In general DNCP is transport agnostic, therefore calling out a = specific > transport such as TCP is a bit debatable. RFC 6206 seems to be all = about > picking right values at least; they DO NOT say it is multicast or > broadcast only, only that it communicates with 1 address. that's what = we > do, it's just the other endpoint. >=20 OK, fair enough argument. >> =09 >> o 2nd paragraph states: >> =09 >> "the multicast transport does not have = to be particularly >> secure" >> =09 >> What is the definition of "not have to be = particularly secure"? >> Is cleartext OK? Authentication? Encryption? >> Should I do something more? >> =09 > Clarified: =E2=80=98.. does not have to be secured.=E2=80=99 Thanks. >=20 >> 5.1 Trickle-driven status updates >> o First paragraph: >> =09 >> "Multicast MUST be employed on a = multicast-capable interface; >> otherwise, unicast can be used as well" >> =09 >> If the interface is not multicast-capable, then = unicast can be >> used as well as what? Certainly not multicast, = since the interface >> is not multicast capable...? >> =09 > All fixed. Yup, it is. >=20 >> o Continuing: >> =09 >> "If possible, most recent," >> =09 >> What would make it "not possible"? >> =09 >> "recently changed, or best of all, all = known Node State TLVs" >> =09 >> OK, so assuming that for some reason (MTU = limitation) it is not >> possible, does the above represent an order that = I MUST respect, >> or is it "take a pick from among these, = according to your whim of >> the day"? >>=20 >> "(Section 7.2.3) SHOULD be also = included," >> =09 >> SHOULD is a strong statement, especially when = prefixed by >> "if possible". That, essentially, renders it a = MAY. >> =09 >> "unless it is defined as undesirable for = some reason >> by the DNCP profile >> =09 >> Now it DEFINITELY is a MAY since apparently a = profile can state >> that these TLVs MUST NOT be included -- and, I = assume, since the >> document permits it to do so, it is possible = without breaking the >> algorithm. > Degraded to MAY; while it improves convergence speed, it is not worth > being too specific about it. And that=E2=80=99s exactly what I like to see MAYs used for, so = fantastic, thanks. >=20 >> =09 >> o And, continuing again: >> =09 >> "If the >> DNCP profile supports dense broadcast = link optimization >> (Section 6.2), and if a node does not = have the highest node >> identifier on a link, the endpoint may = be in a unicast mode in >> which multicast traffic is only = listened to. In that mode, >> multicast updates MUST NOT be sent." >>=20 >> Really hard to parse. Is that not equivalent to = saying: >> =09 >> "If a DNCP endpoint is not configured to = be in multicast >> mode, then it MUST NOT send multicast = updates" >> =09 >> ? >> =09 >> If it is, then say that -- if it is not, then a = rewrite is needed, >> as that's what I manage to extract from the = text. > Hopefully clarified now, about when multicast/unicast is used. yep, I think it is. =09 >> 5.2. Processing of Received TLVs >> o First paragraph reads: >> =09 >> "The DNCP profile may specify criteria = based on which particular >> TLVs are ignored." >> =09 >> Criteria for what? Do you perhaps mean: >> =09 >> "The DNCP profile may specify which TLVs = to process, and >> which to ignore"? >> =09 >> Auxiliary question, then, and related to my = penultimate comment >> to 5.1, are there any constraints on that, any = risks from ignoring >> (or not) specific TLVs to the operation of the = network? > Added some text to the profile section and reference. >=20 Yup, good. >=20 >> =09 >> o I am also confused by the 3rd sentence in the = first paragraph: >> =09 >> "Any =E2=80=99reply=E2=80=99 mentioned = in the steps below denotes sending of >> the specified TLV(s) via unicast to the = originator of the TLV >> being processed." >> =09 >> This confusion is likely due to the lack of a = "protocol overview >> and functioning" description [either as its own = section, or as part >> of the introduction]. >> =09 >> I know how trickle works. Trickle is a = distributed consistency >> algorithm. When an inconsistency is detected, = then an action is >> triggered that rectifies that inconsistency. = DNCP claims to be trickle based, but apparently also a sort of = request/reply >> mechanism. Combined with = trickle-over-unicast-links, I am not sure >> what the protocol logic actually is. Reading = through to the end of >> Section 5, I think that I understand the idea, = but I am not sure. >> =09 >> And the old "when in doubt, look at the state = machines" didn't help >> either, there aren't any. >> =09 >> The point to this comment is, that the document = immediately jumps >> into the details -- but forgets to give the = "10000ft view" of the >> protocol functioning. > Added protocol overview and made connection between trickle, merkle = tree > and requests more clear. >=20 Indeed, and =E2=80=9Cmerkle trees=E2=80=9D disappeared and became hash = trees somewhere along the line ;) >=20 >> =09 >> o First paragraph states two SHOULD. Would those = not be MUST? What >> breaks if not respecting those criteria? > Done. tnx >=20 >> =09 >> o 2nd paragraph, a "valid address", that = definition is rather unclear. >> I understand that that's something specified in = "the profile", but >> what is the relationship to the different = addresses discussed in >> the data model section? >> =09 >> It is not clear what the parenthesis to this = paragraph means, >> but that is probably again a case of the "use = case" and "protocol >> overview" not being documented - the document so = far has nowhere >> described interaction with outside processes. > Text changed. Ok, I can live with that. >=20 >> =09 >> o First bullet, but generally through these, and = other, bullets: >> =09 >> I had a really hard time deciphering this. = First: >> =09 >> "The receiver MUST reply >> with a Network State TLV (Section 7.2.2) and a = Node State TLV >> (Section 7.2.3) for each node data used to = calculate the >> network state hash" >> =09 >> Alright, off to find "network state hash". >> =09 >> The terminology tells me that it is: >> =09 >> "a hash value which represents the current state = of >> the network. The hash function and the = number of >> bits used are defined in the DNCP profile. >> Whenever a node is added, removed or updates its >> published node data this hash value changes as >> well. It is calculated over each reachable nodes' >> update number concatenated with the hash value of >> its node data. For calculation these tuples are >> sorted in ascending order of the respective node's >> node identifier. >>=20 >> Searching further, I find Section 5.1, but that = simply states: >> =09 >> "The Trickle state for all endpoints is >> considered inconsistent and reset if and = only if the locally >> calculated network state hash changes." >>=20 >> Next occurence is in these bullets, and then = just before Section 6, >> =09 >> "During >> the grace period, the nodes that were not = marked reachable >> in the most recent graph traversal MUST NOT = be used for >> calculation of the network state hash, be = provided to any >> applications that need to use the whole TLV = graph, or be >> provided to remote nodes." >> =09 >> Alright, now I know what I can't use for = calculating it. >> =09 >> A few occurences later, in section 7.2.2, in = what looks like a >> section laying out the packet -- sorry, TLV -- = format, I see for >> "Network State TLV": >> =09 >> "This TLV contains the current locally = calculated network state >> hash. It is calculated over each = reachable nodes' update number >> concatenated with the hash value of its = node data in ascending >> order of the respective node = identifiers" >> =09 >> Phew. Now, it does seem a little at odds with = the terminology. The >> terminology states something about tuples that = are ordered. While >> those tuples are not defined (they should be), = at least what is >> described is clear and possibly can be = implemented. What is in 7.2.2 >> is not ant cannot. > Unified and deduplicated the definitions and added appropriate = references. >=20 Yay you! Thanks >> =09 >> This is an instance of a general issue that I = have with this >> document: that it doesn't take a step back, and = properly define >> things in a proper order, but dives into (and = repeats) details. >> =09 >> =09 >> o Also to section 5.2, for each of the cases that = are described, could >> a conceptual description of "what this = corresponds to" be added? For >> example: >> =09 >> Upon reciept of a Node State TLV: >> If the node identifier matches = the local node identifier and >> the TLV has a higher update = sequence number than its current >> local value, or the same update sequence number = and a >> different hash, the node SHOULD re-publish its = own node data >> with an update sequence number 1000 higher than = the received >> one. >> =09 >> It's not clear why it is a "SHOULD re-publish" = (not MUST, nor what >> happens if SHOULD is not followed). And it is = not clear why 1000 ... >> =09 >> [I just pick this example, but it applies to all = processing bullets] > Hopefully all fixed. I think so, yeah. >=20 >> =09 >> o In the same cases, it is a lot more readable (IMO) to do = nested bullets: >> =09 >> o If FOO; and either of: =09 >> - BAR >> - GNYF >> - BLAB >> Then do all of the following: >> - ... >> - ... >> - ... >> o Otherwise, if not-FOO, ... >> =09 >> That's a personal preference, though, so feel free to = disregard this >> comment. >> =09 >> o Section 5.3 and elsewhere, suggest replacing: >> =09 >> "If it comes via..." >> =09 >> by: >> =09 >> "If received over =E2=80=A6 >> =09 > Done. >=20 Yup >> =09 >> o Last paragraph in 5.3: >> Same comment as 3rd comment to 5.1 made above. > Some rewriting done. >=20 yup >> =09 >> o Section 5.4, first sentence: >> "DNCP validates the set of data within it ..." >> =09 >> Should that not be: >> "A DNCP instance validates the data within its = data sets ..." >> =09 >> ? >>=20 >> Also, "nodes that are currently accounted for; what's = the definition >> of "accounted for"? > Replaced the whole paragraph. Indeed you did, and it is better for it. >=20 >> =09 >> o Section 5.4, first paragraph >> The statement: >> =09 >> "therefore, >> unlike Time-To-Live (TTL) based solutions, it = does not require >> periodic re-publishing of the data by the nodes. = On the other >> hand, it does require the topology to be visible to = every node that >> wants to be able to identify unreachable nodes and = therefore remove >> old, stale data." >> =09 >> which also appeared in the introduction, is copied = verbatimly. Once >> more, the statement is a claim which is not supported, = and that which >> follows "therefore" is not a consequence of that which = comes before >> "therefore". > Got rid of duplicate. Thanks >=20 >> =09 >> o Section 5.4, first paragraph >> =09 >> "When a Neighbor TLV or a whole node is added or = removed, the >> neighbor graph SHOULD be traversed, starting = from the local node. >> The edges to be traversed are identified by = looking for Neighbor >> TLVs on both nodes, that have the other node=E2=80= =99s identifier in the >> neighbor node identifier, and local and neighbor = endpoint >> identifiers swapped. Each node reached should be = marked currently >> reachable." >> =09 >> First comment, why SHOULD and not MUST? > Retained this part, there was a =E2=80=98lightweight=E2=80=99 node = option that can do it > without this; however, I consider it non-interesting so changed to = MUST. OK, thanks >=20 >> =09 >> Second comment, and now you made me go = look...."neighbor" sounds like >> "someone on the same link as me" so the "neighbor = graph" is really just >> a set relating "this node" and "another node which is on = the same link >> as this node". >> =09 >> Yet, looking in the terminology, I see "Neighbor graph" = defined as: >> "the undirected graph of DNCP nodes = produced by >> retaining only bidirectional peer relationships >> between nodes. >> =09 >> Which doesn't sound as much like a "neighbor graph" as = it does a >> "topology graph" for the whole network. >> =09 >> So, is the terminology wrong, or is the definition = wrong? > Renamed to =E2=80=9CTopology Graph=E2=80=9D - probably confusion of = non-native-speaking > authors. >=20 =E2=80=A6and this reviewer, who also is a non-native-english speaker. = [We might have another language in common, though=E2=80=A6?] >> o Section 5.4, 3rd paragraph >> =09 >> Is it actually important that the content of that graph = be "purged"? >> That sounds like an implementation detail -- rather, it = sounds like >> the elements of the graph should "not be used for = calculations and >> MAY be removed". Or, is there a specific requirement = that I am >> missing? > Added lots of text; gist of it, basically, is that unreachable nodes > SHOULD be removed and MAY be removed immediately. Yup, and it is actually nice and clear that text. =09 >> o Section 6.1, I do not understand the parenthesis in this = sentence: >> =09 >> Trickle-driven status updates (Section 5.1) = provide a mechanism for >> handling of new peer detection (if applicable) = on an endpoint >> =09 >> Under what conditions is that applicable, and under = which is it not? > Actually always now; removed (if applicable). good. >=20 >> =09 >> o Section 6.2: >> =09 >> "An upper bound for the number of neighbors that = are allowed for a >> (particular type of) link that an endpoint runs = on SHOULD be >> provided by a DNCP profile, user configuration, = or some hardcoded >> default in the implementation." >> =09 >> A couple of things to that: >> 1) Can you explain the parenthesis? What = type of link? >> 2) How does "an endpoint runs on" a link? >> 3) Why SHOULD? >> 4) Is this specification seriously = suggesting "some hardcoded >> default in the implementation" as a = SHOULD? >>=20 >> [I am tempted to upgrade this to a "Major issue" simply = because of 4) ] =09 > Clarified, the choice to use it is not really visible externally. Now > the text has per multicast-enabled link type constraints, and also > per-profile support for extension at all. >=20 > =09 >> =09 >> =09 >> Also to 6.2, this particular optimization, do you have = any >> quantification of its actual benefit? What should I look = for to >> determine if this "optimization" yields a benefit or = not? What are >> you trying to optimize? Over what link types does this = function? >> I am dubious that it "optimizes" much, if anything, = across an Ethernet, for example ... > Oddly enough, most link-state routing protocols have this = optimization. > Added further description on why it is helpful. >=20 So, the things that you did to this, and the precious comment, helps. = The =E2=80=9Cdesignated router=E2=80=9D (or equivalent/derivatives/*) = mechanism is, as you point out, well known and well used. I was yanking = your chain a little bit here to get, well, pretty much the explanation = and discussion that you gave. Thank you for that. Nit, though, just so that I feel useful in doing this: OLD: MAY also be chosen at runtime. Main consideration when = selecting=20 NEW: MAY also be chosen at runtime. The main consideration = when selecting=20 But, good job here. =09 >> o Section 7 >> As indicated previously, having to search through the = frame format >> diagrams for "how to calculate the value" isn't ideal. > Should be clearly defined earlier now. It is. >=20 >> =09 >> o Section 7.2.3, I worry when I see something like this: >> =09 >> "The whole network should have roughly the same = idea about the time >> since origination of any particular published = state." >> =09 >> What is the definition of "roughly"? >> Is the "should" intentionally in non-caps? >> What're the consequences if not? >> [Note that trickle almost mechanically makes information = propagate >> with non-trivial jitter across a network, so how do you = ensure this?] > Clarified the paragraph, since the original text could be interpreted > invertedly. >=20 Another nit=E2=80=A6 Every node, including the originating one what is =E2=80=9Cthe originating one=E2=80=9D, is it =E2=80=9C=E2=80=A6inc= luding the node originating this TLV=E2=80=9D? Otherwise, yes to your clarification. >> =09 >> o Section 7.2.4, CUSTOM-DATA TLV. >> =09 >> Given the description: >> "This TLV can be used to contain anything; the = URI used should be >> under control of the author of that = specification." >> =09 >> It seems that (i) the description is self-contradictory: = it cannot >> contain *anything* but can contain an URI? >> =09 >> Secondly, how is this supposed to work, what does it = mean [for DNCP] >> that "the URI is under control of the author"? >> =09 >> Thirdly, what does "that specification" refer to? >> =09 >> Fourthly, why lower-case should? Indeed, why is the = "control" of the >> URI of any importance to DNCP? > Removed, since it had issues (besides being ambiguously defined). DNCP > profiles can define additional TLVs easily. Just to be clear, you removed the whole TLV type? That=E2=80=99s fine by = me. >=20 >>=20 >> o Section 9, the bullet: >> =09 >> "When receiving messages, what sort of messages = are dropped, as >> specified in Section 5.2" >> =09 >> Seems at odds with Section 5.2, which discusses TLV = processing. > Unified terms to =E2=80=9Cignore=E2=80=9D, added explanation = mentioning security reasons >=20 Good. >=20 >> =09 >>=20 >> Nits: >> =09 >> Requirement Language: >> o Please reflect Errata 499 for RFC2119 in the = boilerplate >> =09 >> o The RFC2119 boilerplate could conveniently be in = the terminology >> section, given that it is terminology. >> =09 >>=20 > Both done. >=20 Thanks. As I said, great job guys (and WG); IMO we=E2=80=99re really = close with this. Cheers, Thomas --Apple-Mail=_8AE078D4-BFBF-494A-B1CE-D41254A36386 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Steven, all,

[I am looping RTG-DIR and RTG-ADs back in on this, just so = that they do not feel that we do not love them any more =E2=80=A6 ;) = ]

On Jun 20, 2015, at 15:56, = Steven Barth <cyrus@openwrt.org> wrote:

Hello Thomas,

thanks a lot for your elaborate review, we have = just pushed revision -06

And I see = that you have pushed ore than that in the month-or-so since my review. = Thank you for that. 

I will = state outright that I am taking this email as an excuse for =E2=80=9Cgoing= back and looking at -08=E2=80=9D,  in part as I go through the new = I-D, and commenting as I go along. I still think that there may be = reason to spin a -09, so I will hold back making the =E2=80=9Cofficial = RTG-DIR follow-up review=E2=80=9D  until that=E2=80=99s either = done, or I am convinced otherwise ;)

But, guys, thanks for your efforts in both = updating the doc and rebutting my comments. And congratulations on = having produced something which  =E2=80=94 for the most part =E2=80=94= is *almost* there, and where it=E2=80=99s going to be easy to push it = over the finishing line, I think.

Highlights of what I still think is needed (with = details below, of course) from this document:

o A handful or so of =E2=80=9Calmost = there, why don=E2=80=99t we add a sentence on =E2=80=A6=E2=80=9D that = should be
really easy to do, and = should make me shut up on a great number of topics.

o An applicability statement = [sorry, I=E2=80=99m insisting here, I feel this is = important]

o Workable = definition of =E2=80=9CEndpoint=E2=80=9D in terminology

o Still need versioning [sorry, = I=E2=80=99m insisting here, I feel this is important]

As I said, details below =E2=80=94 but good job = getting from -05 to -08, and thanks to you both for having taken time to = address and answer to my review in so painstaking detail, both in the = draft, and in this exchange.

Authors, = for all the points where I have said =E2=80=9Cfine=E2=80=9D, if you = reply to this mail feel free to cut those points out and retain only = outstanding issues.

of DNCP addressing = your issues and comments and that of other reviewers.

Please see more detailed comments = inline.


Cheers,

Steven & Markus



On 16.06.2015 17:45, Thomas Clausen = wrote:
Comments:

o Is there = any good reason why the authors have no listed affiliation?
As we are = independent consultants, an affiliation would probably not be
much more useful than our names = themselves.

OK, was just = wondering if it was xml2rfc acting up.



= o = It is somewhat contradictory that the abstract talks about
= = "...describes a protocol" and then later "...leaves some = details
 to be = specified in profiles, which define actual implementable DNCP
= =  based = protocols"

 Does that not mean, then, = that this document specifies an algorithm,
 a framework, and not a = protocol?
This was debated publicly and tbh. we are not = sure what the correct
phrase would be, maybe = =E2=80=9Cabstract protocol=E2=80=9D, but even that was not = liked
by everyone. Other than = that we tried to clear up the introduction and
abstract in that regard.

OK; on a = personal-preferences level, the separation between HNCP and DNCP seems = artificial, and it probably is part of the reason why this is hard to = describe. I probably would not have made that separation myself =E2=80=94 = but I am not suggesting that the WG goes back on that decision (just to = be clear), rather that it be called out.

I can live with what is there.

o On that, I see "DNCP protocol" several places. Expanded, = that becomes
"Dynamic Network Configuration = Protocol Protocol" ...
Fixed, found only one. (long form is wrong = btw.)


I expected so = ;)


o In general, and despite actually = knowing some of the core algorithms
somewhat = before this review, I found the document really tough to
= = read, with convoluted sentences, inconsistent = requirements-language,
and a lack of introductory = "here's the 1000ft view of the protocol,
what it = does, how it works, and under which conditions it works".
= =
o On that, I do not find the chosen structure of the = document to be
optimal for conveying an = unambiguous protocol specification. For one,
the same = concepts are occasionally described slightly differently.
= = For another, it is often hard to find the information needed = to
parse a specific mandated processing (for example). I = provide an
example of what I would suggest a = better structure in the below.

= = The goal is to provide first concepts and an overview, followed = by a
single, easy to identify place for "precise and = unambiguous definitions
of concepts", and then use those = in the detailed expression of the
protocol. = Note that this is just an example, of course:

= = = Section "Terminology:"
The Network State Hash is a hash = value which represents the
current state of the network, as = known by a node.

Section = "Protocol Overview and Functioning"

= = = = When receiving a FOO TLV, the DNCP node compares the received
= = = = Network State Hash with its own Network State Hash. This
= = = = represents the consistency check rom RFC6206. If same,
= = = = then...if not, then ....

= = = Section "Protocol Information Bases"
For the = purpose of this specification, the Protocol
= Information Bases are orgnaized as sets of tuples ... any
= = = = = implementation can chose whatever representation it wants.
= = = =
The Network State Information Base in a DNCP node is a = set
of tuples:
(x, y, z, w)

= = = = = where x is ..., y is ..., z is ..., and w is ...
= = = = =
Section "How to calculate the Network State Hash":
= = = =
 The = network State Hash is calculated using the information
 from the Network State = Information Base, as follows:

  1. First, = the tuples in that information base are sorted
     in ascending = order based on ....
 
= = = = =   2. = Second, .... (concatenation)
 
= = = = =   3. Third, = the hash function from <profile> is used
 
= = = = =   4. = Fourth, the first n bits of the resulting hash value,
     are retained, = witn n being from <profile>.

And then, = in remaining sections simply reference the Network
State = Hash, which is now ubiquitously defined in a single place.
= = =
I am taking this example, since when reading section 5.3 = I found
myself chasing through the document, finding multiple = slightly
different definitions of "Network = State Hash" --  but beyond this
example, = it generally does apply to the document as a whole, and
= = = certainly to all of the processing and generation considerations = in
section 5.

We reorganised the document a bit, wrote a = better abstract and
introduction and provided = a =E2=80=9CProtocol Overview=E2=80=9D section, on top of that
we reorganised the details in an = =E2=80=9COperations=E2=80=9D section.

OK; I am a good deal more happy now, although not = perfectly happy just yet. 

I = still think that it would be fantastic to have an applicability = statement included. Reading the document without any context [as it = might down the line if it was to become an RFC], it=E2=80=99s hard to = understand if =E2=80=9Chey, I have a problem, is DNCP the right lump of = metal to use to make a hammer for it?=E2=80=9D

As I said in my original review, I think that this = is a matter of scoping the work right. The abstract, and the into, calls = out =E2=80=9Ca generic state synchronization protocol=E2=80=9D =E2=80=94 = I=E2=80=99ve heard OSPF described as such, also (hi Fred!) =E2=80=94 = which sounds very much like =E2=80=9Cboiling the ocean=E2=80=9D, and = which I think the WG is not trying to actually do.

Why don=E2=80=99t you put a subsection before the = last paragraph of the Introduction =E2=80=9CApplicability=E2=80=9D and = then expand on that?

I just want to = note that I enjoyed the expanded terminology - thank you! There may be a = small formatting snafu, at least in the HTML version, about missing = blank lines between (for example) =E2=80=9CAddress=E2=80=9D and = =E2=80=9CEndpoint=E2=80=9D

Going = back and looking at that, does it make sense to talk about =E2=80=9CDNCP = network=E2=80=9D, out in the real world, or just in this = document?

An HNCP network and a TNCP = network (that=E2=80=99d be for "Thomas' Neat Configuration Protocol=E2=80=9D= ) sure, and such two could co-exist (but not interoperate) so while they = =E2=80=9Cin the abstract=E2=80=9D would both be instances of DNCP = networks, that=E2=80=99d be an abstract construction = altogether.

Could I suggest that to = the definition of =E2=80=9CDNCP network=E2=80=9D some verbiage to that = effect be added?

Now we=E2=80=99re = at tightening up on terminology, I am finding myself wondering about = =E2=80=9CDNCP profile=E2=80=9D and =E2=80=9CDNCP-based protocol=E2=80=9D = as terms, just a little.

A DNCP = profile is 
     a = definition of the set of rules and values
  =                   =  defining the behavior of a fully specified,
                =      implementable protocol which uses DNCP.  The = DNCP
            =          profile specifies transport method to = be used,
            =          which optional parts of the DNCP = specification are
        =              required by that = particular protocol, and various
    =                  parameters = and optional behaviors.  In this
    =                  document = any parameter that a DNCP profile
    =                  specifies = is prefixed with DNCP_.  Contents of a
  =                   =  DNCP profile are specified in Section 9.

Could we be a little bit more = succinct:

=E2=80=9CA DNCP profile = consists of:
o The = values for the set of parameters, given in section 9.
= o = The set of optional parts of this specification, which are to be = used.=E2=80=9D

For DNCP-based = protocol, the doc says:

A DNCP-based = protocol is:
a protocol which = provides a DNCP profile, and
      =   potentially much more, e.g., protocol-specific TLVs
                =         and guidance on how they should be = used.


Could = we be more precise (than =E2=80=9Cpotentially much more=E2=80=9D) on = =E2=80=9CDNCP-based profile=E2=80=9D

=E2=80=9CA DNCP-based protocol is:
= o = A DNCP profile, according to Section 9,
= o = Zero or more TLV assignments from the registries set up by this = specification
o = generation and processing rules for these TLVs

?

On the = definition of =E2=80=9CAddress=E2=80=9D:

o What does it mean to be = =E2=80=9Crelatively transport agnostic=E2=80=9D? = I=E2=80=99d 
say that it=E2=80=99s a = little bit like being =E2=80=9Crelatively pregnant=E2=80=9D =E2=80=94 = either you are, or you are not?

o Why not = define an =E2=80=9CAddress=E2=80=9D as  (IPv6-address, Transport, = Port)?
= (and then, if someone comes along with something = that doesn=E2=80=99t fit that tuple form
= down the line, deal with it then?)

Address, by the way, uses =E2=80=9Cendpoint=E2=80=9D= which is defined below. 

Endpoint, then, ends up being defined almost as an = =E2=80=9Caddress=E2=80=9D *except* that there=E2=80=99s the clause = =E2=80=9Cmay be bound to a set of predefined unicast addresses=E2=80=9D = [would those be addresses as previously defined?]

When I read =E2=80=9CEndpoint=E2=80=9D I end up = simply thinking =E2=80=9CSocket, expressed as (IPv6-address, Transport, = Port)=E2=80=9D but as that was defined above it can=E2=80=99t be = it? 

Could you clear that up, = please? [Note, it=E2=80=99s better than the -05, but still = confusing]


o As a general comment, the document would do well with a = good editorial
overhaul to bring consistency in = language usage, consistency in 2119
= terminology, coherence in defined terms and their definition, = document
structure, etc.

We did another editing = round with focus on normative language.

Much better, thanks. I=E2=80=99ll holler if I see = something to fix on this front




Major Issues:

o The = introduction does not read well; it contains parts of something that
=   could be = considered as part of an applicability statement (without it
=   being = called out as such, and without forming a complete applicability
= = statement), and does not actually introduce the protocol. Reading = just
the introduction and the abstract, it is very obscure = if
this is a framework, a protocol, a building block, an = architecture, an
algorithm -- and, if either of = those, what it is actually accomplishing,
and why = one would chose to use DNCP. It does, however, transpire that
= = "whatever it is", it has two "modes" and that it requires = something
(presumably a routing protocol) = to provide each "node" with a topology
map.
= =
Suggest that a proper introduction consisting of three = parts would be
beneficial: (i) what this = document is, (ii) what doing DNCP actually
gets you, = and (iii) the operating conditions under which the
DNCP is = applicable.

On the = latter point, given that you state that DNCP requires profiles
= = to provide "actual implementable DNCP based protocols", it = appears
important to understand what the limits for "what a = profile can give
you" are.

= = I am calling this out as a major issue, since I believe that it = is
not just editorial, but is a matter of scoping this = document correctly,
and in particular not falling = into the trap of "claiming applicability
where = it's not".

As noted earlier, the introduction has been = reworded and separated from
protocol overview also = considering your suggestions.

So this is = good, thank you for doing that effort =E2=80=94 it=E2=80=99s tedious, = but it helped.

To section 3, = therefore, a few suggestions:

1) Throw an = initial paragraph in stating what DNCP does =E2=80=9Cstate = synchronization=E2=80=9D and all that.

2) =E2=80=9CDNCP discovers the = topology of its nodes and =E2=80=A6=E2=80=9D
= Argh=E2=80=A6almost there =E2=80=9Cits nodes=E2=80=9D?
= - = would that be =E2=80=9Cthe nodes in the DNCP network=E2=80=9D = (which has been defined=E2=80=A6)?
= - = you=E2=80=99re discovering the topology (i.e., you actually = produce a topology graph?)
or just = the presence or absence of nodes in the network (i.e., a destination = list)?
= Just state what you do, and it=E2=80=99ll be = good.

3) =E2=80=9Cbidirectionally = reachable=E2=80=9D =E2=80=94 call out if that means =E2=80=9Cover one IP = hop=E2=80=9D (as in =E2=80=9Con the same link=E2=80=9D)
= or if it can be =E2=80=9Cbidirectionally reachable, possibly = through a multi-hop path=E2=80=9D

Actually, why don=E2=80=99t= you define that term in the terminology section, since it appears = also
= in section 4, and it=E2=80=99d make me go away with this = comment in more places than one ;)

4) =E2=80=9CA hash tree is = maintained by each node=E2=80=9D =E2=80=94 I=E2=80=99ve thought about = that, and I think that you may
want to expand a little = more. =E2=80=9CA hash tree, rooted in itself, is maintained by each = node=E2=80=9D?

5) And then, = again, the text is almost there, bit just need a nudge=E2=80=A6how is = the tree constructed?
You start fine =E2=80=9Ca = node starts with a hash tree only consisting of = itself=E2=80=9D.
Then it announces that, = and gets updates. How are those =E2=80=9Cintegrated=E2=80=9D into the = receiving nodes=E2=80=99
hash = tree. 

= Yes I know how it=E2=80=99d work out (I may be dense, but not = *that* dense ;) ), but I think that it=E2=80=99d = be 
easy to capture all here = and being complete, since it=E2=80=99s so close.

By the way, I would state that the hash tree is = height 1 in this section, and add a forward reference to = 4.1.

Overall, I really like section = 3.

It might be a good litmus test to = ask someone with no previous understanding of Trickle to give it a = read-through and explain it back to you, though, just to be = sure.

But I really like section 3. = Thank you.

Section 4, I really like = what you have done with it also. As a purely subjective matter, could = there between 4 and 4.1 be some educational text that describes how the = 6 subsections to 4 =E2=80=9Cfit together=E2=80=9D? As it is right now, = it=E2=80=99s a little abrupt.

o The document, in my understanding, defines an exchange = format with
limited ability to evolve, as = simply "a steam of TLVs".

As long = as there's never a need to evolve the TLV format itself, and
= = as long as you do not run out of TLV types, that's not going to = be
a problem. The doc sets aside a 16bit TLV type space, = that's reasonable
enough, but I worry if eventually = a DNCPv2 will need to evolve the
format. = One purely hypothetical example could be if a "sequence number"
= = would be needed in each DNCP message to detect "link success = rates", or
something of that sort.

I think on this front we = have to agree to disagree; as it is a stream of
_unrelated_ TLVs with some rare exceptions (node = endpoint ID =3D> network
state), a later spec such = as DNCPv2 can specify if it wants to that
every DNCP 'message' contains TLV of type $FOO = and uses disjoint set of
TLVs to do X. Hell, we do = that in HNCP already.


OK, then, in = that case what you call a TLV is what I would call a =E2=80=9CMessage=E2=80= =9D =E2=80=94 fair enough, I can do that mental = substitution.

Now=E2=80=A6that still = doesn=E2=80=99t change the fact that you may end up having to evolve = your Message format =E2=80=94 I=E2=80=99m sorry, your TLV format =E2=80=94= as it appears on the wire, as well as some of the behaviors that you = exhibit through DNCP processing.

For = that, you=E2=80=99ll need a version number. And again, I am sorry, I = cannot come up with a concrete example and =E2=80=94 again =E2=80=94 = that=E2=80=99s part of the dilemma: a future extension that we have not = thought about is, by definition, a future extension that we have not = thought about and so therefore we can=E2=80=99t predict if it will be = interoperable with a what we have now.



= = I do not have an actual example in mind -- and that's exactly the = point:
to be evolutive for the unknown future and (at the very = least) be able
to discriminate between "old" and = "new".

A discussion could be had if a = "version number" in each TLV would do,
or if a = concept of "protocol message with a version number" is
= preferential. I do not believe, however, that "no version number" = is
viable.

Since DNCP is an abstract protocol, a concrete = protocol on top of it
might probably want to do = versioning for its own purposes (i.e.
different versions on top of the same DNCP = version). In this case having
versioning in both DNCP = and the derived protocol serves little purpose.
HNCP - as first derived protocol - defines a = Version-TLV btw.


Yes but that is = a =E2=80=9Cversion TLV=E2=80=9D =E2=80=94 what happens if the TLV format = itself, or some of the DNCP specific processing.

This, incidentally, goes to the crux of why I =E2=80= =94 personally =E2=80=94 would not have done the split. Had DNCP = *exclusively* been an algorithm, or such, then I could see not needing a = version in DNCP, but in the DNCP-based protocol (HNCP) only. Or, for = that matter, had DNCP been just a frame format with no processing, or = something, then I could see one sequence number sufficing.

By DNCP being = part-signals-part-procesing-part-behavior-part-framework, which cannot = exist on its own but which requires =E2=80=9Canother protocol which = profiles it and which also defines its own signals, processing, and = behavior=E2=80=9D, yes, you actually having this =E2=80=9Cversion number = conundrum=E2=80=9D.

You could not = fix all this by having a DNCP version number only, but having a = sufficiently large TLV type space? That way, you=E2=80=99d not need = (say) HNCP version numbers, but a HNCPv2 would use TLV types A, B and D = (but not C) from HNCPv1, and would reserve and define TLV types X, Y, Z = ?



o Noting = that the "overhearing n reduncant transmissions" is a key
= = retransmission suppression mechanism in Trickle, and that this
= = seems to assume broad/multicast, using unicast seems to = contradict
the statement of "consists of = Trickle", at least in the way the
algorithm = is defined in RFC6206. Note: it's fine to use an algorithm
= = outside of its initial scope, but it should be with the caveat = of
"which of the characteristics still hold, and which do = not"
If k < 2, even = on point-to-point link, Trickle does reap benefits and
provides exponential backoff timer. Obviously, = we can spell this out
more explicitly if it = helps.


YES, that sort = of explanation would be good.


o DNCP = claims to be trickle based, yet supports unicast. It also
= = (apparently) is a request/reply protocol.  It doesn't have = messages.
This document needs a good, and = pedagogical, "protocol overview and
= functioning" section somewhere: one needs to get through the end = of
Section 5 before having even a vague idea of how DNCP = works.
Protocol overview = added.

Perfect, as I = said, I like what you did in section 3.

o The use of normative language is not as tight as could be = desired.
For example, a number of SHOULDs = seem to really ought to be "MAYs" since
not = following the SHOULD won't break the algorithm. It would be good
= = to walk through the document and take a careful look at these = to
either MUST/MAY the SHOULDs, or to qualify the SHOULDs = remaining.

Reworked.

That seems to have helped a great deal.

o I am going to go out on a limb here, and say that "the = protocol is
underspecified". That's a = deliberately provocative statement, but it
was = honestly how I felt upon having completed the review.

= = The document does not help the reader get an intuitive = understanding
of the protocol functioning, but = jumps right into minute details --
requiring = the reader to "build up her or his own model of how DNCP
= = works". On having read the document a few times, I think that = I
understand it -- but there's nothing permitting me to = verify my
understanding, and thereby I'd = not feel confident to be able to
provide = an interoperable and independent implementation. I've given
= = some comments in the "Comments" section as to what I think would = be
viable ways to improve this point.

Addressed.

Indeed you did. = It seems a LOT better, and I appreciate your efforts here. As I said, I = am trying to respond to those issues that seem to be outstanding in this = email; I=E2=80=99ll go through the document once more in all its = nitpicking detail once we=E2=80=99ve resolved those few issues that I = think are still pending.


 o Section = 5.3, penultimate paragraph:

  "If = keep-alives specified in Section 6.1 are NOT sent by the peer
= =      (eith= er the DNCP profile does not specify the use of keep-alives or
= =      the = particular peer chooses not to send keep-alives), some other
= =      means= MUST be employed to ensure its presence.  When the peer is no
= =      longe= r present, the Neighbor TLV and the local DNCP peer state MUST
= =      be = removed."

"...some = other means MUST be employed to ensure its presence." --
= = followed by more MUST verage when a peer disappears...I am not = sure that
that's conductive to = interoperable implementations.

= = Two implementatons may chose different "means" and then turn off = keep-
alives - and be non-interoperable.

= = For interoperability, we need:

= = = = o = A mandatory to implement mechanism, that always is
= = = = = present, but can be complemented by another "means", or
= = = = =
o A mandatory to implement mechanism, which by way of a
= = = = = specified negotiation mechanism can be turned off between
= = = = = two peers, to allow them to use another "means".
= = = = =
If you argument is "...this will be specified in the = profile", then
you still should provide the two = above in this document, with the note
that = "...and a profile may specify which from among these MUST be
= = used in a given deployment"

Clarified that =E2=80=9Cother means=E2=80=9D, = refers to existing transport-provided
mechanism, e.g. Ethernet carrier-detection, TCP = keep-alives etc.

Alright, = good. Now where is it specified which is to be used? Is that part of the = profile, or should it be? If so, call that out here.

I=E2=80=99m trying to avoid interoperability = issues, for example if I am using =E2=80=9CTCP keep-alives=E2=80=9D and = you are using something else, can we work together? If this is not a = problem, call that out as something which a device can do as it sees fit = (although, for example. TCP keep-alives presumably expects TCP which is = a profile matter =E2=80=A6)

I = *think* that we are almost there also with this point, so convince me = that the text there won=E2=80=99t cause interoperability issues? Hiving = it off to a profile to specify would do just that (of course, I=E2=80=99d = come back on that in HNCP, instead ;) ).



o Section = 8:
Interesting; I am not a security expert, but I am very = curious to
see the SEC-DIR review of this = document. That said, section 8.3.1
contains = normative verbage:

"A node = MUST be trusted for participating in the DNCP network if and
= = = only if..."

Which I = think needs a qualifier of the "If the certificate based
= = trust model is used, then a node must be trusted for ...."
=
Same goes for the subsequent SHOULD - it really reads = as-if this
certificate based mechanism = initially was intended as MTI, but then
was = backed away from subsequently without a complete cleanup of the
= = text?

It was never intended to be MTI, the intention = was that nodes not
participating in the = mechanism would ignore the whole section (and
normative language), that is now explicitly = stated in normative language
in the = beginning.

OK, this is not = a comment, then, for the authors to action, but for the WG chairs: I would strongly recommend that = you reach out to the SEC ADs to understand what their expectations are = to this.

Speaking from = not-so-ancient-experiences, the SEC-ADs have become more =E2=80=9Cstrict=E2= =80=9D with what they let through, and what might have passed a year ago = would not fly today. 

I am NOT = a security expert, though, but as they say, a burnt child = ...


I do actually question the value = of having a laundry-list of trust
= management methods, and for one of those (certs) a = laundry-list
of all sorts of trust = relationship establishment methods, in this
document; = this in no small part as the lists are explicitly indicated
= = as "non-exhaustive" and that none are listed as "mandatory to
= = implement". Was any thought given to factoring this into a = seperate
document, and focusing in this = document on one, mandatory-to-implement,
security = mechanism?

This set is a 'useful base set' that e.g. HNCP = requires. While I agree
it is not exhaustive, as = the original goal was just to split DNCP and
HNCP, I consider it a success.

Not sure that I = agree, but I think I will fold this into =E2=80=9Cdiscuss with = SEC-ADs=E2=80=9D since that=E2=80=99s for the most part not in my scope = of competencies.

Minor Issues:

Introduction:
o 1st = paragraph: "reachable nodes"; two things:

= = = = - = I always have a problem with the term "node"; it is often
= = = = = used as a shorthand for "routers and hosts, both". I was
= = = = = given to understand that homenet specifically did not want
= = = = = to consider host changes?
DNCP is not strictly speaking about homenet (but = a strict requirement
for HNCP which is). Also = even in homenet-case non-routers may join the
network temporarily in order to e.g. do = monitoring.

But, would those = =E2=80=9Cnon-routers=E2=80=9D not speak at least part of the =E2=80=9Chome= net specific protocols=E2=80=9D and thereby not be =E2=80=9Chosts=E2=80=9D= in the =E2=80=9Cgot them from Best Buy and just clicked OK=E2=80=9D = sort of sense? 

So is the crux = that we have =E2=80=9Chomenet-aware devices=E2=80=9D and =E2=80=9Clegacy = hosts=E2=80=9D, and that either of us just need to get with the program? = If so, can I insist (gently) on =E2=80=9Chomenet-aware devices=E2=80=9D = [with a suitable definition] instead of =E2=80=9Cnodes=E2=80=9D since = =E2=80=9Cnodes=E2=80=9D are such an overloaded term that it=E2=80=99s = not even fun any more.



- "Reachable" - does that mean = something as in "radio range",
does it = mean "on the same link", does it mean within a
specific = (DNCP?) domain, or does it mean simply "on the
Internet = somewhere"?

Clarified in the text as =E2=80=9Cbidirectionally = reachable=E2=80=9D, also added
fwd-references to actual definition.

Suggest also = defining in Terminology, and clarifying if this is a one-hop, or a = multi-hop-within-the-homenet, concept. In section 1, I do not see a = forward reference, btw, at least not in latest rev.



= = o = 2nd paragraph: "nodes that are currently accounted for":
= = = = - = What does that mean?

- Also, the = conclusion "Therefore unlike Time-To-Live (TTL) 
= = = = = based solutions, it does not require periodic re-publishing
= = = = = of the data by the nodes" does actually not follow from
= = = = = the previous sentence in that paragraph.

= = = = - = I actually do not think that the introduction describes
= = = = = what DNCP does, and so the comparison to TTL-based
= = = = = solutions is rather hard to get here.
Fixed. =

Indeed it = is.



- Continuing:

= = = = = = "On the other hand, it does require the topology
= = = = = = to be visible to every node that wants to be able to
= = = = = = identify unreachable nodes and therefore remove old,
= = = = = = stale data."

This = reads a lot more like an applicability statement than
an = introduction; the take-away when reading this is:

= = = = = = "Each node must have something that maintains
 a topology map of the = entire network, such as
 a (LS) routing protocol, = for DNCP to function"

Is that = actually the intent here?

Clarified, it was intended to be read as DNCP = itself providing that
topology.


OK.


- "DNCP is most suitable for data = that changes only gradually"
How is the reader to interpret = "gradually"? Do you mean
"infrequently", or do you really = mean "gradualy"?
Clarified.


OK



o Last = paragraph:
"DNCP has relatively few = requirements for the underlying
 transport; it requires some = way of transmitting either unicast
 datagram or stream data to = a peer"

This is a bit of a forward = comment, but we now have "nodes
that are = accounted for" and "peers". I see neither defined in
the = terminology section.

"and, if = used in multicast mode, a way of
 sending multicast = datagrams."

This is = the first mention of two "modes" of this protocol. This
= = = loops back to an earlier comment, that the introduction = actually
does not introduce the protocol, = but rather is an incomplete
applicability statement.
Fixed and moved to = more appropriate sections.


And, it reads = much better now. Thank you.



= = = = "If security is desired and one of the
   built-in security methods = is to be used, support for some
= TLS-derived transport scheme - such as TLS [RFC5246] on top of
= = = = TCP or DTLS [RFC6347] on top of UDP - is also required."

   I am not pretending to be a = security expert, but "some
   = TLS-derived...such as ... on top of TCP or DTLS..." (i) does = not
   sound like it could lead to = interoperable implementations, and (ii)
   does not = sound sufficiently tight as a MTI security mechanism to
   pass security reviews. Again, I = am no security expert, but perhaps
   getting = one looped in early would be advicable?
Clarified that profile MUST define = details.


Also good, thank = you.


Terminology:
o Suggest = adding "In this document ..." somewhere to this text:

= = = = "For readability, any DNCP profile specific
 parameters with a = profile-specific fixed value are
 prefixed with DNCP_."
Fixed.

Thanks



o DNCP = network: I read this twice, and came away with two different
= = = understandings, perhaps you can clarify which it is:

o A set of nodes running DNCP, = within the same domain, and
for which a path betwen any two = DNCP nodes includes only
other DNCP nodes; i.e., a DNCP = network forms a connected
component with only other DNCP = nodes.

o A set of nodes running DNCP. They = may be anywhere on the
Internet, they are part of the = same DNCP network as long
as they (through other means) = have learned of each others
addresses.

= = = In the former, that'd be (for example) a deployment within my
= = = home -- in the latter, it could be a node in my home and a node = in
your home forming a DNCP network.

= = = The text is not quite clear on this point.
Both are valid use = cases; hopefully clarified.


OK, sadly = you clarified it ;) Well, no, not sadly, but you clarified it to be = understandable to me in the above sense. But, if I come up with the = aforementioned TNCP and I use the same transport as HNCP, would a TNCP = and a HNCP node be on the same DNCP network, then?


o Link: a point of clarification = here. In "DNCP network", there was
talk = about "unidirectional links" and "bidirectional links"; in
= = = "Link" the definition is somewhat vague "directly connected" = and
"can communicate". Could something like "without = decrementing TTL/
hop-count" be added, and could a = statement on bidirectionality
(IOW, that this is just an IP = link) be added?
This isn=E2=80=99t IP specific as such; however, = some better definition is
welcome. some types of IP = links are not strictly bidirectional either
(hello, mesh). =

Hi, you = rang? ;)

Actually =E2=80=9Csome mesh = protocols=E2=80=9D do go through the exercise of verifying = bidirectionally before even considering them as useful for whatever the = protocol tries to do.

What I am = trying to get at, though, is not this discussion but rather: what does = this Link present to the IP layer, in terms of properties?


o "Interface" is overloading the = term "port" (IP port) which can be
= confusing
Done (stole definition from some RFC that is = =E2=80=98port free=E2=80=99)

It=E2=80=99s= , indeed, a very good idea to steal a good idea.

o "Endpoint" - The definition "locally configured use of = DNCP" is not
clear -- are you really not = talking about a DNCP process?

I am not = sure that it is clear how a DNCP process can be "attached
= = = to  ... a specific remote unicast address, or to a range of = unicast
addresses that are allowed to contact"

= = = I can see how a DNCP process can be configured to allow = connections
from a specific range of = addresses, or can be configured to connect
to a = specific remote unicast address. Is that what you mean instead?
= = =
Clarified, endpoint most likely resembles = network socket, i.e. bound to
interface or connected to = certain remote address etc.


OK, I addressed = that earlier in my comments.



= = o = "Peer" - states that two peers "communicate directly". For = link,
the definition is "directly connected nodes can = communicate".
Would it then not be easier to = say "a DNCP node on the same link
as ..." = ?

It is not. Removed directly if it = helps.

Ah, so now it is = just =E2=80=9Csomeone out there in the network with whom I = communicate=E2=80=9D - fine, it=E2=80=99s clear.

o "Node = state"
"The hash function and the number of bits used are = defined
 in the = DNCP profile."

= Suggest:
"The hash function and the length = of the hash value are defined
 in the DNCP profile."
= = =
Done.

Thanks.


= = o = "Network state hash" - same comment as for node state (above)

Done.

Thanks.


= Data model:
o "Latest update sequence = number"
This may just be my personal taste, but does it hurt to = mandate
a specific way of doing the looping comparison? The = reason I
suggest this is, that it's one of = those things where creativity
in an implementation seems to = simply be an invitation for bugs,
and for = little gain

Done.

Thanks


o "Relative time delta"
= = = Document talks about "a 32 bit number on the wire" -- does = that
mean that wireless links are excluded?
I thought this was = an expression, but guess not, replaced with
=E2=80=98transmitted as=E2=80=99 (both here + = fragment stuff)

I=E2=80=99ve = spent a good chunk of my career =E2=80=9Coff the wire=E2=80=9D so I=E2=80=99= m perhaps specially sensitive to that. Thanks for catering to my special = sensitivities ;)




o Related to terminology, there = seems to be some fuzzyness around
node and = endpoint. For example, in data model one of the things that
= = = a DNCP node may have is:

"Unicast = address: the DNCP node it should connect with"

= = = Does that mean *any* DNCP process (i.e., *any* endpoint) at = that
address, or a *specific* DNCP process at that address?
= = =
The same, but inverse, for "Range of addresses: the DNCP = nodes that
are allowed to connect" - is this = "any DHCP process (i.e., *any*
endpoint) = on any of these addresses?

= Following, the same section reads:

= = = = "For each remote (peer, endpoint) pair detected on a local
= = = = endpoint, a DNCP node has..."

= = = the following text indicating that there's some sort of = distinction
between which endpoint.
= = =
This whole thing needs some clarification.
I think there was a = general misconception about the term endpoint, which
is hopefully cleared up in the latest = revision.


Hm, it was = cleared somewhat, but there are still murky areas; see previous comment. = I am still confused after having read through the relevant bits again, = but I am confused in a different way now, than I was last time. That may = be an improvement after all. I think the crux is the distinction between = =E2=80=9CAddress=E2=80=9D and =E2=80=9CEndpoint=E2=80=9D in the = terminology, and once that is settled the rest will likely fall into = place.


= =

Operation

= = o = First a generic comment that Trickle itself has some operating
= = = conditions which scopes its applicability, and it would behove
= = = this document to, in its own applicability statement, call out
= = = those.
Added some comments regarding = applicability.

Better, but I = would like to see that reflected also in a dedicated applicability = statement.


o On the = same token, while the use of Trickle in an unicast fashion
= = = is possible, I wonder if (in general) unicast use is advicable. = I
appreciate that some links are point-to-point and so a = broadcast
across it becomes an unicast -- = but, does that necessitate being
called = out?

IF the reason for this "because = we can use TCP", then be explicit
about = this - but, also, that you're then not exactly using Trickle
= = = where and how it was intended. I wonder if you could be = explicit
as to what consequences this = "alternate use of Trickle" have? It
seems = that the use of unicast is directly contradicting the main
= = = operating consideration of Trickle?

In general DNCP is transport agnostic, therefore = calling out a specific
transport such as TCP is a = bit debatable. RFC 6206 seems to be all about
picking right values at least; they DO NOT say = it is multicast or
broadcast only, only that = it communicates with 1 address. that's what we
do, it's just the other endpoint.


OK, fair enough argument.


o 2nd paragraph states:
= =
"the multicast transport does not have to be = particularly
 secure"

= = = What is the definition of "not have to be particularly = secure"?
Is cleartext OK? Authentication? = Encryption?
Should I do something more?
= = =
Clarified: =E2=80=98.. does not have to be = secured.=E2=80=99

Thanks.


5.1 = Trickle-driven status updates
o  First = paragraph:

= "Multicast MUST be employed on a multicast-capable interface;
= = = =  otherwise, = unicast can be used as well"

If the = interface is not multicast-capable, then unicast can be
= = = used as well as what? Certainly not multicast, since the = interface
is not multicast capable...?
= = =
All fixed.

Yup, it is.


o = Continuing:

"If = possible, most recent,"

What = would make it "not possible"?

   "recently = changed, or best of all, all known Node State TLVs"
  
   OK, so = assuming that for some reason (MTU limitation) it is not
   possible, does the above = represent an order that I MUST respect,
   or is it = "take a pick from among these, according to your whim of
   the day"?

= = = = "(Section 7.2.3) SHOULD be also included,"

= = = SHOULD is a strong statement, especially when prefixed by
= = = "if possible". That, essentially, renders it a MAY.
= = =
"unless it is defined as undesirable for some reason
= = = =  by the DNCP = profile

Now it DEFINITELY is a MAY since = apparently a profile can state
that = these TLVs MUST NOT be included -- and, I assume, since the
= = = document permits it to do so, it is possible without breaking = the
algorithm.
Degraded to MAY; while it improves convergence = speed, it is not worth
being too specific about = it.

And that=E2=80=99s= exactly what I like to see MAYs used for, so fantastic, = thanks.



o And, continuing again:
= =
"If the
    DNCP profile supports dense = broadcast link optimization
 (Section 6.2), and if a = node does not have the highest node
 identifier on a link, the = endpoint may be in a unicast mode in
 which multicast traffic is = only listened to.  In that mode,
 multicast updates MUST NOT = be sent."

Really hard to parse. Is that not = equivalent to saying:

"If a = DNCP endpoint is not configured to be in multicast
  mode, then it MUST = NOT send multicast updates"

?
= = =
If it is, then say that -- if it is not, then a rewrite = is needed,
as that's what I manage to = extract from the text.
Hopefully clarified now, about when = multicast/unicast is used.

yep, I = think it is.

5.2. =  Processing of Received TLVs
o First = paragraph reads:

"The DNCP = profile may specify criteria based on which particular
 TLVs are ignored."
= = =
Criteria for what? Do you perhaps mean:

= = = = "The DNCP profile may specify which TLVs to process, and
= = = =  which to = ignore"?

Auxiliary = question, then, and related to my penultimate comment
to 5.1, = are there any constraints on that, any risks from ignoring
= = = (or not) specific TLVs to the operation of the network?
Added some text to = the profile section and reference.


Yup, good.



= = o = I am also confused by the 3rd sentence in the first paragraph:
= =
"Any =E2=80=99reply=E2=80=99 mentioned in the steps below = denotes sending of
   the specified TLV(s) via = unicast to the originator of the TLV
   being processed."
= = =  
= = =  This confusion = is likely due to the lack of a "protocol overview
 and functioning" = description [either as its own section, or as part
 of the introduction].
= = =
 I know = how trickle works. Trickle is a distributed consistency
= = =  algorithm. = When an inconsistency is detected, then an action is
 triggered that rectifies = that inconsistency.  DNCP claims to be trickle based, but = apparently also a sort of request/reply
 mechanism. Combined with = trickle-over-unicast-links, I am not sure
 what the protocol logic = actually is. Reading through to the end of
 Section 5, I think that I = understand the idea, but I am not sure.

= = =  And the old = "when in doubt, look at the state machines" didn't help
= = =  either, there = aren't any.

 The point to this comment = is, that the document immediately jumps
 into the details -- but = forgets to give the "10000ft view" of the
 protocol functioning.
Added protocol = overview and made connection between trickle, merkle tree
and requests more clear.


Indeed, and =E2=80=9Cmerkle trees=E2=80=9D disappeared = and became hash trees somewhere along the line ;)


= = o = First paragraph states two SHOULD. Would those not be MUST? = What
breaks if not respecting those criteria?
Done.

tnx



= = o = 2nd paragraph, a "valid address", that definition is rather = unclear.
I understand that that's = something specified in "the profile", but
what is = the relationship to the different addresses discussed in
= = = the data model section?

= = = It is not clear what the parenthesis to this paragraph means,
= = = but that is probably again a case of the "use case" and = "protocol
overview" not being documented - = the document so far has nowhere
described = interaction with outside processes.
Text changed.

Ok, I can live with that.



= = o = First bullet, but generally through these, and other, bullets:
= =
I had a really hard time deciphering this. First:
= = =
"The receiver MUST reply
      = ;   with a Network State TLV (Section 7.2.2) and a Node = State TLV
      = ;   (Section 7.2.3) for each node data used to calculate = the
      = ;   network state hash"

= =     Alright, = off to find "network state hash".

= =     The = terminology tells me that it is:

= =      "a hash = value which represents the current state of
   the network.  The hash = function and the number of
          &nb= sp;     bits used are defined in the DNCP = profile.
          &nb= sp;     Whenever a node is added, removed or = updates its
          &nb= sp;     published node data this hash value = changes as
          &nb= sp;     well. It is calculated over each = reachable nodes'
          &nb= sp;     update number concatenated with the = hash value of
          &nb= sp;     its node data. For calculation these = tuples are
          &nb= sp;     sorted in ascending order of the = respective node's
          &nb= sp;     node identifier.

= =     Searching = further, I find Section 5.1, but that simply states:

= =      "The = Trickle state for all endpoints is
     consi= dered inconsistent and reset if and only if the locally
= = =      calcu= lated network state hash changes."

Next = occurence is in these bullets, and then just before Section 6,
= = =
"During
     the = grace period, the nodes that were not marked reachable
     in = the most recent graph traversal MUST NOT be used for
     calcu= lation of the network state hash, be provided to any
     appli= cations that need to use the whole TLV graph, or be
     provi= ded to remote nodes."

Alright, = now I know what I can't use for calculating it.

= = = A few occurences later, in section 7.2.2, in what looks like a
= = = section laying out the packet -- sorry, TLV -- format, I see = for
"Network State TLV":

= = = = "This TLV contains the current locally calculated network = state
hash. It is calculated over each reachable nodes' update = number
   concatenated with the hash value = of its node data in ascending
   order of = the respective node identifiers"
  
= = = Phew. Now, it does seem a little at odds with the terminology. = The
terminology states something about tuples that are = ordered. While
those tuples are not defined = (they should be), at least what is
described = is clear and possibly can be implemented. What is in 7.2.2
= = = is not ant cannot.
Unified and deduplicated the definitions and = added appropriate references.


Yay you! = Thanks



= = = This is an instance of a general issue that I have with this
= = = document: that it doesn't take a step back, and properly = define
things in a proper order, but dives into (and repeats) = details.


= = o = Also to section 5.2, for each of the cases that are described, = could
a conceptual description of "what this corresponds to" be = added? For
example:

= = = = Upon reciept of a Node State TLV:
If the = node identifier matches the local node identifier and
the TLV = has a higher update sequence number than its current
          local = value, or the same update sequence number and a
          different = hash, the node SHOULD re-publish its own node data
          with an = update sequence number 1000 higher than the received
          one.
= = =
  It's not = clear why it is a "SHOULD re-publish" (not MUST, nor what
= =   happens = if SHOULD is not followed). And it is not clear why 1000 ...
= = =
[I just pick this example, but it applies to all = processing bullets]
Hopefully all fixed.

I think so, = yeah.



o In the same cases, it is a lot = more readable (IMO) to do nested bullets:

= = o = If FOO; and either of:
  - BAR
=   - GNYF
=   - BLAB
=   Then do = all of the following:
  - ...
=   - ...
=   - ...
=   o  = Otherwise, if not-FOO, ...
 
=   That's a = personal preference, though, so feel free to disregard this
=   = comment.
 
=  o Section = 5.3 and elsewhere, suggest replacing:

=   "If it = comes via..."
 
=   by:
=  
=   "If = received over =E2=80=A6
 

Done.


Yup


o Last paragraph in 5.3:
= = = Same comment as 3rd comment to 5.1 made above.
Some rewriting = done.


yup


o  Section = 5.4, first sentence:
"DNCP validates the set of data = within it ..."

Should = that not be:
"A DNCP instance validates the = data within its data sets ..."

= = ?

Also, "nodes that are currently = accounted for; what's the definition
of = "accounted for"?
Replaced the whole paragraph.

Indeed you did, = and it is better for it.




= o = Section 5.4, first paragraph
The = statement:

= "therefore,
    unlike Time-To-Live (TTL) = based solutions, it does not require
     perio= dic re-publishing of the data by the nodes.  On the other
= =      hand,= it does require the topology to be visible to every node that
= =      wants= to be able to identify unreachable nodes and therefore remove
= =      old, = stale data."

which = also appeared in the introduction, is copied verbatimly. Once
= = more, the statement is a claim which is not supported, and that = which
follows "therefore" is not a consequence of that which = comes before
"therefore".
Got rid of = duplicate.

Thanks



o Section = 5.4, first paragraph

"When a = Neighbor TLV or a whole node is added or removed, the
neighbor = graph SHOULD be traversed, starting from the local node.
= = = The edges to be traversed are identified by looking for = Neighbor
TLVs on both nodes, that have the = other node=E2=80=99s identifier in the
neighbor = node identifier, and local and neighbor endpoint
= identifiers swapped. Each node reached should be marked = currently
reachable."

= = First comment, why SHOULD and not MUST?
Retained this part, = there was a =E2=80=98lightweight=E2=80=99 node option that can do = it
without this; however, I = consider it non-interesting so changed to MUST.

OK, = thanks



Second comment, and now you made = me go look...."neighbor" sounds like
"someone = on the same link as me" so  the "neighbor graph" is really just
= = a set relating "this node" and "another node which is on the same = link
as this node".

Yet, = looking in the terminology, I see "Neighbor graph" defined as:
= = = = "the undirected graph of DNCP nodes produced by
          &nb= sp;     retaining only bidirectional peer = relationships
          &nb= sp;     between nodes.

= = Which doesn't sound as much like a "neighbor graph" as it does = a
"topology graph" for the whole network.

= = So, is the terminology wrong, or is the definition wrong?
Renamed to = =E2=80=9CTopology Graph=E2=80=9D - probably confusion of = non-native-speaking
authors.


=E2=80=A6and this reviewer, who also is a = non-native-english speaker. [We might have another language in common, = though=E2=80=A6?]

o Section 5.4, 3rd paragraph
= =
Is it actually important that the content of that graph = be "purged"?
That sounds like an = implementation detail -- rather, it sounds like
the = elements of the graph should "not be used for calculations and
= = MAY be removed". Or, is there a specific requirement that I am
= = missing?
Added lots of text; gist of it, basically, is = that unreachable nodes
SHOULD be removed and MAY = be removed immediately.

Yup, and = it is actually nice and clear that text.

o Section 6.1, I do not understand the parenthesis in this = sentence:

= Trickle-driven status updates (Section 5.1) provide a mechanism = for
handling of new peer detection (if applicable) on an = endpoint

Under = what conditions is that applicable, and under which is it not?
Actually always = now; removed (if applicable).

good.



o Section = 6.2:

"An upper bound for the number of = neighbors that are allowed for a
    (particular type of) link = that an endpoint runs on SHOULD be
    provided by a DNCP profile, = user configuration, or some hardcoded
    default in the = implementation."
  
   A couple = of things to that:
   1) Can you = explain the parenthesis? What type of link?
   2) How does "an endpoint runs on" a = link?
   3) Why SHOULD?
   4) Is this specification seriously = suggesting "some hardcoded
   default = in the implementation" as a SHOULD?

[I am = tempted to upgrade this to a "Major issue" simply because of 4) ] =    =
Clarified, the choice to use it is not really = visible externally. Now
the text has per = multicast-enabled link type constraints, and also
per-profile support for extension at = all.



= =
Also to 6.2, this particular optimization, do you have = any
quantification of its actual benefit? What should I look = for to
determine if this "optimization" yields a benefit or not? = What are
you trying to optimize? Over what = link types does this function?
I am = dubious that it "optimizes" much, if anything, across an Ethernet, for = example ...
Oddly enough, most link-state routing protocols = have this optimization.
Added further description = on why it is helpful.


So, the things = that you did to this, and the precious comment, helps. The =E2=80=9Cdesign= ated router=E2=80=9D (or equivalent/derivatives/*) mechanism is, as you = point out, well known and well used. I was yanking your chain a little = bit here to get, well, pretty much the explanation and discussion that = you gave. Thank you for that.

Nit, = though, just so that I feel useful in doing this:

OLD:
= MAY also be chosen at runtime.  Main consideration when = selecting 

= NEW:
MAY also be chosen at = runtime.  The main consideration when selecting 


But, good job = here.

o Section 7
As indicated previously, having = to search through the frame format
diagrams = for "how to calculate the value" isn't ideal.
Should be clearly = defined earlier now.

It = is.



o Section 7.2.3, I worry when I see = something like this:

"The = whole network should have roughly the same idea about the time
= = =  since = origination of any particular published state."

= = What is the definition of "roughly"?
Is the = "should" intentionally in non-caps?
What're = the consequences if not?
[Note that trickle almost = mechanically makes information propagate
with = non-trivial jitter across a network, so how do you ensure this?]
Clarified the = paragraph, since the original text could be interpreted
invertedly.


Another nit=E2=80=A6

Every node, including the = originating one

what is =E2=80=9Cthe = originating one=E2=80=9D, is it =E2=80=9C=E2=80=A6including the node = originating this TLV=E2=80=9D?

Otherwise, yes to your = clarification.



o Section 7.2.4, CUSTOM-DATA = TLV.

Given the description:
= = = "This TLV can be used to contain anything; the URI used should = be
 under = control of the author of that specification."

= = It seems that (i) the description is self-contradictory: it = cannot
contain *anything* but can contain an URI?
= =
Secondly, how is this supposed to work, what does it mean = [for DNCP]
that "the URI is under control of = the author"?

Thirdly, = what does "that specification" refer to?

= = Fourthly, why lower-case should? Indeed, why is the "control" of = the
URI of any importance to DNCP?
Removed, since it = had issues (besides being ambiguously defined). DNCP
profiles can define additional TLVs = easily.

Just to be = clear, you removed the whole TLV type? That=E2=80=99s fine by = me.



o Section 9, the bullet:
=
"When receiving messages, what sort of messages are = dropped, as
specified in Section 5.2"
= =
Seems at odds with Section 5.2, which discusses TLV = processing.
Unified terms to =E2=80=9Cignore=E2=80=9D, added = explanation mentioning security reasons


Good.




Nits:
  
= Requirement Language:
o Please reflect Errata 499 for = RFC2119 in the boilerplate

o The = RFC2119 boilerplate could conveniently be in the terminology
= = = section, given that it is terminology.


Both done.


Thanks. As I said, great job guys (and WG); IMO we=E2=80=99= re really close with this.

Cheers,

Thomas

= --Apple-Mail=_8AE078D4-BFBF-494A-B1CE-D41254A36386-- From nobody Tue Jul 28 09:07:06 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B831ACD6A; Tue, 28 Jul 2015 09:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 Fr2u5Anz0KEJ; Tue, 28 Jul 2015 09:07:05 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 03CEC1ACD60; Tue, 28 Jul 2015 09:07:05 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZK7P8-0006tl-TG with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Tue, 28 Jul 2015 18:06:59 +0200 To: Thomas Clausen References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> From: Steven Barth Message-ID: <55B7A8A1.50106@openwrt.org> Date: Tue, 28 Jul 2015 18:06:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "" , "homenet@ietf.org Group" , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 16:07:05 -0000 Hello Thomas, let me just quickly say, thanks again for your detailed reviews. Together with the others it helped us a great deal in advancing the draft to where it is today. We have put your HNCP-review and this follow up for DNCP on our todo, and will provide you with some detailed changes and replies once we are through. Though since this is post-IETF time we have to go through the piles on our desks and on top of that also holiday season, it will probably take some more time for the next revisions. Thanks, Steven From nobody Tue Jul 28 09:37:34 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3460A1ACE96; Tue, 28 Jul 2015 09:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_MY_NAME_IS=0.001, HTML_MESSAGE=0.001, 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 Virb1jnAdgSq; Tue, 28 Jul 2015 09:37:27 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961731ACE80; Tue, 28 Jul 2015 09:37:13 -0700 (PDT) Received: from DB3PR03MB299.eurprd03.prod.outlook.com (10.242.131.144) by DB3PR03MB0794.eurprd03.prod.outlook.com (10.161.55.139) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 16:36:52 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB299.eurprd03.prod.outlook.com (10.242.131.144) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 16:36:51 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0225.018; Tue, 28 Jul 2015 16:36:51 +0000 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" Thread-Topic: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4rozHs9zgL9Q6awOhnek/vb5w== Date: Tue, 28 Jul 2015 16:36:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tools.ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [109.66.1.206] x-microsoft-exchange-diagnostics: 1; DB3PR03MB299; 5:LuXU3qcBFkxCpaqMksnRLY9KxxecbQJde2LhOdgAWz1ljBaIkVXnCOxmQqnD1ftkFTywHZVmun1dxK/kAi2vd9OHq18pqg00X/EB179tiMp8KxL4ZmzMjMGkNSHd6KlisrjF6d4J8G7CPMoWzc42mw==; 24:+isdw1zhettUGkoNKUsxiHUjSqxBzub/Uj7xB+0NqUDkaGLlbxUxRETWgnQkJYRpAzMkvS2Y/vhfLQqsPXLuWOBkQGLg1lD/u7i3yi3qCGo=; 20:l7952jHuXANBn2vKaHunrOLaXu+3XWlcYW3REnQqnnV+hP1tt/+DDPVuhAEpS5PMCP8HZr+BofmD6Lwycd1sQw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB299; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0794; db3pr03mb299: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB299; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB299; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(377454003)(37854004)(51444003)(66654002)(122556002)(86362001)(2656002)(66066001)(2900100001)(19617315012)(19580395003)(87936001)(40100003)(54356999)(19300405004)(92566002)(555904002)(2351001)(50986999)(62966003)(46102003)(230783001)(189998001)(5003600100002)(110136002)(5002640100001)(16236675004)(77156002)(19625215002)(76576001)(5001960100002)(2501003)(19580405001)(77096005)(33656002)(102836002)(15975445007)(74316001)(7059030)(579004)(559001)(36394004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB299; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 16:36:51.5188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB299 X-Microsoft-Exchange-Diagnostics: 1; DB3PR03MB0794; 2:AxLS0cb3yHFJiQjue9bbyc16tbkxQITgAtfzOUp+6be4E5UTswYaqsmJOfFGz5op2bkhGTx1S9Weu9FNxuGhCJDGZzxrPXlVZ3zGiti4U+rFRBXlSR9LKZuuUjJB8PqLBjBCSuc+jBKsHrgdJEuAqpUGLgisPS9AIyqaf2UYR9c=; 3:3hT4y0Ct7H14Q6LETIspbbaOYEWTYNrRoT9dquiFG1ipsFg+U7i4+QvkeVsu9D0encu2jKy4MK4UMnNUccnLrBNhfjNgMBbCZA7pAD4y1PrsMXKmr9v127Eqh/44EE1abxzanCcCDxU4zs4Wa0abng==; 25:Kx7LkEtX0L+B9ZHGKGCzZSvNSmUTxrh/nXogiolAxGDjPpfvxiDGW7L1xsM0mCr0w7zW6T/fLe2TQkemaVGnmS0vqJpcZ8MpNoxoJgxm5PSiHG7e2YMvf+Ho3HuSpxDak1zgi5b4LJ4btKhPALra40XVo9Regv1OJSo/YoTF0+roZPgI6TcLDYpp1y9RzZ8sBRV44geRd+Fr657/m0/UMMe6EYYYycg5Il+937/RdaxlOsBKoZ5IgiZrnAxmZpF0PkhkBptxazvUw1e3+FEAFw==; 20:Lm0L75f5tG0oBF/sMl+4B0TgWWHk7eHajJB3ytwzJKvlqJwr8bY84fIGCfbZVg78d7gGHRV+96RYgZDt4tHzHw==; 23:XqzhgXKEF+GUsghdxYbxQ8oSxBJymT/k/ZivXFICPkGFLeRW608unbOneM7BFpaF+umbTVsJK1hmxTWeml+NyT5cn4qjp8C2NE//7f4s+DP/BKMd1eQCZrhI6DRyB2pyw+YSXSVv6vstrwGV0VrB+K0GMPweWnNnyX2POHn2xpOqN2kmtU/QABNNyBVi4L8l4kmHrWwJq3neiR2I8B8yEvjz3qxrvGkCiWBnCgpQjUrpuspSEWvCyBgOdubs68gZ DB3PR03MB0794: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: ecitele.com Archived-At: Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "Martin.Horneffer@telekom.de" , "bashandy@cisco.com" , "cfilsfil@cisco.com" , "mpls@ietf.org" , "edward.crabbe@gmail.com" , "igormilojevic@telekom.rs" , Jeff Tantsura , "bruno.decraene@orange.com" , "saku@ytti.fi" , "rob.shakir@bt.com" , "sprevidi@cisco.com" , Jonathan Hardwick , "jgs@juniper.net" , "wim.henderickx@alcatel-lucent.com" , "stephane.litkowski@orange.com" , Jon Hudson Subject: Re: [RTG-DIR] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 16:37:33 -0000 --_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My name is Sasha Vainshtein, and I have been asked to perform the QA revie= w of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing= -ldp-interop/. Due to health problems I have been very late (but, hopefully, not too late)= with this review, and here it is. Does the draft solves a real problem? From my POV, definitely yes. 1. The problem stems from the following combination of fa= cts fact that: a. LDP distributes labels for FECs represented by IP prefixes (among = other things). b. LDP-based MPLS network are very widely deployed c. SR operating over the MPLS DP allocates labels for SIDs that can r= epresent IP prefixes (again, among other things) d. As a consequence, LDP and SR may effectively map the same IP prefix= to different labels. 2. As SR using the MPLS DP is gaining acceptance in the i= ndustry, the following deployment scenarios look as realistic to me: a. Coexistence between LDP-based and SR-based control planes in the = same network b. Partial deployment of SR in some sub-domains of a network combined = with the operators' need to use the benefits of SR where it is already depl= oyed c. Gradual transition of services (especially L2 and L3VPN) tunnelle= d over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa) Is the draft a good enough start for a WG document? From my POV, yes. 1 The draft covers multiple (if not all) realistic use cases for co= existence of LDP-based and SR-based control planes and provides what looks= to me as reasonable solutions for these scenarios. 2 At the same I would think that additional work is required to com= plete the work. Specific issues with the current draft: 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are us= ed without expansion at the first use, and there is no "Abbreviation" secti= on in the draft. 2 Process/Editorial: The draft currently lists 12 authors on its ti= tle page exceeding the recommended RFC Editor maximum of 5 authors. 3. Technical: The draft does not analyse the use case of= coexistence between SR and LDP with enabled extension for multi-area LSPs = as per RFC 5283= . I think that this use case deserves special consideration in the draft be= cause: a. It mentions the use case of seamless MPLS and refers to the (expir= ed) Seamless MPLS Architecture draft b. The seamless MPLS Architecture draft, in its turn, explicitly refe= rs to RFC 5283 in Section 5.1.1 to facilitate binding of labels received vi= a the DoD LDP session while only default route is configured in the RIB of = the access node in the seamless MPLS architecture c. It is possible that this use case would not add anything to the dr= aft - but I would prefer to see it in the document with the appropriate exp= lanation 4. Technical: Section 8 "Manageability Considerations" is= currently left empty. When this section is written, I would expect at leas= t the following: a. Some level of detail regarding local policies defining whether LD= P-created or SR-created LSPs should be used etc. b. Discussion of using LSP Ping for LSPs that are produced by stitchin= g an LDP segment with an SR one. c. Alternatively, it is possible to move this section to a separate d= edicated draft 5. Technical: I think more information should be provided= in Section 5 to explain operational aspects of SR-assisted LDP FR: a. In Section 5.1 I would expect the draft to explain that: i. Node= D is selected as the RLFA using the same logic that is defined for select= ing RLFA in RFC 7490 ii. The "= bypass LSP" is set up by the SR CP automatically without any need for manag= ement intervention iii. I wou= ld like to understand why dynamically set up Targeted LDP sessions are an o= perational concern. Such sessions appear also when BGP-based auto-discovery= for L2VPN is used, and, according to the analysis in RFC 7490, the scalabi= lity problems associated with these sessions look as negligible. b. In Section 5.2 I would expect the draft to explain that: i. The = resulting solution is similar to using a bypass LSP to a manually selected = RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP sessi= on to such an RLFA would be still needed) ii. Set u= p of the "traffic-engineered bypass LSP" by the SR CP is triggered by an a= ppropriate management operation iii. What = information should be provided by the Management Plane for computing the RL= FA and the traffic-engineered bypass LSP? Should it be similar to configur= ation parameters used with RSVP-TE? iv. Which k= ind of logic should be responsible for computing the RLFA and the path to b= e taken by the engineered bypass LSP: should it be similar to the CSPF used= with RSVP-TE? v. How th= e traffic-engineered bypass LSP hat is set up by the SR CP would react to a= dditional changes in the network topology (the behaviour of the bypass LSP = that is set by RSVP-TE in these situations is well known). Neither of the issues listed above should be considered as preventing adopt= ion of the draft as a WG document IMO. Actually I think that resolving thes= e issues in the context of a WG document would be more effective. Hopefully these notes will be useful. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Wednesday, May 20, 2015 12:46 PM To: Alexander Vainshtein Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (aretana); Jo= n Hudson Subject: Routing directorate QA review of draft-filsfils-spring-segment-rou= ting-ldp-interop Hi Sasha Please would you be the routing directorate QA reviewer for draft-filsfils-= spring-segment-routing-ldp-interop? https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-= interop/ This initial review has been prompted by the spring WG chairs in parallel w= ith a call for WG adoption. As such, this document qualifies for "initial = QA review". Please could you provide your initial comments in the next 3 w= eeks? As per the QA process, we would also like you to stay with the docum= ent and review it again when it goes to WG last call. The following web page contains a briefing on the QA process, and guidance = for the QA reviewer. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Please copy your comments to the spring and rtgdir mailing lists. Please let me know whether you can do it, or not. Many thanks Jon --_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

My na= me is Sasha Vainshtein, and  I have been asked to perform the QA revie= w of https:/= /datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop= /.

 = ;

Due t= o health problems I have been very late (but, hopefully, not too late) with= this review, and here it is.

 = ;

Do= es the draft solves a real problem? From my POV, definitely yes.

   = ;       1.  = ;       The problem stem= s from the following combination of facts fact that:

a.  &nb= sp;    LDP distributes labels for FECs represented by IP prefixes (among oth= er things).

b.  &nb= sp;   LDP-based MPLS network are very widely deployed

c.  &nb= sp;    SR operating over the MPLS DP allocates labels for SIDs that can repr= esent IP prefixes (again, among other things)

d.  &nb= sp;   As a consequence, LDP and SR may effectively map the same IP prefix t= o different labels.

   = ;       2.  = ;       As SR using the = MPLS DP is gaining acceptance in the industry, the following deployment scenarios look as realistic to me:

a.  &nb= sp;    Coexistence  between LDP-based and SR-based contr= ol planes in the same network

b.  &nb= sp;   Partial deployment of SR in some sub-domains of a netw= ork combined with the operators’ need to use the benefits of SR where it is already deployed

c.  &nb= sp;    Gradual transition of services  (especially L2 an= d L3VPN) tunnelled over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa)

 

I= s the draft a good enough start for= a WG document? From my POV, = yes.

1  &nbs= p;      The draft covers multiple (if not all) realistic use c= ases for coexistence of LDP-based and SR-based control planes and provides  what looks to me as reasonable solutions for these scen= arios.

2  &nbs= p;      At the same I would think that additional work is requ= ired to complete the work.

<= o:p> 

Sp= ecific issues with the current draft:

1  &nbs= p;      Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are used without expansion= at the first use, and there is no “Abbreviation” section in th= e draft.

2  &nbs= p;      Process/Editorial: The draft currently lists 12 authors on its title page exceeding the recom= mended RFC Editor maximum of 5 authors.

&n= bsp;         3.  = ;       Technical: The draft does not analyse the use case  of coexistence between SR an= d LDP with enabled extension for multi-area LSPs as per RFC 5283. I think t= hat this use case deserves special consideration in the draft because:

a.=        It mentions the use case of seamless MPLS and refers t= o the (expired) Seamless MPLS Architecture= draft

b.=        The seamless MPLS Architecture draft, in its tur= n, explicitly refers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received via the DoD LDP session while only default rout= e is configured in the RIB of the access node in the seamless MPLS architec= ture

c.=        It is possible that this use case would not add anythi= ng to the draft – but I would prefer to see it in the document with the appropriate explanation

&n= bsp;         4.  = ;       Technical: Section 8 “Manageability Considerations” is currently left emp= ty. When this section is written, I would expect at least the following:

a.=        Some level of detail regarding local  policies de= fining whether LDP-created or SR-created LSPs should be used etc.

b.=       Discussion of using LSP Ping for LSPs that are produce= d by stitching an LDP segment with an SR one.

c.=        Alternatively, it is possible to move this section to = a separate dedicated draft

&n= bsp;         5.  = ;       Technical: I think more information= should be provided in Section 5 to explain operational aspects of SR-assis= ted LDP FR:

a.=        In Section 5.1 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    Node D is selected as the RLFA usi= ng the same logic  that is defined for selecting RLFA in RFC 7490

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    The “bypass LSP” is s= et up by the SR CP automatically without any need for management intervention

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    I would like to understand why d= ynamically set up Targeted LDP sessions are an operational concern. Such sessions appear also when BG= P-based auto-discovery for L2VPN is used, and, according to the analysis in= RFC 7490, the scalability problems associated with these sessions look as = negligible.

b.=       In Section 5.2 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    The resulting solution is similar = to using a bypass LSP to a manually selected RLFA that is set up by RSVP-TE (the difference is t= hat a Targeted LDP session to such an RLFA would be still needed)

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    Set up of the  “traffi= c-engineered bypass LSP” by the SR CP is triggered by an appropriate management operation

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    What information should be provi= ded by the Management Plane for computing the RLFA and the traffic-engineered  bypass LSP? = Should it be similar to configuration parameters used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        iv. &nbs= p;    Which kind of logic should be res= ponsible for computing the RLFA and the path to be taken by the engineered bypass LSP: should it = be similar to the CSPF used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          v.  = ;    How the traffic-engineered bypass = LSP hat is set up by the SR CP would react to additional changes in the network topology (the b= ehaviour of the bypass LSP that is set by RSVP-TE in these situations is we= ll known).

<= o:p> 

Neith= er of the issues listed above should be considered as preventing adoption o= f the draft as a WG document IMO. Actually I think that resolving these issues in the context of a WG document would be more effective.

&n= bsp;

Hopef= ully these notes will be useful.=

 = ;

Reg= ards,

Sas= ha

&nb= sp;

Office: +972-3= 9266302

Cell:  &= nbsp;   +972-549266302

Email:  = Alexander.Vainshtein@ecitele.com

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswit= ch.com]
Sent: Wednesday, May 20, 2015 12:46 PM
To: Alexander Vainshtein
Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (areta= na); Jon Hudson
Subject: Routing directorate QA review of draft-filsfils-spring-segm= ent-routing-ldp-interop

 

Hi Sa= sha

 = ;

Pleas= e would you be the routing directorate QA reviewer for draft-filsfils-sprin= g-segment-routing-ldp-interop?

https://datatracker.ietf.org/doc/draft-filsfils-sprin= g-segment-routing-ldp-interop/

 = ;

This = initial review has been prompted by the spring WG chairs in parallel with a= call for WG adoption.  As such, this document qualifies for “initial QA review”.  Please could you provide your initi= al comments in the next 3 weeks?  As per the QA process, we would also= like you to stay with the document and review it again when it goes to WG = last call.

 = ;

The f= ollowing web page contains a briefing on the QA process, and guidance for t= he QA reviewer.

htt= ps://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 = ;

Pleas= e copy your comments to the spring and rtgdir mailing lists.

 = ;

Pleas= e let me know whether you can do it, or not.

 = ;

Many = thanks

Jon

 = ;

 = ;

--_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_-- From nobody Wed Jul 29 05:03:13 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58651A8874; Wed, 29 Jul 2015 05:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OCm-thWqHAiW; Wed, 29 Jul 2015 05:02:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6A51A8870; Wed, 29 Jul 2015 05:02:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F08A01C0189; Wed, 29 Jul 2015 05:02:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CEF5C1C0070; Wed, 29 Jul 2015 05:02:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2732A1FC-D0D0-4DB7-AA21-2F49CA9A3B1F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Thomas Clausen In-Reply-To: <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> Date: Wed, 29 Jul 2015 14:02:54 +0200 Message-Id: References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "" , Steven Barth , "homenet@ietf.org Group" , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 12:03:11 -0000 --Apple-Mail=_2732A1FC-D0D0-4DB7-AA21-2F49CA9A3B1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 29, 2015, at 13:06, Markus Stenberg = wrote: >=20 > First of all, thanks a lot again for review comments; I think you are = the most critical reviewer we have had yet, and it helps to improve the = document quality a lot :) I *was* starting to worry if I needed to take out armed protection, = simply due to the sheer volume of my comments appearing as a =E2=80=9Cla= te assault=E2=80=9D :D I am thrilled that I didn=E2=80=99t need to, and = that to the contrary you really reflected them well in the spec. > We have had a number of reviews by this point, but I believe you have = raised order of magnitude more changes than the second in line who also = lives in Paris; is this a coincidence? I think not. Fun that you should mention it. I think that the person you refer to, = and I, while we=E2=80=99re based in the same area, never actually have = seen each other (despite repeatedly planning for it) in or around Paris. = So rest assured, it=E2=80=99s not a =E2=80=9Cgeographic conspiracy=E2=80=9D= afoot here ;) > Anyway, on to comments.. >=20 > Caveat: These are my comments, Steven is likely to fix typos before we = actually hit publish button on -09 :) >=20 > Executive summary: Minor edits, but as you are good with words, time = to ask for advice - how would you explain =E2=80=9CEndpoint=E2=80=9D in = the terminology? (Anyone else on the list too, feel free to chime up..) >=20 Actually, when doing my review I tried if I could come up with some text = that I would thing worked =E2=80=94 which, if I had succeeded, I=E2=80=99d= have been throwing it at you saying =E2=80=9C=E2=80=A6but this would = make me happy=E2=80=9D. I didn=E2=80=99t come up with something that I actually liked. So = instead, you get my random thoughts =E2=80=A6=20 > Fact: It is not socket. I consider it essentially bidirectional = mapping between an endpoint #, and some transport details (as it is used = for both receiving and sending traffic). I guess I am troubled by having seen the terminology =E2=80=9Ca socket = is an endpoint for communication=E2=80=9D and =E2=80=9Ca connection is a = pair of sockets=E2=80=9D =E2=80=94 taking from Wikipedia (which is not a = source for anything but =E2=80=9Cwhat is commonly used, even if = incorrectly - but, as such, is a good way to understand =E2=80=9Chow = many people would misunderstand in the same way"): "A network socket is an endpoint of an inter-process = communication across=20 a computer network. Today, most communication between computers = is=20 based on the Internet Protocol; therefore most network sockets = are Internet sockets." Now, I am of course also troubled by the recursive definition of = endpoint in the I-D: Endpoint: a locally configured communication endpoint of a DNCP = node, such as a network socket. > Random examples from existing implementations: >=20 > - _a rule_ that matches that stuff from ::1 is endpoint #1 (on shared = socket) > - _a rule_ that we try to contact 2001:db8::1 and denote it as = endpoint #2 (on shared socket) > - a socket which is bound to eth0 + port X, and listens to multicast = there, denoted as endpoint #3 > - (shared socket on port Y) which is listens to eth1 multicast (and = also deals with eth1 link-local unicast traffic), denoted as endpoint #4 >=20 So that sounds a little bit like (for the 2nd bullet) that it=E2=80=99s = (in part) a =E2=80=9Cconnection=E2=80=9D (the =E2=80=9Cwe try to contact = =E2=80=A6.=E2=80=9D part)? > The current text-monster is as follows: >=20 > Endpoint a locally configured communication endpoint of a DNCP = node, such as a network socket. An endpoint may be bound to a set of = predefined unicast Addresses representing remote DNCP nodes to = individually connect to or to accept connections from whereby = communication with each node is separated (e.g., an individual unicast = UDP message flow per remote node). An endpoint may also be bound to a = whole network interface, then multicast communication is used (in = addition to individual unicast flows) to send certain messages to all = DNCP nodes connected therewith at once as well as to automatically = discover new DNCP nodes. Endpoints are usually in one of the transport = modes specified in Section 4.2. >=20 > On 28.7.2015, at 18.45, Thomas Clausen wrote: >> Authors, for all the points where I have said =E2=80=9Cfine=E2=80=9D, = if you reply to this mail feel free to cut those points out and retain = only outstanding issues. >> OK; on a personal-preferences level, the separation between HNCP and = DNCP seems artificial, and it probably is part of the reason why this is = hard to describe. I probably would not have made that separation myself = =E2=80=94 but I am not suggesting that the WG goes back on that decision = (just to be clear), rather that it be called out. >>=20 >> I can live with what is there. >=20 > I think the separation makes sense (as DNCP itself is generic = algorithm, more or less); however, the point of separation I am not so = sure about (e.g. concrete TLVs in DNCP feel bit wrong, but there are = reasons for that too; easier to specify DNCP-based protocols). As I said, I am not suggesting to go back on that decision =E2=80=94 so = we can have that discussion somewhere away from the ears of the ADs some = other time ;) >>> We reorganised the document a bit, wrote a better abstract and >>> introduction and provided a =E2=80=9CProtocol Overview=E2=80=9D = section, on top of that >>> we reorganised the details in an =E2=80=9COperations=E2=80=9D = section. >>=20 >> OK; I am a good deal more happy now, although not perfectly happy = just yet.=20 >>=20 >> I still think that it would be fantastic to have an applicability = statement included. Reading the document without any context [as it = might down the line if it was to become an RFC], it=E2=80=99s hard to = understand if =E2=80=9Chey, I have a problem, is DNCP the right lump of = metal to use to make a hammer for it?=E2=80=9D >=20 > Adding one in -09; however, it is still undergoing edits. Gist of it = is to look at=20 >=20 > [1] min (keepalive-interval-if-nonzero, churn frequency * number of = nodes) and compare it to Trickle parameters chosen > [2] consider amount of TLV change within TLV sets published by nodes = (large set, small changes =3D> may not be the best protocol for the job = due to lack of per-TLV deltas) Sounds good. >> As I said in my original review, I think that this is a matter of = scoping the work right. The abstract, and the into, calls out =E2=80=9Ca = generic state synchronization protocol=E2=80=9D =E2=80=94 I=E2=80=99ve = heard OSPF described as such, also (hi Fred!) =E2=80=94 which sounds = very much like =E2=80=9Cboiling the ocean=E2=80=9D, and which I think = the WG is not trying to actually do. >=20 > WG isn=E2=80=99t, but we wound up doing one anyway. Still, we=E2=80=99re= adding applicability subsection in 09, as I think it is important to = note that DNCP is _not_ the tool for many things. Great, sounds like we=E2=80=99re perfectly aligned here, and I look = forward to seeing the text. >=20 >> Why don=E2=80=99t you put a subsection before the last paragraph of = the Introduction =E2=80=9CApplicability=E2=80=9D and then expand on = that? >=20 > Addressed above. >=20 >> I just want to note that I enjoyed the expanded terminology - thank = you! There may be a small formatting snafu, at least in the HTML = version, about missing blank lines between (for example) =E2=80=9CAddress=E2= =80=9D and =E2=80=9CEndpoint=E2=80=9D >=20 > Hopefully fixed. >=20 >> Going back and looking at that, does it make sense to talk about = =E2=80=9CDNCP network=E2=80=9D, out in the real world, or just in this = document? >>=20 >> An HNCP network and a TNCP network (that=E2=80=99d be for "Thomas' = Neat Configuration Protocol=E2=80=9D) sure, and such two could co-exist = (but not interoperate) so while they =E2=80=9Cin the abstract=E2=80=9D = would both be instances of DNCP networks, that=E2=80=99d be an abstract = construction altogether. >>=20 >> Could I suggest that to the definition of =E2=80=9CDNCP network=E2=80=9D= some verbiage to that effect be added? >=20 > NEW: a set of DNCP nodes running DNCP-based protocol(s) that have = matching DNCP profile. >=20 > The side effect is that if DNCP profiles match, essentially transit = service is provided even if the implemented protocol is not same. (e.g. = HNCP + SHSP currently.) And that *sounds* right and *sounds* as if it is by design, so that=E2=80=99= s great. >=20 >> Now we=E2=80=99re at tightening up on terminology, I am finding = myself wondering about =E2=80=9CDNCP profile=E2=80=9D and =E2=80=9CDNCP-ba= sed protocol=E2=80=9D as terms, just a little. >>=20 >> A DNCP profile is=20 >> a definition of the set of rules and values >> defining the behavior of a fully specified, >> implementable protocol which uses DNCP. The DNCP >> profile specifies transport method to be used, >> which optional parts of the DNCP specification = are >> required by that particular protocol, and various >> parameters and optional behaviors. In this >> document any parameter that a DNCP profile >> specifies is prefixed with DNCP_. Contents of a >> DNCP profile are specified in Section 9. >>=20 >> Could we be a little bit more succinct: >>=20 >> =E2=80=9CA DNCP profile consists of: >> o The values for the set of parameters, = given in section 9. >> o The set of optional parts of this = specification, which are to be used.=E2=80=9D >=20 > Adopted the gist of it, although not going to convert to a list (and = retained DNCP_ note as it is useful to understand DNCP_foo coming up = shortly in the next few things). >=20 Yes, the DNCP_ note should be retained. My bad for *not* doing that, = thanks for catching it. > NEW: > DNCP profile consists of the values for the set of parameters, > given in Section 9. They are prefixed with DNCP_ = in > this document. It also specifies the set of > optional parts of this specification, which are to > be used. >=20 Works for me. >=20 >> For DNCP-based protocol, the doc says: >>=20 >> A DNCP-based protocol is: >> a protocol which provides a DNCP profile, and >> potentially much more, e.g., protocol-specific = TLVs >> and guidance on how they should be used. >>=20 >>=20 >> Could we be more precise (than =E2=80=9Cpotentially much more=E2=80=9D)= on =E2=80=9CDNCP-based profile=E2=80=9D >>=20 >> =E2=80=9CA DNCP-based protocol is: >> o A DNCP profile, according to Section 9, >> o Zero or more TLV assignments from the = registries set up by this specification >> o generation and processing rules for = these TLVs >=20 >=20 > NEW: > DNCP-based protocol a protocol which provides a DNCP profile, = according to Section 9, and zero or more TLV assignments from the DNCP = profile-specific TLV registry as well as their processing rules. >=20 Works. >> On the definition of =E2=80=9CAddress=E2=80=9D: >>=20 >> o What does it mean to be =E2=80=9Crelatively transport = agnostic=E2=80=9D? I=E2=80=99d=20 >> say that it=E2=80=99s a little bit like being = =E2=80=9Crelatively pregnant=E2=80=9D =E2=80=94 either you are, or you = are not? >=20 > Got rid of some relatively=E2=80=99s. >=20 ;) >> o Why not define an =E2=80=9CAddress=E2=80=9D as = (IPv6-address, Transport, Port)? >> (and then, if someone comes along with something that = doesn=E2=80=99t fit that tuple form >> down the line, deal with it then?) >=20 > I am not sure it would help as such. The addressing may also occur = inside transport - think multiple flows multiplexed over single stream = connection, for example. Or local UNIX domain sockets :) OK, but now I am back to being confused =E2=80=94 how does =E2=80=9Cmultip= le flows multiplexed over single stream connection=E2=80=9D, = =E2=80=9Caddress=E2=80=9D and =E2=80=9Cendpoint=E2=80=9D then fit = together? >=20 >> Address, by the way, uses =E2=80=9Cendpoint=E2=80=9D which is defined = below.=20 >=20 > Transport protocol endpoint and DNCP endpoint are not neccessarily the = same thing. They may have 1:1 relationship, but also 1:N (or possibly = M:N) are possible. Got rid of endpoint in the new definition. >=20 > NEW: >=20 > Address an identifier which specifies how to reach a particular = instance of a transport protocol on a particular node. In case of an = IPv6 UDP transport, an address in this specification refers to a tuple = (IPv6 address, UDP port). *mumble* - Let me give this whole part some thought, and see if I can = come up with something constructive to say on this point (other than = =E2=80=9Cnot sure that that=E2=80=99s clear=E2=80=9D). >> Endpoint, then, ends up being defined almost as an =E2=80=9Caddress=E2=80= =9D *except* that there=E2=80=99s the clause =E2=80=9Cmay be bound to a = set of predefined unicast addresses=E2=80=9D [would those be addresses = as previously defined?] >>=20 >> When I read =E2=80=9CEndpoint=E2=80=9D I end up simply thinking = =E2=80=9CSocket, expressed as (IPv6-address, Transport, Port)=E2=80=9D = but as that was defined above it can=E2=80=99t be it?=20 >>=20 >> Could you clear that up, please? [Note, it=E2=80=99s better than the = -05, but still confusing] >=20 > I am not sure how. There has been literally half dozen iterations so = far. I am not sure I like the current one, as it is overly verbose and = apparently not much closer to the goal. >=20 > (see top) Yup. Needs some thought here. I=E2=80=99ll peg that as a todo; if we end = up with that as the only outstanding point, and we=E2=80=99re no closer = to an alternative, then the conclusion could be =E2=80=9CThomas is just = too dense to understand this=E2=80=9D, which I trust that the ADs would = be comfortable with.=20 >>>> Major Issues: >>>> =09 >>>> o The introduction does not read well; it contains parts = of something that >>>> could be considered as part of an applicability = statement (without it >>>> being called out as such, and without forming a complete = applicability >>>> statement), and does not actually introduce the = protocol. Reading just >>>> the introduction and the abstract, it is very obscure if >>>> this is a framework, a protocol, a building block, an = architecture, an >>>> algorithm -- and, if either of those, what it is = actually accomplishing, >>>> and why one would chose to use DNCP. It does, however, = transpire that >>>> "whatever it is", it has two "modes" and that it = requires something >>>> (presumably a routing protocol) to provide each "node" = with a topology >>>> map. >>>> =09 >>>> Suggest that a proper introduction consisting of three = parts would be >>>> beneficial: (i) what this document is, (ii) what doing = DNCP actually >>>> gets you, and (iii) the operating conditions under which = the >>>> DNCP is applicable. >>>> =09 >>>> On the latter point, given that you state that DNCP = requires profiles >>>> to provide "actual implementable DNCP based protocols", = it appears >>>> important to understand what the limits for "what a = profile can give >>>> you" are. >>>> =09 >>>> I am calling this out as a major issue, since I believe = that it is >>>> not just editorial, but is a matter of scoping this = document correctly, >>>> and in particular not falling into the trap of "claiming = applicability >>>> where it's not". >>>=20 >>> As noted earlier, the introduction has been reworded and separated = from >>> protocol overview also considering your suggestions. >>=20 >> So this is good, thank you for doing that effort =E2=80=94 it=E2=80=99s= tedious, but it helped. >>=20 >> To section 3, therefore, a few suggestions: >>=20 >> 1) Throw an initial paragraph in stating what DNCP does = =E2=80=9Cstate synchronization=E2=80=9D and all that. >=20 > As this comes after the intro (which does that), I am not sure I agree = with the need. Do you suggest cut-n-paste, or something new here? Well, =E2=80=9CA TLV-based distributed state synchronization protocol, = DNCP operates primarily using unicast exchanges=E2=80=A6=E2=80=9D as the = first sentence would really do it for me. >=20 >> 2) =E2=80=9CDNCP discovers the topology of its nodes and = =E2=80=A6=E2=80=9D >> Argh=E2=80=A6almost there =E2=80=9Cits nodes=E2=80=9D? >> - would that be =E2=80=9Cthe nodes in the = DNCP network=E2=80=9D (which has been defined=E2=80=A6)? >> - you=E2=80=99re discovering the topology = (i.e., you actually produce a topology graph?) >> or just the presence or absence of nodes = in the network (i.e., a destination list)? >> Just state what you do, and it=E2=80=99ll be good. >=20 > Using the first suggested text. Of course, this =E2=80=99topology=E2=80=99= may be somewhat misleading too as we do not really necessarily have = low-level topology, but just connectivity among DNCP nodes. *sigh* >=20 > (In point-to-point case, there may be arbitrary number of hops in the = middle DNCP is blissfully unaware of.) That works. >=20 >> 3) =E2=80=9Cbidirectionally reachable=E2=80=9D =E2=80=94 = call out if that means =E2=80=9Cover one IP hop=E2=80=9D (as in =E2=80=9Co= n the same link=E2=80=9D) >> or if it can be =E2=80=9Cbidirectionally reachable, = possibly through a multi-hop path=E2=80=9D >>=20 >> Actually, why don=E2=80=99t you define that term in the = terminology section, since it appears also >> in section 4, and it=E2=80=99d make me go away with this = comment in more places than one ;) >=20 > Hmm. Given we leave actual transport out, I am not sure how it could = be over one IP hop. >=20 > Anyway, added a definition (not cut-n-pasting here so Steven has time = to fix it, cough). >=20 OK, I=E2=80=99ll wait to see what comes >> 4) =E2=80=9CA hash tree is maintained by each node=E2=80=9D = =E2=80=94 I=E2=80=99ve thought about that, and I think that you may >> want to expand a little more. =E2=80=9CA hash tree, = rooted in itself, is maintained by each node=E2=80=9D? >> 5) And then, again, the text is almost there, bit just need = a nudge=E2=80=A6how is the tree constructed? >> You start fine =E2=80=9Ca node starts with a hash tree = only consisting of itself=E2=80=9D. >> Then it announces that, and gets updates. How are those = =E2=80=9Cintegrated=E2=80=9D into the receiving nodes=E2=80=99 >> hash tree.=20 >> Yes I know how it=E2=80=99d work out (I may be dense, = but not *that* dense ;) ), but I think that it=E2=80=99d be=20 >> easy to capture all here and being complete, since = it=E2=80=99s so close. >>=20 >> By the way, I would state that the hash tree is height 1 in this = section, and add a forward reference to 4.1. >=20 > Added some forward refs, and updated the text. >=20 > A hash tree of height 1, rooted in itself, is maintained by each node = to represent the state of all currently reachable nodes (see Section = 4.1) and the Trickle algorithm is used to trigger synchronization (see = Section 4.3).=20 >=20 Awesome, clear now. >> Section 4, I really like what you have done with it also. As a purely = subjective matter, could there between 4 and 4.1 be some educational = text that describes how the 6 subsections to 4 =E2=80=9Cfit together=E2=80= =9D? As it is right now, it=E2=80=99s a little abrupt. >>=20 >>>> o The document, in my understanding, defines an exchange = format with >>>> limited ability to evolve, as simply "a steam of TLVs". >>>>=20 >>>> As long as there's never a need to evolve the TLV format = itself, and >>>> as long as you do not run out of TLV types, that's not = going to be >>>> a problem. The doc sets aside a 16bit TLV type space, = that's reasonable >>>> enough, but I worry if eventually a DNCPv2 will need to = evolve the >>>> format. One purely hypothetical example could be if a = "sequence number" >>>> would be needed in each DNCP message to detect "link = success rates", or >>>> something of that sort. >>>=20 >>> I think on this front we have to agree to disagree; as it is a = stream of >>> _unrelated_ TLVs with some rare exceptions (node endpoint ID =3D> = network >>> state), a later spec such as DNCPv2 can specify if it wants to that >>> every DNCP 'message' contains TLV of type $FOO and uses disjoint set = of >>> TLVs to do X. Hell, we do that in HNCP already. >>>=20 >>=20 >> OK, then, in that case what you call a TLV is what I would call a = =E2=80=9CMessage=E2=80=9D =E2=80=94 fair enough, I can do that mental = substitution. >>=20 >> Now=E2=80=A6that still doesn=E2=80=99t change the fact that you may = end up having to evolve your Message format =E2=80=94 I=E2=80=99m sorry, = your TLV format =E2=80=94 as it appears on the wire, as well as some of = the behaviors that you exhibit through DNCP processing. >>=20 >> For that, you=E2=80=99ll need a version number. And again, I am = sorry, I cannot come up with a concrete example and =E2=80=94 again =E2=80= =94 that=E2=80=99s part of the dilemma: a future extension that we have = not thought about is, by definition, a future extension that we have not = thought about and so therefore we can=E2=80=99t predict if it will be = interoperable with a what we have now. >=20 > TLV space is relatively large, and mostly undefined. I still do not = see the problem. >=20 > I see much more of a problem defining e.g. 4 byte version thing, = because after that speaking =E2=80=98both versions=E2=80=99 of the = protocol becomes hard. >=20 Alright, I=E2=80=99ll peg that as issue #2 that needs an isolated = discussion and where the ADs may have to decide that I am in the rough = (which is fine) if needed. I just observe that I=E2=80=99ve seen a = strong move in other contexts in the IETF for =E2=80=9Cversion = numbers=E2=80=9D so I would expect that to become an issue here also. >>>> I do not have an actual example in mind -- and that's = exactly the point: >>>> to be evolutive for the unknown future and (at the very = least) be able >>>> to discriminate between "old" and "new". >>>> =09 >>>> A discussion could be had if a "version number" in each = TLV would do, >>>> or if a concept of "protocol message with a version = number" is >>>> preferential. I do not believe, however, that "no = version number" is >>>> viable. >>>=20 >>> Since DNCP is an abstract protocol, a concrete protocol on top of it >>> might probably want to do versioning for its own purposes (i.e. >>> different versions on top of the same DNCP version). In this case = having >>> versioning in both DNCP and the derived protocol serves little = purpose. >>> HNCP - as first derived protocol - defines a Version-TLV btw. >>=20 >> Yes but that is a =E2=80=9Cversion TLV=E2=80=9D =E2=80=94 what = happens if the TLV format itself, or some of the DNCP specific = processing. >>=20 >> This, incidentally, goes to the crux of why I =E2=80=94 personally = =E2=80=94 would not have done the split. Had DNCP *exclusively* been an = algorithm, or such, then I could see not needing a version in DNCP, but = in the DNCP-based protocol (HNCP) only. Or, for that matter, had DNCP = been just a frame format with no processing, or something, then I could = see one sequence number sufficing. >>=20 >> By DNCP being = part-signals-part-procesing-part-behavior-part-framework, which cannot = exist on its own but which requires =E2=80=9Canother protocol which = profiles it and which also defines its own signals, processing, and = behavior=E2=80=9D, yes, you actually having this =E2=80=9Cversion number = conundrum=E2=80=9D. >=20 > Why? The concrete DNCP-based protocol actually says what it supports, = and e.g. future DNCP extensions are not implicitly part of HNCP, unless = we specify them to be. It=E2=80=99s always hard to speculate on extensions, so =E2=80=A6 this = may sound silly. Say we wanted DNCPv2 to, for some reason, not use TLVs but use LVTs, or = that it redefined the way of calculating the Network State / Node State = =E2=80=94 for some reason. For the LVT-option you=E2=80=99d be screwed = ;) for the =E2=80=9Cnew way of calculating Network State / Node State=E2=80= =9D you=E2=80=99d say =E2=80=9Cdefine a new TLV type=E2=80=9D? I=E2=80=99d imagine that a DNCPv2, or perhaps a device using DNCPv2, = would somehow be able to maintain a =E2=80=9Cbackwards compatible = mode=E2=80=9D, say, if I see DNCPv1-based protocols hanging around, then = I=E2=80=99d probably fall back to use those, but if I don=E2=80=99t then = I=E2=80=99d want to use the new-fancy DNCPv2-based protocols (which = might use some of the same TLVs, but use them differently). I think that you=E2=80=99re shooting yourself in the foot here. >=20 >> You could not fix all this by having a DNCP version number only, but = having a sufficiently large TLV type space? That way, you=E2=80=99d not = need (say) HNCP version numbers, but a HNCPv2 would use TLV types A, B = and D (but not C) from HNCPv1, and would reserve and define TLV types X, = Y, Z ? >=20 > HNCP has 2^16-few types to play with. Is that not enough? >=20 > (Only up to 32 and the local tinkering range are excluded from the = DNCP profile specific registry HNCP will set up. However, conflicts in = handling the 256+ range are currently being considered on how they = should be handled.) Proposal=E2=80=A6.you say that you have a large TLV type space so = =E2=80=A6.why don=E2=80=99t we set aside the first two bits in the TLV = type field, call that =E2=80=9CVersion=E2=80=9D, and define =E2=80=9Cif = both are cleared, then it means this specification, DNCPv1" and then = have 2^14 =E2=80=9CTLV types=E2=80=9D =E2=80=94 with a potential for 4 = DNCP =E2=80=9Cversions=E2=80=9D? Then, we take an appointment in 15 years time. If by then we still have = not found a reason to flip either of these two version bits, then (i) we = write an =E2=80=9CUpdates DNCPv1=E2=80=9D RFC which reassigns that field = as =E2=80=9C16 bit TLV Type=E2=80=9D, and I buy lunch =E2=80=94 = otherwise, lunch is on you?=20 ;) >=20 >>>>=20 >>>> o Noting that the "overhearing n reduncant transmissions" = is a key >>>> retransmission suppression mechanism in Trickle, and = that this >>>> seems to assume broad/multicast, using unicast seems to = contradict >>>> the statement of "consists of Trickle", at least in the = way the >>>> algorithm is defined in RFC6206. Note: it's fine to use = an algorithm >>>> outside of its initial scope, but it should be with the = caveat of >>>> "which of the characteristics still hold, and which do = not" >>> If k < 2, even on point-to-point link, Trickle does reap benefits = and >>> provides exponential backoff timer. Obviously, we can spell this out >>> more explicitly if it helps. >> YES, that sort of explanation would be good. >=20 > Added that to the applicability subsection too. (Pending Steven check, = *grin*) >=20 Great >>>> o Section 5.3, penultimate paragraph: >>>> =09 >>>> "If keep-alives specified in Section 6.1 are NOT = sent by the peer >>>> (either the DNCP profile does not specify the use = of keep-alives or >>>> the particular peer chooses not to send = keep-alives), some other >>>> means MUST be employed to ensure its presence. = When the peer is no >>>> longer present, the Neighbor TLV and the local DNCP = peer state MUST >>>> be removed." >>>> =09 >>>> "...some other means MUST be employed to ensure its = presence." -- >>>> followed by more MUST verage when a peer disappears...I = am not sure that >>>> that's conductive to interoperable implementations. >>>> =09 >>>> Two implementatons may chose different "means" and then = turn off keep- >>>> alives - and be non-interoperable. >>>> =09 >>>> For interoperability, we need: >>>> =09 >>>> o A mandatory to implement = mechanism, that always is >>>> present, but can be complemented = by another "means", or >>>> =09 >>>> o A mandatory to implement = mechanism, which by way of a >>>> specified negotiation mechanism = can be turned off between >>>> two peers, to allow them to use = another "means". >>>> =09 >>>> If you argument is "...this will be specified in the = profile", then >>>> you still should provide the two above in this document, = with the note >>>> that "...and a profile may specify which from among = these MUST be >>>> used in a given deployment" >>>=20 >>> Clarified that =E2=80=9Cother means=E2=80=9D, refers to existing = transport-provided >>> mechanism, e.g. Ethernet carrier-detection, TCP keep-alives etc. >>=20 >> Alright, good. Now where is it specified which is to be used? Is that = part of the profile, or should it be? If so, call that out here. >>=20 >> I=E2=80=99m trying to avoid interoperability issues, for example if I = am using =E2=80=9CTCP keep-alives=E2=80=9D and you are using something = else, can we work together? If this is not a problem, call that out as = something which a device can do as it sees fit (although, for example. = TCP keep-alives presumably expects TCP which is a profile matter =E2=80=A6= ) >> I *think* that we are almost there also with this point, so convince = me that the text there won=E2=80=99t cause interoperability issues? = Hiving it off to a profile to specify would do just that (of course, = I=E2=80=99d come back on that in HNCP, instead ;) ). >=20 > This (like many other things in the spec actually) are local = implementation choices; the MUST is that _a method_ must be used (if no = keep-alives are used). >=20 > However, to cover the case without any method available, added = following: >=20 > If the peer does not send keep-alives, and no means to verify > presence of the peer are available, the peer MUST be considered = no > longer present and it SHOULD not be added back as a peer until = it > starts sending keep-alives again. >=20 That seems to work for me. Thanks > .. omitted security stuff. >=20 >>>> Minor Issues: >>>>=20 >>>> Introduction: >>>> o 1st paragraph: "reachable nodes"; two things: >>>> =09 >>>> - I always have a problem with the = term "node"; it is often >>>> used as a shorthand for "routers = and hosts, both". I was >>>> given to understand that homenet = specifically did not want >>>> to consider host changes? >>> DNCP is not strictly speaking about homenet (but a strict = requirement >>> for HNCP which is). Also even in homenet-case non-routers may join = the >>> network temporarily in order to e.g. do monitoring. >>=20 >> But, would those =E2=80=9Cnon-routers=E2=80=9D not speak at least = part of the =E2=80=9Chome net specific protocols=E2=80=9D and thereby = not be =E2=80=9Chosts=E2=80=9D in the =E2=80=9Cgot them from Best Buy = and just clicked OK=E2=80=9D sort of sense?=20 >>=20 >> So is the crux that we have =E2=80=9Chomenet-aware devices=E2=80=9D = and =E2=80=9Clegacy hosts=E2=80=9D, and that either of us just need to = get with the program? If so, can I insist (gently) on =E2=80=9Chomenet-awa= re devices=E2=80=9D [with a suitable definition] instead of =E2=80=9Cnodes= =E2=80=9D since =E2=80=9Cnodes=E2=80=9D are such an overloaded term that = it=E2=80=99s not even fun any more. >=20 > Again, this has nothing to do with homenet, but it=E2=80=99s being = pushed in homenet just because it is strict dependency on HNCP. >=20 > There is already one existing use of DNCP which is very non homenet, = demoed in IETF93 BnB and presented in the WG; I expect there might be = more if we do not make the spec overtly homenet-y. Ok, being general where it makes sense is good. We=E2=80=99ll take this = discussion in HNCP, then. >>>> - "Reachable" - does that mean = something as in "radio range", >>>> does it mean "on the same link", = does it mean within a >>>> specific (DNCP?) domain, or does = it mean simply "on the >>>> Internet somewhere"? >>> Clarified in the text as =E2=80=9Cbidirectionally reachable=E2=80=9D, = also added >>> fwd-references to actual definition. >> Suggest also defining in Terminology, and clarifying if this is a = one-hop, or a multi-hop-within-the-homenet, concept. In section 1, I do = not see a forward reference, btw, at least not in latest rev. >=20 > Added rather verbose description. ;) >=20 >>>=20 >>>> =09 >>>> o DNCP network: I read this twice, and came away = with two different >>>> understandings, perhaps you can clarify which it = is: >>>>=20 >>>> o A set of nodes running DNCP, = within the same domain, and >>>> for which a path betwen any two = DNCP nodes includes only >>>> other DNCP nodes; i.e., a DNCP = network forms a connected >>>> component with only other DNCP = nodes. >>>> =09 >>>> o A set of nodes running DNCP. = They may be anywhere on the >>>> Internet, they are part of the = same DNCP network as long >>>> as they (through other means) = have learned of each others >>>> addresses. >>>> =09 >>>> In the former, that'd be (for example) a = deployment within my >>>> home -- in the latter, it could be a node in my = home and a node in >>>> your home forming a DNCP network. >>>> =09 >>>> The text is not quite clear on this point. >>> Both are valid use cases; hopefully clarified. >> OK, sadly you clarified it ;) Well, no, not sadly, but you clarified = it to be understandable to me in the above sense. But, if I come up with = the aforementioned TNCP and I use the same transport as HNCP, would a = TNCP and a HNCP node be on the same DNCP network, then? >=20 > Yes. E.g. SHSP and HNCP share transport, but are ships passing each = other in the night as far as understanding TLVs go. (And unwittingly, = they proxy each other=E2=80=99s state.) OK, with the proposed text somewhere up above in this email, this is = clear =E2=80=94 so that works for me also. >>>> o Link: a point of clarification here. In "DNCP = network", there was >>>> talk about "unidirectional links" and = "bidirectional links"; in >>>> "Link" the definition is somewhat vague = "directly connected" and >>>> "can communicate". Could something like "without = decrementing TTL/ >>>> hop-count" be added, and could a statement on = bidirectionality >>>> (IOW, that this is just an IP link) be added? >>> This isn=E2=80=99t IP specific as such; however, some better = definition is >>> welcome. some types of IP links are not strictly bidirectional = either >>> (hello, mesh).=09 >> Hi, you rang? ;) >>=20 >> Actually =E2=80=9Csome mesh protocols=E2=80=9D do go through the = exercise of verifying bidirectionally before even considering them as = useful for whatever the protocol tries to do. >>=20 >> What I am trying to get at, though, is not this discussion but = rather: what does this Link present to the IP layer, in terms of = properties? >=20 > (802-style) broadcast domain is what we=E2=80=99re probably looking = for. There=E2=80=99s also =E2=80=98multiple access link=E2=80=99 in one = place in the spec, to denote availability of link-local multicast I = guess. >=20 > This terminology could use some further work I think though. Thanks, let me know when you want me to look at something concrete. > =09 >>>> Operation >>>> =09 >>>> o First a generic comment that Trickle itself has = some operating >>>> conditions which scopes its applicability, and = it would behove >>>> this document to, in its own applicability = statement, call out >>>> those. >>> Added some comments regarding applicability. >>=20 >> Better, but I would like to see that reflected also in a dedicated = applicability statement. >=20 > I do not think we can actually provide so concrete applicability stmt = as Trickle does though (e.g. RAM, LoC, etc) as it depends mostly on the = protocol it runs on + network size + .. I do not want to see RAM, LoC, etc. =E2=80=94 and what you mentioned up = above in the email seems to be the right direction that you are going. = One operating condition for trickle to make sense is, for example, that = you do not have a continued flow of =E2=80=9Cchanges to reflect=E2=80=9D = =E2=80=94 hey, you say that somewhere in the document already, that=E2=80=99= s part of =E2=80=9Cwhere DNCP is applicable=E2=80=9D. So I think that = in doing the other stuff you=E2=80=99re actually addressing this here. >>>> Added protocol overview and made connection between trickle, merkle = tree >>> and requests more clear. >> Indeed, and =E2=80=9Cmerkle trees=E2=80=9D disappeared and became = hash trees somewhere along the line ;) >=20 > We were misusing the term actually; original Merkle tree was binary = hash tree _only_, and while later on the term became synonymous with = (N-ary) hash tree, when asked for Merkle references, just renaming it = hash tree seemed to be the sensible choice as we were abusing the = (original) definition. Yup, and that=E2=80=99s quite fine. >=20 >>>>=20 >>>> o Section 6.2: >>>> =09 >>>> "An upper bound for the number of neighbors that = are allowed for a >>>> (particular type of) link that an endpoint runs = on SHOULD be >>>> provided by a DNCP profile, user configuration, = or some hardcoded >>>> default in the implementation." >>>> =09 >>>> A couple of things to that: >>>> 1) Can you explain the parenthesis? What = type of link? >>>> 2) How does "an endpoint runs on" a link? >>>> 3) Why SHOULD? >>>> 4) Is this specification seriously = suggesting "some hardcoded >>>> default in the implementation" as a = SHOULD? >>>>=20 >>>> [I am tempted to upgrade this to a "Major issue" simply = because of 4) ] =09 >>> Clarified, the choice to use it is not really visible externally. = Now >>> the text has per multicast-enabled link type constraints, and also >>> per-profile support for extension at all. >>>=20 >>> =09 >>>> =09 >>>> =09 >>>> Also to 6.2, this particular optimization, do you have = any >>>> quantification of its actual benefit? What should I look = for to >>>> determine if this "optimization" yields a benefit or = not? What are >>>> you trying to optimize? Over what link types does this = function? >>>> I am dubious that it "optimizes" much, if anything, = across an Ethernet, for example ... >>> Oddly enough, most link-state routing protocols have this = optimization. >>> Added further description on why it is helpful. >>>=20 >>=20 >> So, the things that you did to this, and the precious comment, helps. = The =E2=80=9Cdesignated router=E2=80=9D (or equivalent/derivatives/*) = mechanism is, as you point out, well known and well used. I was yanking = your chain a little bit here to get, well, pretty much the explanation = and discussion that you gave. Thank you for that. >>=20 >> Nit, though, just so that I feel useful in doing this: >>=20 >> OLD: >> MAY also be chosen at runtime. Main consideration when = selecting=20 >>=20 >> NEW: >> MAY also be chosen at runtime. The main consideration = when selecting=20 >>=20 >>=20 >> But, good job here. >=20 > Thanks :) Addressed. ;) > =09 >>>> o Section 7.2.3, I worry when I see something like this: >>>> =09 >>>> "The whole network should have roughly the same = idea about the time >>>> since origination of any particular published = state." >>>> =09 >>>> What is the definition of "roughly"? >>>> Is the "should" intentionally in non-caps? >>>> What're the consequences if not? >>>> [Note that trickle almost mechanically makes information = propagate >>>> with non-trivial jitter across a network, so how do you = ensure this?] >>> Clarified the paragraph, since the original text could be = interpreted >>> invertedly. >> Another nit=E2=80=A6 >>=20 >> Every node, including the originating one >>=20 >> what is =E2=80=9Cthe originating one=E2=80=9D, is it =E2=80=9C=E2=80=A6= including the node originating this TLV=E2=80=9D? >>=20 >> Otherwise, yes to your clarification. >=20 > =E2=80=98this TLV=E2=80=99 is also confusing, as you could say the TLV = itself is sent by all nodes and as it is not passed verbatim (timestamp = changes) it cannot be said to be originated by someone. >=20 > Inserted =E2=80=9CEvery node, including the node publishing the node = data,=E2=80=9D for now. >=20 I think that this works. Recapitulating, I see basically two potential issues where we do not yet = have resolution: o Versioning=20 o Address/Endpoint terminology That=E2=80=99s already great progress.=20 For the former, either the proposal I made in this email (which included = a lunch appointment in 15 years time), or it may be one of those cases = where we will agree to disagree and have the RTG-ADs figure out what = they want to take it as. For the latter, I=E2=80=99ll try to come up with something that might = make sense (I may meet Pierre tomorrow and bounce it around with him = over coffee) and shoot back, but anybody else with a proposal=E2=80=A6plea= se chip in. =20 Thanks for this exchange, it=E2=80=99s engaging and constructive and I = can=E2=80=99t wait to review -09 (regardless of what comes from the two = above items). Cheers, Thomas > Cheers, >=20 > -Markus --Apple-Mail=_2732A1FC-D0D0-4DB7-AA21-2F49CA9A3B1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 29, 2015, at 13:06, Markus Stenberg <markus.stenberg@iki.fi> wrote:

First of all, thanks = a lot again for review comments; I think you are the most critical = reviewer we have had yet, and it helps to improve the document quality a = lot :)

I *was* starting to = worry if I needed to take out armed protection, simply due to the sheer = volume  of my comments appearing  as a =E2=80=9Clate = assault=E2=80=9D :D  I am thrilled that I didn=E2=80=99t need to, = and that to the contrary you really reflected them well in the = spec.

We have had a number of reviews by this = point, but I believe you have raised order of magnitude more changes = than the second in line who also lives in Paris; is this a coincidence? = I think not.

Fun that you = should mention it. I think that the person you refer to, and I, while = we=E2=80=99re based in the same area, never actually have seen each = other (despite repeatedly planning for it) in or around Paris. So rest = assured, it=E2=80=99s not a =E2=80=9Cgeographic conspiracy=E2=80=9D = afoot here ;)

Anyway, on to comments..

Caveat: These are my comments, Steven is likely to fix typos = before we actually hit publish button on -09 :)

Executive summary: Minor edits, but as you are good with = words, time to ask for advice - how would you explain =E2=80=9CEndpoint=E2= =80=9D in the terminology? (Anyone else on the list too, feel free to = chime up..)


Actually, when doing my review I tried if I could come = up with some text that I would thing worked =E2=80=94 which, if I had = succeeded, I=E2=80=99d have been throwing it at you saying =E2=80=9C=E2=80= =A6but this would make me happy=E2=80=9D.

I didn=E2=80=99t come up with something that I = actually liked. So instead, you get my random thoughts = =E2=80=A6 

Fact: It is not socket. I = consider it essentially bidirectional mapping between an endpoint #, and = some transport details (as it is used for both receiving and sending = traffic).

I guess I am troubled by having seen the = terminology =E2=80=9Ca socket is an endpoint for communication=E2=80=9D = and =E2=80=9Ca connection is a pair of sockets=E2=80=9D =E2=80=94 taking = from Wikipedia (which is not a source for anything but =E2=80=9Cwhat is = commonly used, even if incorrectly - but, as such, is a good way to = understand =E2=80=9Chow many people would misunderstand in the same = way"):

"A network socket is an = endpoint of = an inter-process communication across 
=  a computer network. Today, most communication = between computers is 
 based on the Internet = Protocol; therefore most network sockets are Internet = sockets."

Now, = I am of course also troubled by the recursive definition of endpoint in = the I-D:

Endpoint: a locally = configured communication endpoint of a DNCP node, such = as a network socket.

Random examples from existing implementations:

- _a rule_ that matches that stuff from ::1 is = endpoint #1 (on shared socket)
- _a rule_ that we try to = contact 2001:db8::1 and denote it as endpoint #2 (on shared socket)
- a socket which is bound to eth0 + port X, and listens to = multicast there, denoted as endpoint #3
- (shared socket = on port Y) which is listens to eth1 multicast (and also deals with eth1 = link-local unicast traffic), denoted as endpoint #4


So that sounds a = little bit like (for the 2nd bullet) that it=E2=80=99s (in part) a = =E2=80=9Cconnection=E2=80=9D (the =E2=80=9Cwe try to contact =E2=80=A6.=E2= =80=9D part)?

The current text-monster is as follows:

Endpoint a locally configured = communication endpoint of a DNCP node, such as a network socket. An = endpoint may be bound to a set of predefined unicast Addresses = representing remote DNCP nodes to individually connect to or to accept = connections from whereby communication with each node is separated = (e.g., an individual unicast UDP message flow per remote node). An = endpoint may also be bound to a whole network interface, then multicast = communication is used (in addition to individual unicast flows) to send = certain messages to all DNCP nodes connected therewith at once as well = as to automatically discover new DNCP nodes. Endpoints are usually in = one of the transport modes specified in Section 4.2.

On 28.7.2015, at 18.45, Thomas Clausen <ietf@thomasclausen.org> wrote:
Authors, for all the points where I have said = =E2=80=9Cfine=E2=80=9D, if you reply to this mail feel free to cut those = points out and retain only outstanding issues.
OK; on a = personal-preferences level, the separation between HNCP and DNCP seems = artificial, and it probably is part of the reason why this is hard to = describe. I probably would not have made that separation myself =E2=80=94 = but I am not suggesting that the WG goes back on that decision (just to = be clear), rather that it be called out.

I = can live with what is there.

I = think the separation makes sense (as DNCP itself is generic algorithm, = more or less); however, the point of separation I am not so sure about = (e.g. concrete TLVs in DNCP feel bit wrong, but there are reasons for = that too; easier to specify DNCP-based protocols).

As I said, I am = not suggesting to go back on that decision =E2=80=94 so we can have that = discussion somewhere away from the ears of the ADs some other time = ;)

We reorganised the document a bit, wrote a better abstract = and
introduction and provided a =E2=80=9CProtocol = Overview=E2=80=9D section, on top of that
we reorganised = the details in an =E2=80=9COperations=E2=80=9D section.

OK; I am a good deal more happy = now, although not perfectly happy just yet.

I still think that it would be fantastic to have an = applicability statement included. Reading the document without any = context [as it might down the line if it was to become an RFC], it=E2=80=99= s hard to understand if =E2=80=9Chey, I have a problem, is DNCP the = right lump of metal to use to make a hammer for it?=E2=80=9D

Adding one in -09; however, it is = still undergoing edits. Gist of it is to look at

[1] min (keepalive-interval-if-nonzero, churn frequency * = number of nodes) and compare it to Trickle parameters chosen
[2] consider amount of TLV change within TLV sets published = by nodes (large set, small changes =3D> may not be the best protocol = for the job due to lack of per-TLV deltas)

Sounds = good.

As I said in my original = review, I think that this is a matter of scoping the work right. The = abstract, and the into, calls out =E2=80=9Ca generic state = synchronization protocol=E2=80=9D =E2=80=94 I=E2=80=99ve heard OSPF = described as such, also (hi Fred!) =E2=80=94 which sounds very much like = =E2=80=9Cboiling the ocean=E2=80=9D, and which I think the WG is not = trying to actually do.

WG = isn=E2=80=99t, but we wound up doing one anyway. Still, we=E2=80=99re = adding applicability subsection in 09, as I think it is important to = note that DNCP is _not_ the tool for many things.

Great, sounds = like we=E2=80=99re perfectly aligned here, and I look forward to seeing = the text.


Why don=E2=80=99t you put a subsection before the last = paragraph of the Introduction =E2=80=9CApplicability=E2=80=9D and then = expand on that?

Addressed = above.

I= just want to note that I enjoyed the expanded terminology - thank you! = There may be a small formatting snafu, at least in the HTML version, = about missing blank lines between (for example) =E2=80=9CAddress=E2=80=9D = and =E2=80=9CEndpoint=E2=80=9D

Hopefully fixed.

Going back and looking at that, does it make = sense to talk about =E2=80=9CDNCP network=E2=80=9D, out in the real = world, or just in this document?

An HNCP = network and a TNCP network (that=E2=80=99d be for "Thomas' Neat = Configuration Protocol=E2=80=9D) sure, and such two could co-exist (but = not interoperate) so while they =E2=80=9Cin the abstract=E2=80=9D would = both be instances of DNCP networks, that=E2=80=99d be an abstract = construction altogether.

Could I suggest = that to the definition of =E2=80=9CDNCP network=E2=80=9D some verbiage = to that effect be added?

NEW: = a set of DNCP nodes running DNCP-based protocol(s) that have matching = DNCP profile.

The side effect is that if = DNCP profiles match, essentially transit service is provided even if the = implemented protocol is not same. (e.g. HNCP + SHSP currently.)

And that = *sounds* right and *sounds* as if it is by design, so that=E2=80=99s = great.


Now = we=E2=80=99re at tightening up on terminology, I am finding myself = wondering about =E2=80=9CDNCP profile=E2=80=9D and =E2=80=9CDNCP-based = protocol=E2=80=9D as terms, just a little.

A = DNCP profile is
    a = definition of the set of rules and values
=             &n= bsp;       defining the behavior of a = fully specified,
=             &n= bsp;       implementable protocol = which uses DNCP.  The DNCP
=             &n= bsp;       profile specifies = transport method to be used,
=             &n= bsp;       which optional parts of = the DNCP specification are
=             &n= bsp;       required by that = particular protocol, and various
=             &n= bsp;       parameters and optional = behaviors.  In this
=             &n= bsp;       document any parameter = that a DNCP profile
=             &n= bsp;       specifies is prefixed with = DNCP_.  Contents of a
=             &n= bsp;       DNCP profile are specified = in Section 9.

Could we be a little bit more = succinct:

=E2=80=9CA DNCP profile consists = of:
o The values for the set of = parameters, given in section 9.
o The set = of optional parts of this specification, which are to be used.=E2=80=9D

Adopted the gist of it, although = not going to convert to a list (and retained DNCP_ note as it is useful = to understand DNCP_foo coming up shortly in the next few things).


Yes, the DNCP_ note should be retained. My bad for = *not* doing that, thanks for catching it.

NEW:
  DNCP profile =      consists of the values for the set of = parameters,
=             &n= bsp;       given in Section 9. They = are prefixed with DNCP_ in
=             &n= bsp;       this document. It also = specifies the set of
=             &n= bsp;       optional parts of this = specification, which are to
=             &n= bsp;       be used.


Works for = me.


For = DNCP-based protocol, the doc says:

A = DNCP-based protocol is:
a protocol which provides a DNCP = profile, and
=        potentially much more, e.g., = protocol-specific TLVs
=             &n= bsp;          and = guidance on how they should be used.


Could we be more precise (than =E2=80=9Cpotentially much = more=E2=80=9D) on =E2=80=9CDNCP-based profile=E2=80=9D

=E2=80=9CA DNCP-based protocol is:
o A DNCP = profile, according to Section 9,
o Zero or = more TLV assignments from the registries set up by this specification
= = = o = generation and processing rules for these TLVs


NEW:
DNCP-based protocol a protocol which provides a DNCP = profile, according to Section 9, and zero or more TLV assignments from = the DNCP profile-specific TLV registry as well as their processing = rules.


Works.

On the = definition of =E2=80=9CAddress=E2=80=9D:

= o = What does it mean to be =E2=80=9Crelatively transport = agnostic=E2=80=9D? I=E2=80=99d
say that = it=E2=80=99s a little bit like being =E2=80=9Crelatively pregnant=E2=80=9D= =E2=80=94 either you are, or you are not?

Got rid of some relatively=E2=80=99s.


;)

o Why not = define an =E2=80=9CAddress=E2=80=9D as  (IPv6-address, Transport, = Port)?
(and then, if someone comes along = with something that doesn=E2=80=99t fit that tuple form
= = down the line, deal with it then?)

I am not sure it would help as such. The addressing may also = occur inside transport - think multiple flows multiplexed over single = stream connection, for example. Or local UNIX domain sockets :)

OK, but now I am = back to being confused =E2=80=94 how does =E2=80=9Cmultiple flows = multiplexed over single stream connection=E2=80=9D, =E2=80=9Caddress=E2=80= =9D and =E2=80=9Cendpoint=E2=80=9D then fit together?


Address, = by the way, uses =E2=80=9Cendpoint=E2=80=9D which is defined below.

Transport protocol endpoint and = DNCP endpoint are not neccessarily the same thing. They may have 1:1 = relationship, but also 1:N (or possibly M:N) are possible. Got rid of = endpoint in the new definition.

NEW:

Address an identifier which specifies how = to reach a particular instance of a transport protocol on a particular = node. In case of an IPv6 UDP transport, an address in this specification = refers to a tuple (IPv6 address, UDP port).

*mumble* - Let = me give this whole part some thought, and see if I can come up with = something constructive to say on this point (other than =E2=80=9Cnot = sure that that=E2=80=99s clear=E2=80=9D).

Endpoint, then, ends up = being defined almost as an =E2=80=9Caddress=E2=80=9D *except* that = there=E2=80=99s the clause =E2=80=9Cmay be bound to a set of predefined = unicast addresses=E2=80=9D [would those be addresses as previously = defined?]

When I read =E2=80=9CEndpoint=E2=80= =9D I end up simply thinking =E2=80=9CSocket, expressed as = (IPv6-address, Transport, Port)=E2=80=9D but as that was defined above = it can=E2=80=99t be it?

Could you clear = that up, please? [Note, it=E2=80=99s better than the -05, but still = confusing]

I am not sure how. = There has been literally half dozen iterations so far. I am not sure I = like the current one, as it is overly verbose and apparently not much = closer to the goal.

(see top)

Yup. Needs some = thought here. I=E2=80=99ll peg that as a todo; if we end up with that as = the only outstanding point, and we=E2=80=99re no closer to an = alternative, then the conclusion could be =E2=80=9CThomas is just too = dense to understand this=E2=80=9D, which I trust that the ADs would be = comfortable with. 

Major Issues:

o The = introduction does not read well; it contains parts of something that
= = could be considered as part of an applicability statement = (without it
being called out as such, and = without forming a complete applicability
= statement), and does not actually introduce the protocol. Reading = just
the introduction and the = abstract, it is very obscure if
this is a = framework, a protocol, a building block, an architecture, an
= = algorithm -- and, if either of those, what it is actually = accomplishing,
and why one would chose to use = DNCP. It does, however, transpire that
"whatever = it is", it has two "modes" and that it requires something
= = (presumably a routing protocol) to provide each "node" with a = topology
map.

= = Suggest that a proper introduction consisting of three parts = would be
beneficial: (i) what this = document is, (ii) what doing DNCP actually
gets you, = and (iii) the operating conditions under which the
DNCP is = applicable.

On the = latter point, given that you state that DNCP requires profiles
= = to provide "actual implementable DNCP based protocols", it = appears
important to understand what the = limits for "what a profile can give
you" = are.

I am = calling this out as a major issue, since I believe that it is
= = not just editorial, but is a matter of scoping this document = correctly,
and in particular not falling = into the trap of "claiming applicability
where = it's not".

As noted earlier, = the introduction has been reworded and separated from
protocol overview also considering your suggestions.

So this is good, thank you for = doing that effort =E2=80=94 it=E2=80=99s tedious, but it helped.

To section 3, therefore, a few suggestions:

1) Throw an initial paragraph in = stating what DNCP does =E2=80=9Cstate synchronization=E2=80=9D and all = that.

As this comes after the = intro (which does that), I am not sure I agree with the need. Do you = suggest cut-n-paste, or something new here?

Well, =E2=80=9CA = TLV-based distributed state synchronization protocol, DNCP operates = primarily using unicast exchanges=E2=80=A6=E2=80=9D as the first = sentence would really do it for me.


2) =E2=80=9CDNCP discovers the = topology of its nodes and =E2=80=A6=E2=80=9D
= Argh=E2=80=A6almost there =E2=80=9Cits nodes=E2=80=9D?
= = = - = would that be =E2=80=9Cthe nodes in the DNCP network=E2=80=9D = (which has been defined=E2=80=A6)?
- you=E2=80=99= re discovering the topology (i.e., you actually produce a topology = graph?)
or just the presence or absence = of nodes in the network (i.e., a destination list)?
Just = state what you do, and it=E2=80=99ll be good.

Using the first suggested text. = Of course, this =E2=80=99topology=E2=80=99 may be somewhat misleading = too as we do not really necessarily have low-level topology, but just = connectivity among DNCP nodes. *sigh*

(In = point-to-point case, there may be arbitrary number of hops in the middle = DNCP is blissfully unaware of.)

That works.


3) =E2=80=9Cbidirectionally = reachable=E2=80=9D =E2=80=94 call out if that means =E2=80=9Cover one IP = hop=E2=80=9D (as in =E2=80=9Con the same link=E2=80=9D)
= = or if it can be =E2=80=9Cbidirectionally reachable, possibly = through a multi-hop path=E2=80=9D

Actually, = why don=E2=80=99t you define that term in the terminology section, since = it appears also
in section 4, and it=E2=80=99d = make me go away with this comment in more places than one ;)

Hmm. Given we leave actual = transport out, I am not sure how it could be over one IP hop.

Anyway, added a definition (not cut-n-pasting = here so Steven has time to fix it, cough).


OK, I=E2=80=99ll = wait to see what comes

4) =E2=80=9CA = hash tree is maintained by each node=E2=80=9D =E2=80=94 I=E2=80=99ve = thought about that, and I think that you may
want to = expand a little more. =E2=80=9CA hash tree, rooted in itself, is = maintained by each node=E2=80=9D?
5) And then, = again, the text is almost there, bit just need a nudge=E2=80=A6how is = the tree constructed?
You start fine =E2=80=9Ca node = starts with a hash tree only consisting of itself=E2=80=9D.
= = Then it announces that, and gets updates. How are those = =E2=80=9Cintegrated=E2=80=9D into the receiving nodes=E2=80=99
= = hash tree.
Yes I know how it=E2=80=99d work = out (I may be dense, but not *that* dense ;) ), but I think that it=E2=80=99= d be
easy to capture all here and = being complete, since it=E2=80=99s so close.

By the way, I would state that the hash tree is height 1 in = this section, and add a forward reference to 4.1.

Added some forward refs, and = updated the text.

A hash tree of height 1, = rooted in itself, is maintained by each node to represent the state of = all currently reachable nodes (see Section 4.1) and the Trickle = algorithm is used to trigger synchronization (see Section 4.3).


Awesome, clear now.

Section 4, I really like what you have done with it also. As = a purely subjective matter, could there between 4 and 4.1 be some = educational text that describes how the 6 subsections to 4 =E2=80=9Cfit = together=E2=80=9D? As it is right now, it=E2=80=99s a little abrupt.

o The document, in my = understanding, defines an exchange format with
limited = ability to evolve, as simply "a steam of TLVs".

= = As long as there's never a need to evolve the TLV format itself, = and
as long as you do not run out of = TLV types, that's not going to be
a = problem. The doc sets aside a 16bit TLV type space, that's reasonable
= = enough, but I worry if eventually a DNCPv2 will need to evolve = the
format. One purely hypothetical = example could be if a "sequence number"
would be = needed in each DNCP message to detect "link success rates", or
= = something of that sort.

I= think on this front we have to agree to disagree; as it is a stream = of
_unrelated_ TLVs with some rare exceptions (node = endpoint ID =3D> network
state), a later spec such as = DNCPv2 can specify if it wants to that
every DNCP = 'message' contains TLV of type $FOO and uses disjoint set of
TLVs to do X. Hell, we do that in HNCP already.


OK, then, in that = case what you call a TLV is what I would call a =E2=80=9CMessage=E2=80=9D = =E2=80=94 fair enough, I can do that mental substitution.

Now=E2=80=A6that still doesn=E2=80=99t change = the fact that you may end up having to evolve your Message format =E2=80=94= I=E2=80=99m sorry, your TLV format =E2=80=94 as it appears on the wire, = as well as some of the behaviors that you exhibit through DNCP = processing.

For that, you=E2=80=99ll need a = version number. And again, I am sorry, I cannot come up with a concrete = example and =E2=80=94 again =E2=80=94 that=E2=80=99s part of the = dilemma: a future extension that we have not thought about is, by = definition, a future extension that we have not thought about and so = therefore we can=E2=80=99t predict if it will be interoperable with a = what we have now.

TLV space is = relatively large, and mostly undefined. I still do not see the = problem.

I see much more of a problem = defining e.g. 4 byte version thing, because after that speaking =E2=80=98b= oth versions=E2=80=99 of the protocol becomes hard.


Alright, I=E2=80=99= ll peg that as issue #2 that needs an isolated discussion and where the = ADs may have to decide that I am in the rough (which is fine) if needed. = I just observe that I=E2=80=99ve seen a strong move in other contexts in = the IETF for =E2=80=9Cversion numbers=E2=80=9D so I would expect that to = become an issue here also.

= = I do not have an actual example in mind -- and that's exactly the = point:
to be evolutive for the unknown = future and (at the very least) be able
to = discriminate between "old" and "new".

= = A discussion could be had if a "version number" in each TLV would = do,
or if a concept of "protocol = message with a version number" is
= preferential. I do not believe, however, that "no version number" = is
= = viable.

Since DNCP is = an abstract protocol, a concrete protocol on top of it
might= probably want to do versioning for its own purposes (i.e.
different versions on top of the same DNCP version). In this = case having
versioning in both DNCP and the derived = protocol serves little purpose.
HNCP - as first derived = protocol - defines a Version-TLV btw.

Yes but that is a =E2=80=9Cversion TLV=E2=80=9D =E2=80=94 = what happens if the TLV format itself, or some of the DNCP specific = processing.

This, incidentally, goes to the = crux of why I =E2=80=94 personally =E2=80=94 would not have done the = split. Had DNCP *exclusively* been an algorithm, or such, then I could = see not needing a version in DNCP, but in the DNCP-based protocol (HNCP) = only. Or, for that matter, had DNCP been just a frame format with no = processing, or something, then I could see one sequence number = sufficing.

By DNCP being = part-signals-part-procesing-part-behavior-part-framework, which cannot = exist on its own but which requires =E2=80=9Canother protocol which = profiles it and which also defines its own signals, processing, and = behavior=E2=80=9D, yes, you actually having this =E2=80=9Cversion number = conundrum=E2=80=9D.

Why? The = concrete DNCP-based protocol actually says what it supports, and e.g. = future DNCP extensions are not implicitly part of HNCP, unless we = specify them to be.

It=E2=80=99s always hard to speculate on = extensions, so =E2=80=A6 this may sound silly.

Say we wanted DNCPv2 to, for some reason, not use TLVs = but use LVTs, or that it redefined the way of calculating the Network = State / Node State =E2=80=94 for some reason. For the LVT-option you=E2=80= =99d be screwed ;) for the =E2=80=9Cnew way of calculating Network State = / Node State=E2=80=9D you=E2=80=99d say =E2=80=9Cdefine a new TLV = type=E2=80=9D?

I=E2=80=99d imagine = that a DNCPv2, or perhaps a device using DNCPv2, would somehow be able = to maintain a =E2=80=9Cbackwards compatible mode=E2=80=9D, say, if I see = DNCPv1-based protocols hanging around, then I=E2=80=99d probably fall = back to use those, but if I don=E2=80=99t then I=E2=80=99d want to use = the new-fancy DNCPv2-based protocols (which might use some of the same = TLVs, but use them differently).

I = think that you=E2=80=99re shooting yourself in the foot = here.


You could = not fix all this by having a DNCP version number only, but having a = sufficiently large TLV type space? That way, you=E2=80=99d not need = (say) HNCP version numbers, but a HNCPv2 would use TLV types A, B and D = (but not C) from HNCPv1, and would reserve and define TLV types X, Y, Z = ?

HNCP has 2^16-few types to = play with. Is that not enough?

(Only up to = 32 and the local tinkering range are excluded from the DNCP profile = specific registry HNCP will set up. However, conflicts in handling the = 256+ range are currently being considered on how they should be = handled.)

Proposal=E2=80=A6.you say that you have a large = TLV type space so =E2=80=A6.why don=E2=80=99t we set aside the first two = bits in the TLV type field, call that =E2=80=9CVersion=E2=80=9D, and = define =E2=80=9Cif both are cleared, then it means this specification, = DNCPv1" and then have 2^14 =E2=80=9CTLV types=E2=80=9D =E2=80=94 with a = potential for 4 DNCP =E2=80=9Cversions=E2=80=9D?

Then, we take an appointment in 15 years time. If = by then we still have not found a reason to flip either of these two = version bits, then (i) we write an =E2=80=9CUpdates DNCPv1=E2=80=9D RFC = which reassigns that field as =E2=80=9C16 bit TLV Type=E2=80=9D, and I = buy lunch =E2=80=94 otherwise, lunch is on you? 

;)



o Noting that the "overhearing n = reduncant transmissions" is a key
= retransmission suppression mechanism in Trickle, and that this
= = seems to assume broad/multicast, using unicast seems to = contradict
the statement of "consists of = Trickle", at least in the way the
algorithm = is defined in RFC6206. Note: it's fine to use an algorithm
= = outside of its initial scope, but it should be with the caveat = of
= = "which of the characteristics still hold, and which do not"
If k < 2, even on point-to-point link, = Trickle does reap benefits and
provides exponential = backoff timer. Obviously, we can spell this out
more = explicitly if it helps.
YES, that sort of = explanation would be good.

Added= that to the applicability subsection too. (Pending Steven check, = *grin*)


Great

= o = Section 5.3, penultimate paragraph:

= = = "If keep-alives specified in Section 6.1 are NOT sent by the = peer
    (either = the DNCP profile does not specify the use of keep-alives or
= =     the particular peer chooses not to send = keep-alives), some other
    means = MUST be employed to ensure its presence.  When the peer is no
= =     longer present, the Neighbor TLV and the = local DNCP peer state MUST
    be = removed."

"...some = other means MUST be employed to ensure its presence." --
= = followed by more MUST verage when a peer disappears...I am not = sure that
that's conductive to = interoperable implementations.

= = Two implementatons may chose different "means" and then turn off = keep-
alives - and be = non-interoperable.

For = interoperability, we need:

o A = mandatory to implement mechanism, that always is
present, = but can be complemented by another "means", or

= = = = o = A mandatory to implement mechanism, which by way of a
= = = = = specified negotiation mechanism can be turned off between
= = = = = two peers, to allow them to use another "means".
= = = = =
If you argument is "...this will = be specified in the profile", then
you still = should provide the two above in this document, with the note
= = that "...and a profile may specify which from among these MUST = be
= = used in a given deployment"

Clarified that =E2=80=9Cother means=E2=80=9D, refers to = existing transport-provided
mechanism, e.g. Ethernet = carrier-detection, TCP keep-alives etc.

Alright, good. Now where is it specified which is to be used? = Is that part of the profile, or should it be? If so, call that out = here.

I=E2=80=99m trying to avoid = interoperability issues, for example if I am using =E2=80=9CTCP = keep-alives=E2=80=9D and you are using something else, can we work = together? If this is not a problem, call that out as something which a = device can do as it sees fit (although, for example. TCP keep-alives = presumably expects TCP which is a profile matter =E2=80=A6)
I *think* that we are almost there also with this point, so = convince me that the text there won=E2=80=99t cause interoperability = issues? Hiving it off to a profile to specify would do just that (of = course, I=E2=80=99d come back on that in HNCP, instead ;) ).

This (like many other things in = the spec actually) are local implementation choices; the MUST is that _a = method_ must be used (if no keep-alives are used).

However, to cover the case without any method available, = added following:

=        If the peer does not send = keep-alives, and no means to verify
=        presence of the peer are = available, the peer MUST be considered no
=        longer present and it SHOULD = not be added back as a peer until it
=        starts sending keep-alives = again.


That seems to work for me. Thanks

.. = omitted security stuff.

Minor Issues:

= Introduction:
o 1st paragraph: "reachable nodes"; = two things:

- I always = have a problem with the term "node"; it is often
used as a = shorthand for "routers and hosts, both". I was
given to = understand that homenet specifically did not want
to = consider host changes?
DNCP is not strictly = speaking about homenet (but a strict requirement
for HNCP = which is). Also even in homenet-case non-routers may join the
network temporarily in order to e.g. do monitoring.

But, would those = =E2=80=9Cnon-routers=E2=80=9D not speak at least part of the =E2=80=9Chome= net specific protocols=E2=80=9D and thereby not be =E2=80=9Chosts=E2=80=9D= in the =E2=80=9Cgot them from Best Buy and just clicked OK=E2=80=9D = sort of sense?

So is the crux that we have = =E2=80=9Chomenet-aware devices=E2=80=9D and =E2=80=9Clegacy hosts=E2=80=9D= , and that either of us just need to get with the program? If so, can I = insist (gently) on =E2=80=9Chomenet-aware devices=E2=80=9D [with a = suitable definition] instead of =E2=80=9Cnodes=E2=80=9D since = =E2=80=9Cnodes=E2=80=9D are such an overloaded term that it=E2=80=99s = not even fun any more.

Again, = this has nothing to do with homenet, but it=E2=80=99s being pushed in = homenet just because it is strict dependency on HNCP.

There is already one existing use of DNCP which is very non = homenet, demoed in IETF93 BnB and presented in the WG; I expect there = might be more if we do not make the spec overtly homenet-y.

Ok, being = general where it makes sense is good.  We=E2=80=99ll take this = discussion in HNCP, then.

= = = = - = "Reachable" - does that mean something as in "radio range",
= = = = = does it mean "on the same link", does it mean within a
= = = = = specific (DNCP?) domain, or does it mean simply "on the
= = = = = Internet somewhere"?
Clarified in the = text as =E2=80=9Cbidirectionally reachable=E2=80=9D, also added
fwd-references to actual definition.
Suggest also defining in Terminology, and = clarifying if this is a one-hop, or a multi-hop-within-the-homenet, = concept. In section 1, I do not see a forward reference, btw, at least = not in latest rev.

Added = rather verbose description.

;)




o DNCP = network: I read this twice, and came away with two different
= = = understandings, perhaps you can clarify which it is:

o A set of nodes running DNCP, = within the same domain, and
for which a path betwen any two = DNCP nodes includes only
other DNCP nodes; i.e., a DNCP = network forms a connected
component with only other DNCP = nodes.

o A set of = nodes running DNCP. They may be anywhere on the
Internet, = they are part of the same DNCP network as long
as they = (through other means) have learned of each others
= addresses.

In the = former, that'd be (for example) a deployment within my
home -- = in the latter, it could be a node in my home and a node in
= = = your home forming a DNCP network.

= = = The text is not quite clear on this point.
Both are valid use cases; hopefully = clarified.
OK, sadly you clarified it ;) = Well, no, not sadly, but you clarified it to be understandable to me in = the above sense. But, if I come up with the aforementioned TNCP and I = use the same transport as HNCP, would a TNCP and a HNCP node be on the = same DNCP network, then?

Yes. = E.g. SHSP and HNCP share transport, but are ships passing each other in = the night as far as understanding TLVs go. (And unwittingly, they proxy = each other=E2=80=99s state.)

OK, with the proposed text somewhere up above in = this email, this is clear =E2=80=94 so that works for me also.

o Link: a = point of clarification here. In "DNCP network", there was
= = = talk about "unidirectional links" and "bidirectional links"; = in
= = = "Link" the definition is somewhat vague "directly connected" = and
"can communicate". Could = something like "without decrementing TTL/
= hop-count" be added, and could a statement on bidirectionality
= = = (IOW, that this is just an IP link) be added?
This isn=E2=80=99t IP specific as such; however, = some better definition is
welcome. some types of IP links = are not strictly bidirectional either
(hello, mesh).
Hi, you rang? ;)

Actually =E2=80=9Csome mesh protocols=E2=80=9D do go through = the exercise of verifying bidirectionally before even considering them = as useful for whatever the protocol tries to do.

What I am trying to get at, though, is not this discussion = but rather: what does this Link present to the IP layer, in terms of = properties?

(802-style) = broadcast domain is what we=E2=80=99re probably looking for. There=E2=80=99= s also =E2=80=98multiple access link=E2=80=99 in one place in the spec, = to denote availability of link-local multicast I guess.

This terminology could use some further work I think = though.

Thanks,= let me know when you want me to look at something = concrete.


Operation

= = o = First a generic comment that Trickle itself has some operating
= = = conditions which scopes its applicability, and it would behove
= = = this document to, in its own applicability statement, call out
= = = those.
Added some comments regarding = applicability.

Better, but I = would like to see that reflected also in a dedicated applicability = statement.

I do not think we = can actually provide so concrete applicability stmt as Trickle does = though (e.g. RAM, LoC, etc) as it depends mostly on the protocol it runs = on + network size + ..

I do not want to see RAM, LoC, etc. =E2=80=94 =  and what you mentioned up above in the email seems to be the right = direction that you are going. One operating condition for trickle to = make sense is, for example, that you do not have a continued flow of = =E2=80=9Cchanges to reflect=E2=80=9D =E2=80=94 hey, you say that = somewhere in the document already, that=E2=80=99s part of =E2=80=9Cwhere = DNCP is applicable=E2=80=9D.  So I think that in doing the other = stuff you=E2=80=99re actually addressing this here.


Added protocol overview = and made connection between trickle, merkle tree
and requests more clear.
Indeed, and =E2=80=9Cmerkle trees=E2=80=9D = disappeared and became hash trees somewhere along the line ;)

We were misusing the term = actually; original Merkle tree was binary hash tree _only_, and while = later on the term became synonymous with (N-ary) hash tree, when asked = for Merkle references, just renaming it hash tree seemed to be the = sensible choice as we were abusing the (original) definition.

Yup, and = that=E2=80=99s quite fine.



o Section 6.2:

= = = "An upper bound for the number of neighbors that are allowed for = a
  (particular type of) link that = an endpoint runs on SHOULD be
  provided = by a DNCP profile, user configuration, or some hardcoded
=   = = = default in the implementation."
 
  A couple of things to that:
  1) Can you explain the parenthesis? = What type of link?
  2) How does "an endpoint runs on" a = link?
  3) Why SHOULD?
=   = = = 4) = Is this specification seriously suggesting "some hardcoded
  default in the implementation" as = a SHOULD?

[I am tempted to upgrade this to = a "Major issue" simply because of 4) ]   
Clarified, the choice to use it is not really = visible externally. Now
the text has per multicast-enabled = link type constraints, and also
per-profile support for = extension at all.



= =
Also to 6.2, this particular = optimization, do you have any
quantification of its actual = benefit? What should I look for to
determine = if this "optimization" yields a benefit or not? What are
= = you trying to optimize? Over what link types does this = function?
I am dubious that it "optimizes" = much, if anything, across an Ethernet, for example ...
Oddly enough, most link-state routing protocols = have this optimization.
Added further description on why = it is helpful.


So, the things that you did to this, and the precious = comment, helps. The =E2=80=9Cdesignated router=E2=80=9D (or = equivalent/derivatives/*) mechanism is, as you point out, well known and = well used. I was yanking your chain a little bit here to get, well, = pretty much the explanation and discussion that you gave. Thank you for = that.

Nit, though, just so that I feel = useful in doing this:

OLD:
= = MAY also be chosen at runtime.  Main consideration when = selecting

NEW:
MAY also = be chosen at runtime.  The main consideration when selecting


But, good job here.

Thanks :) Addressed.

;)


o Section = 7.2.3, I worry when I see something like this:

= = = "The whole network should have roughly the same idea about the = time
since origination of any = particular published state."

What is = the definition of "roughly"?
Is the "should" intentionally in = non-caps?
What're the consequences if = not?
[Note that trickle almost = mechanically makes information propagate
with = non-trivial jitter across a network, so how do you ensure this?]
Clarified the paragraph, since the original text = could be interpreted
invertedly.
Another nit=E2=80=A6

= Every node, including the originating one

what is =E2=80=9Cthe originating one=E2=80=9D, is it = =E2=80=9C=E2=80=A6including the node originating this TLV=E2=80=9D?

Otherwise, yes to your clarification.

=E2=80=98this TLV=E2=80=99 is = also confusing, as you could say the TLV itself is sent by all nodes and = as it is not passed verbatim (timestamp changes) it cannot be said to be = originated by someone.

Inserted =E2=80=9CEver= y node, including the node publishing the node data,=E2=80=9D for = now.


I think that this works.

Recapitulating, I see basically two potential = issues where we do not yet have resolution:

o Versioning 
o = Address/Endpoint terminology

That=E2=80=99s already great = progress. 

For the former, = either the proposal I made in this email (which included a lunch = appointment in 15 years time), or it may be one of those cases where we = will agree to disagree and have the RTG-ADs figure out what they want to = take it as.

For the latter, I=E2=80=99= ll try to come up with something that might make sense (I may meet = Pierre tomorrow and bounce it around with him over coffee) and shoot = back, but anybody else with a proposal=E2=80=A6please chip = in.
 
Thanks for this exchange, it=E2=80=99s= engaging and constructive and I can=E2=80=99t wait to review -09 = (regardless of what comes from the two above items).

Cheers,

Thomas

Cheers,

-Markus

= --Apple-Mail=_2732A1FC-D0D0-4DB7-AA21-2F49CA9A3B1F-- From nobody Wed Jul 29 05:53:09 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10021A8A84; Wed, 29 Jul 2015 05:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_MY_NAME_IS=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xox39FM2MT5; Wed, 29 Jul 2015 05:52:56 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBF21A8A7F; Wed, 29 Jul 2015 05:52:43 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 12:52:26 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0225.018; Wed, 29 Jul 2015 12:52:27 +0000 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" Thread-Topic: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4roffYaBLXOTjabFYQ9m7cUoAApb99Q Date: Wed, 29 Jul 2015 12:52:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tools.ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [109.66.1.206] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:bCnfCQ6yGm8Avp5Pv3G2L6/yv0ddhft+HRVwo8FXybR4JmfJ+ujDsUFdILPgdfeK+2d6KkRgknF4grsP7YpV2ZTnDpqxUbVov1a1MLWsfogxcMJs6eo/xQpS+8U0HvT43vvdgJyUT8Jt75SXZ/WqpA==; 24:4+2nFIfuhst80kX3iWBIYABz93vCz5i0npgxdX7zHOKIbRGnvekKWsQLCBe9S++OozZTPYzcXq10DRx5Hg+H2fNuyPXV4MxPrv+M6aMcbFM=; 20:Wrtkoc3jeQw+sYZu2lH1+AfYIfM5hSkfP1KpRtHdeRPUPRaIWtZj8qRV51HDp3Fcy8+twoqlmnbpxlxbdzq2hw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; db3pr03mb0779: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(37854004)(252514010)(66654002)(46102003)(76576001)(66066001)(19580405001)(86362001)(19625215002)(33656002)(54356999)(19609705001)(102836002)(50986999)(16236675004)(2656002)(230783001)(19580395003)(87936001)(74316001)(555904002)(19300405004)(5003600100002)(77156002)(122556002)(62966003)(92566002)(15975445007)(19617315012)(5002640100001)(2351001)(77096005)(5001920100001)(2501003)(189998001)(110136002)(5001960100002)(40100003)(2900100001)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 12:52:26.8819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 12:53:04 -0000 --_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My previous message has been put on hold by the moderator of the SPRING WG = as having too many recipients. This is partially due to the draft having 12 authors - and have tried to s= end the review to each of them:). I am now re-sending it with a shorter (but, hopefully, sufficient - I belie= ve all the authors are on the SPRING mailing list anyway) list of recipient= s and with one more issue I have found in the draft - highlighted. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Alexander Vainshtein Sent: Tuesday, July 28, 2015 7:37 PM To: 'rtg-ads@tools.ietf.org' Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonathan Hardw= ick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfil@cisco= .com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkowski@oran= ge.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.sh= akir@bt.com'; 'saku@ytti.fi'; 'wim.henderickx@alcatel-lucent.com'; 'Jeff Ta= ntsura (jeff.tantsura@ericsson.com)'; 'edward.crabbe@gmail.com' Subject: RE: Routing directorate QA review of draft-filsfils-spring-segment= -routing-ldp-interop Hi, My name is Sasha Vainshtein, and I have been asked to perform the QA revie= w of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing= -ldp-interop/. Due to health problems I have been very late (but, hopefully, not too late)= with this review, and here it is. Does the draft solves a real problem? From my POV, definitely yes. 1. The problem stems from the following combination of fa= cts fact that: a. LDP distributes labels for FECs represented by IP prefixes (among = other things). b. LDP-based MPLS network are very widely deployed c. SR operating over the MPLS DP allocates labels for SIDs that can r= epresent IP prefixes (again, among other things) d. As a consequence, LDP and SR may effectively map the same IP prefix= to different labels. 2. As SR using the MPLS DP is gaining acceptance in the i= ndustry, the following deployment scenarios look as realistic to me: a. Coexistence between LDP-based and SR-based control planes in the = same network b. Partial deployment of SR in some sub-domains of a network combined = with the operators' need to use the benefits of SR where it is already depl= oyed c. Gradual transition of services (especially L2 and L3VPN) tunnelle= d over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa) Is the draft a good enough start for a WG document? From my POV, yes. 1 The draft covers multiple (if not all) realistic use cases for co= existence of LDP-based and SR-based control planes and provides what looks= to me as reasonable solutions for these scenarios. 2 At the same I would think that additional work is required to com= plete the work. Specific issues with the current draft: 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are us= ed without expansion at the first use, and there is no "Abbreviation" secti= on in the draft. 2 Process/Editorial: The draft currently lists 12 authors on its ti= tle page exceeding the recommended RFC Editor maximum of 5 authors. 3. Technical: The draft does not analyse the use case of= coexistence between SR and LDP with enabled extension for multi-area LSPs = as per RFC 5283= . I think that this use case deserves special consideration in the draft be= cause: a. It mentions the use case of seamless MPLS and refers to the (expir= ed) Seamless MPLS Architecture draft b. The seamless MPLS Architecture draft, in its turn, explicitly refe= rs to RFC 5283 in Section 5.1.1 to facilitate binding of labels received vi= a the DoD LDP session while only default route is configured in the RIB of = the access node in the seamless MPLS architecture c. It is possible that this use case would not add anything to the dr= aft - but I would prefer to see it in the document with the appropriate exp= lanation 4. Technical: Section 8 "Manageability Considerations" is= currently left empty. When this section is written, I would expect at leas= t the following: a. Some level of detail regarding local policies defining whether LD= P-created or SR-created LSPs should be used etc. b. Discussion of using LSP Ping for LSPs that are produced by stitchin= g an LDP segment with an SR one. c. Alternatively, it is possible to move this section to a separate d= edicated draft 5. Technical: I think more information should be provided= in Section 5 to explain operational aspects of SR-assisted LDP FR: a. In Section 5.1 I would expect the draft to explain that: i. Node= D is selected as the RLFA using the same logic that is defined for select= ing RLFA in RFC 7490 ii. The "= bypass LSP" is set up by the SR CP automatically without any need for manag= ement intervention iii. I wou= ld like to understand why dynamically set up Targeted LDP sessions are an o= perational concern. Such sessions appear also when BGP-based auto-discovery= for L2VPN is used, and, according to the analysis in RFC 7490, the scalabi= lity problems associated with these sessions look as negligible. b. In Section 5.2 I would expect the draft to explain that: i. The = resulting solution is similar to using a bypass LSP to a manually selected = RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP sessi= on to such an RLFA would be still needed) ii. Set u= p of the "traffic-engineered bypass LSP" by the SR CP is triggered by an a= ppropriate management operation iii. What = information should be provided by the Management Plane for computing the RL= FA and the traffic-engineered bypass LSP? Should it be similar to configur= ation parameters used with RSVP-TE? iv. Which k= ind of logic should be responsible for computing the RLFA and the path to b= e taken by the engineered bypass LSP: should it be similar to the CSPF used= with RSVP-TE? v. How th= e traffic-engineered bypass LSP hat is set up by the SR CP would react to a= dditional changes in the network topology (the behaviour of the bypass LSP = that is set by RSVP-TE in these situations is well known) c. In both cases it is not clear how the backup label and NHOP are in= stalled: i. In t= he FRR with RLFA as per RFC 7490 this is usually done by LDP that receives= the backup label as bound to the destination prefix FEC via the Targeted L= DP session, retains it and decides to us it when a route to the destination= prefix using the LSP leading to the RLFA as its NHOP is installed in the = RIB as the best route to the destination prefix by IP FRR ii. This = scheme definitely would not work if the Targeted LDP session to the selecte= d RLFA is eliminated iii. From = my POV more details are required here, and the critical question here is, o= f course, when the scheme proposed in the draft requires any changes in LDP= . Neither of the issues listed above should be considered as preventing adopt= ion of the draft as a WG document IMO. Actually I think that resolving thes= e issues in the context of a WG document would be more effective. Hopefully these notes will be useful. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Wednesday, May 20, 2015 12:46 PM To: Alexander Vainshtein Cc: bruno.decraene@orange.com; jgs@junipe= r.net; Alvaro Retana (aretana); Jon Hudson Subject: Routing directorate QA review of draft-filsfils-spring-segment-rou= ting-ldp-interop Hi Sasha Please would you be the routing directorate QA reviewer for draft-filsfils-= spring-segment-routing-ldp-interop? https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-= interop/ This initial review has been prompted by the spring WG chairs in parallel w= ith a call for WG adoption. As such, this document qualifies for "initial = QA review". Please could you provide your initial comments in the next 3 w= eeks? As per the QA process, we would also like you to stay with the docum= ent and review it again when it goes to WG last call. The following web page contains a briefing on the QA process, and guidance = for the QA reviewer. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Please copy your comments to the spring and rtgdir mailing lists. Please let me know whether you can do it, or not. Many thanks Jon --_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

My previous message has b= een put on hold by the moderator of the SPRING WG as having too many recipi= ents.

This is partially due to = the draft having 12 authors – and  have tried to send the review= to each of themJ.

 <= /p>

I am now re-sending it wi= th a shorter (but, hopefully, sufficient – I believe all the authors = are on the SPRING mailing list anyway) list of recipients and with one more issue I have found in the draft – highlighted.

 <= /p>

Regards,

Sasha

 <= /p>

Office: +972-39266302=

Cell:   &n= bsp;  +972-549266302

Email:   Alexan= der.Vainshtein@ecitele.com

 <= /p>

From: Alexande= r Vainshtein
Sent: Tuesday, July 28, 2015 7:37 PM
To: 'rtg-ads@tools.ietf.org'
Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonatha= n Hardwick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfi= l@cisco.com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkows= ki@orange.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.shakir@bt.com'; 'saku@ytti.fi'; 'wim.hend= erickx@alcatel-lucent.com'; 'Jeff Tantsura (jeff.tantsura@ericsson.com)'; '= edward.crabbe@gmail.com'
Subject: RE: Routing directorate QA review of draft-filsfils-spring-= segment-routing-ldp-interop

 

Hi,

My na= me is Sasha Vainshtein, and  I have been asked to perform the QA revie= w of https:/= /datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop= /.

 = ;

Due t= o health problems I have been very late (but, hopefully, not too late) with= this review, and here it is.

 = ;

Do= es the draft solves a real problem? From my POV, definitely yes.

   = ;       1.  = ;       The problem stem= s from the following combination of facts fact that:

a.  &nb= sp;    LDP distributes labels for FECs represented by IP prefixes (among oth= er things).

b.  &nb= sp;   LDP-based MPLS network are very widely deployed

c.  &nb= sp;    SR operating over the MPLS DP allocates labels for SIDs that can repr= esent IP prefixes (again, among other things)

d.  &nb= sp;   As a consequence, LDP and SR may effectively map the same IP prefix t= o different labels.

   = ;       2.  = ;       As SR using the = MPLS DP is gaining acceptance in the industry, the following deployment scenarios look as realistic to me:

a.  &nb= sp;    Coexistence  between LDP-based and SR-based contr= ol planes in the same network

b.  &nb= sp;   Partial deployment of SR in some sub-domains of a netw= ork combined with the operators’ need to use the benefits of SR where it is already deployed

c.  &nb= sp;    Gradual transition of services  (especially L2 an= d L3VPN) tunnelled over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa)

 

I= s the draft a good enough start for= a WG document? From my POV, = yes.

1  &nbs= p;      The draft covers multiple (if not all) realistic use c= ases for coexistence of LDP-based and SR-based control planes and provides  what looks to me as reasonable solutions for these scen= arios.

2  &nbs= p;      At the same I would think that additional work is requ= ired to complete the work.

<= o:p> 

Sp= ecific issues with the current draft:

1  &nbs= p;      Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are used without expansion= at the first use, and there is no “Abbreviation” section in th= e draft.

2  &nbs= p;      Process/Editorial: The draft currently lists 12 authors on its title page exceeding the recom= mended RFC Editor maximum of 5 authors.

&n= bsp;         3.  = ;       Technical: The draft does not analyse the use case  of coexistence between SR an= d LDP with enabled extension for multi-area LSPs as per RFC 5283. I think t= hat this use case deserves special consideration in the draft because:

a.=        It mentions the use case of seamless MPLS and refers t= o the (expired) Seamless MPLS Architecture= draft

b.=        The seamless MPLS Architecture draft, in its tur= n, explicitly refers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received via the DoD LDP session while only default rout= e is configured in the RIB of the access node in the seamless MPLS architec= ture

c.=        It is possible that this use case would not add anythi= ng to the draft – but I would prefer to see it in the document with the appropriate explanation

&n= bsp;         4.  = ;       Technical: Section 8 “Manageability Considerations” is currently left emp= ty. When this section is written, I would expect at least the following:

a.=        Some level of detail regarding local  policies de= fining whether LDP-created or SR-created LSPs should be used etc.

b.=       Discussion of using LSP Ping for LSPs that are produce= d by stitching an LDP segment with an SR one.

c.=        Alternatively, it is possible to move this section to = a separate dedicated draft

&n= bsp;         5.  = ;       Technical: I think more information= should be provided in Section 5 to explain operational aspects of SR-assis= ted LDP FR:

a.=        In Section 5.1 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    Node D is selected as the RLFA usi= ng the same logic  that is defined for selecting RLFA in RFC 7490

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    The “bypass LSP” is s= et up by the SR CP automatically without any need for management intervention

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    I would like to understand why d= ynamically set up Targeted LDP sessions are an operational concern. Such sessions appear also when BG= P-based auto-discovery for L2VPN is used, and, according to the analysis in= RFC 7490, the scalability problems associated with these sessions look as = negligible.

b.=       In Section 5.2 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    The resulting solution is similar = to using a bypass LSP to a manually selected RLFA that is set up by RSVP-TE (the difference is t= hat a Targeted LDP session to such an RLFA would be still needed)

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    Set up of the  “traffi= c-engineered bypass LSP” by the SR CP is triggered by an appropriate management operation

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    What information should be provi= ded by the Management Plane for computing the RLFA and the traffic-engineered  bypass LSP? = Should it be similar to configuration parameters used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        iv. &nbs= p;    Which kind of logic should be res= ponsible for computing the RLFA and the path to be taken by the engineered bypass LSP: should it = be similar to the CSPF used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          v.  = ;    How the traffic-engineered bypass = LSP hat is set up by the SR CP would react to additional changes in the network topology (the b= ehaviour of the bypass LSP that is set by RSVP-TE in these situations is we= ll known)

c.     &= nbsp; In b= oth cases it is not clear how the backup label and NHOP are installed:

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       i.  = ;    In the FRR with RLFA  as per RFC 7490 this is usually done by LDP that recei= ves the backup label as bound to the destination prefix FEC via the Targete= d LDP session, retains it and decides to us it when a route to the destinat= ion prefix using the LSP leading to the RLFA as its NHOP is installed in  the RIB as the best route to the de= stination prefix by IP FRR

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     ii. &nbs= p;    <= /span>This scheme definitely would not work if the Targeted LDP session to the select= ed RLFA is eliminated

      =             &nb= sp;            =             &nb= sp;            =     iii. &nb= sp;    From my POV more details are required here, and the critical question here is, of = course, when the scheme proposed in the draft requires any changes in LDP.

 

<= o:p> 

Neith= er of the issues listed above should be considered as preventing adoption o= f the draft as a WG document IMO. Actually I think that resolving these issues in the context of a WG document would be more effective.

&n= bsp;

Hopef= ully these notes will be useful.=

 = ;

Reg= ards,

Sas= ha

&nb= sp;

Office: +972-3= 9266302

Cell:  &= nbsp;   +972-549266302

Email:   Alexander.Vainshtein@ec= itele.com

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Wednesday, May 20, 2015 12:46 PM
To: Alexander Vainshtein
Cc: bruno.decraene@oran= ge.com; jgs@juniper.net; Alvaro Retana (aret= ana); Jon Hudson
Subject: Routing directorate QA review of draft-filsfils-spring-segm= ent-routing-ldp-interop

 

Hi Sa= sha

 = ;

Pleas= e would you be the routing directorate QA reviewer for draft-filsfils-sprin= g-segment-routing-ldp-interop?

https://datatracker.ietf.org/doc/draft-filsfils-sprin= g-segment-routing-ldp-interop/

 = ;

This = initial review has been prompted by the spring WG chairs in parallel with a= call for WG adoption.  As such, this document qualifies for “initial QA review”.  Please could you provide your initi= al comments in the next 3 weeks?  As per the QA process, we would also= like you to stay with the document and review it again when it goes to WG = last call.

 = ;

The f= ollowing web page contains a briefing on the QA process, and guidance for t= he QA reviewer.

htt= ps://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 = ;

Pleas= e copy your comments to the spring and rtgdir mailing lists.

 = ;

Pleas= e let me know whether you can do it, or not.

 = ;

Many = thanks

Jon

 = ;

 = ;

--_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_-- From nobody Wed Jul 29 06:13:12 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220761A9165; Wed, 29 Jul 2015 06:13:08 -0700 (PDT) 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, FSL_MY_NAME_IS=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 7T9yz6ZzCFk3; Wed, 29 Jul 2015 06:13:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C541A90D2; Wed, 29 Jul 2015 06:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10185; q=dns/txt; s=iport; t=1438175586; x=1439385186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+iA6nGtVhljNNSzcCYAE9A8UWVbVfV5v00s0bZeolEQ=; b=HBzMNEs0d5J4BkVD6p2LjYHSTSw5RNZ+wfXU5Kme5sK76/wwC0YWUoAR dru296KT9umfGPYWXQ/P+BPzberBneZdStEqpRBaNXzO+b8dB/HDT4BNt Q65m5ogb9q6a55zuM76FWqbU5rRPoknTS8WcowaOQDTp0HnWPE6OM4i6m 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAwA80LhV/4cNJK1bgxVUaQa7fgmBdwyFLUoCgVY4FAEBAQEBAQGBCoQjAQEBAwEBAQEaTwILBQkCAgEIEQEDAQEoBxYLBgsUAwYIAQEEDgUbh34DCggNyW8NhS8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBASLSoJOgU0JEQEeCCsHAgSDEoEUBYcUhTSBJ4cBAYR5hWCBajmBDIQgjB2DS4NjJoIOHBWBPm8BgQ06gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,570,1432598400"; d="scan'208";a="19709749" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jul 2015 13:13:04 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6TDD3VD030888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jul 2015 13:13:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 29 Jul 2015 08:13:03 -0500 From: "Stefano Previdi (sprevidi)" To: Alexander Vainshtein Thread-Topic: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4rozHs9zgL9Q6awOhnek/vb5wApb99QAAw7GIA= Date: Wed, 29 Jul 2015 13:13:02 +0000 Message-ID: <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.248] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8AA1D18CF509044DABABC87124551150@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 13:13:08 -0000 Hi Sasha, Many thanks for your review and comments. I'll go through them asap. Thanks. s. On Jul 29, 2015, at 2:52 PM, Alexander Vainshtein wrote: > Hi, > My previous message has been put on hold by the moderator of the SPRING W= G as having too many recipients. > This is partially due to the draft having 12 authors =96 and have tried = to send the review to each of themJ. > =20 > I am now re-sending it with a shorter (but, hopefully, sufficient =96 I b= elieve all the authors are on the SPRING mailing list anyway) list of recip= ients andwith one more issue I have found in the draft =96 highlighted. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Alexander Vainshtein=20 > Sent: Tuesday, July 28, 2015 7:37 PM > To: 'rtg-ads@tools.ietf.org' > Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonathan Har= dwick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfil@cis= co.com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkowski@or= ange.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.= shakir@bt.com'; 'saku@ytti.fi'; 'wim.henderickx@alcatel-lucent.com'; 'Jeff = Tantsura (jeff.tantsura@ericsson.com)'; 'edward.crabbe@gmail.com' > Subject: RE: Routing directorate QA review of draft-filsfils-spring-segme= nt-routing-ldp-interop > =20 > Hi, > My name is Sasha Vainshtein, and I have been asked to perform the QA rev= iew of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routi= ng-ldp-interop/. > =20 > Due to health problems I have been very late (but, hopefully, not too lat= e) with this review, and here it is. > =20 > Does the draft solves a real problem? From my POV, definitely yes. > 1. The problem stems from the following combination of = facts fact that: > a. LDP distributes labels for FECs represented by IP prefixes (amon= g other things). > b. LDP-based MPLS network are very widely deployed > c. SR operating over the MPLS DP allocates labels for SIDs that can= represent IP prefixes (again, among other things) > d. As a consequence, LDP and SR may effectively map the same IP pref= ix to different labels. > 2. As SR using the MPLS DP is gaining acceptance in the= industry, the following deployment scenarios look as realistic to me: > a. Coexistence between LDP-based and SR-based control planes in th= e same network > b. Partial deployment of SR in some sub-domains of a network combine= d with the operators=92 need to use the benefits of SR where it is already = deployed > c. Gradual transition of services (especially L2 and L3VPN) tunnel= led over LDP-created LSPs to LSPs set up using SR (and, possibly, vice vers= a) > =20 > Is the draft a good enough start for a WG document? From my POV, yes. > 1 The draft covers multiple (if not all) realistic use cases for = coexistence of LDP-based and SR-based control planes and provides what loo= ks to me as reasonable solutions for these scenarios. > 2 At the same I would think that additional work is required to c= omplete the work. > =20 > Specific issues with the current draft: > 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are = used without expansion at the first use, and there is no =93Abbreviation=94= section in the draft. > 2 Process/Editorial: The draft currently lists 12 authors on its = title page exceeding the recommended RFC Editor maximum of 5 authors. > 3. Technical: The draft does not analyse the use case = of coexistence between SR and LDP with enabled extension for multi-area LSP= s as per RFC 5283. I think that this use case deserves special consideratio= n in the draft because: > a. It mentions the use case of seamless MPLS and refers to the (exp= ired) Seamless MPLS Architecture draft > b. The seamless MPLS Architecture draft, in its turn, explicitly re= fers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received = via the DoD LDP session while only default route is configured in the RIB o= f the access node in the seamless MPLS architecture > c. It is possible that this use case would not add anything to the = draft =96 but I would prefer to see it in the document with the appropriate= explanation > 4. Technical: Section 8 =93Manageability Considerations= =94 is currently left empty. When this section is written, I would expect a= t least the following: > a. Some level of detail regarding local policies defining whether = LDP-created or SR-created LSPs should be used etc. > b. Discussion of using LSP Ping for LSPs that are produced by stitch= ing an LDP segment with an SR one. > c. Alternatively, it is possible to move this section to a separate= dedicated draft > 5. Technical: I think more information should be provid= ed in Section 5 to explain operational aspects of SR-assisted LDP FR: > a. In Section 5.1 I would expect the draft to explain that: > i. No= de D is selected as the RLFA using the same logic that is defined for sele= cting RLFA in RFC 7490 > ii. The= =93bypass LSP=94 is set up by the SR CP automatically without any need for= management intervention > iii. I w= ould like to understand why dynamically set up Targeted LDP sessions are an= operational concern. Such sessions appear also when BGP-based auto-discove= ry for L2VPN is used, and, according to the analysis in RFC 7490, the scala= bility problems associated with these sessions look as negligible. > b. In Section 5.2 I would expect the draft to explain that: > i. Th= e resulting solution is similar to using a bypass LSP to a manually selecte= d RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP ses= sion to such an RLFA would be still needed) > ii. Set= up of the =93traffic-engineered bypass LSP=94 by the SR CP is triggered b= y an appropriate management operation > iii. Wha= t information should be provided by the Management Plane for computing the = RLFA and the traffic-engineered bypass LSP? Should it be similar to config= uration parameters used with RSVP-TE? > iv. Which= kind of logic should be responsible for computing the RLFA and the path to= be taken by the engineered bypass LSP: should it be similar to the CSPF us= ed with RSVP-TE? > v. How = the traffic-engineered bypass LSP hat is set up by the SR CP would react to= additional changes in the network topology (the behaviour of the bypass LS= P that is set by RSVP-TE in these situations is well known) > c. In both cases it is not clear how the backup label and NHOP are = installed: > i. In= the FRR with RLFA as per RFC 7490 this is usually done by LDP that receiv= es the backup label as bound to the destination prefix FEC via the Targeted= LDP session, retains it and decides to us it when a route to the destinati= on prefix using the LSP leading to the RLFA as its NHOP is installed in th= e RIB as the best route to the destination prefix by IP FRR > ii. Thi= s scheme definitely would not work if the Targeted LDP session to the selec= ted RLFA is eliminated > iii. Fro= m my POV more details are required here, and the critical question here is,= of course, when the scheme proposed in the draft requires any changes in L= DP. > =20 > =20 > Neither of the issues listed above should be considered as preventing ado= ption of the draft as a WG document IMO. Actually I think that resolving th= ese issues in the context of a WG document would be more effective. > =20 > Hopefully these notes will be useful. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]=20 > Sent: Wednesday, May 20, 2015 12:46 PM > To: Alexander Vainshtein > Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (aretana); = Jon Hudson > Subject: Routing directorate QA review of draft-filsfils-spring-segment-r= outing-ldp-interop > =20 > Hi Sasha > =20 > Please would you be the routing directorate QA reviewer for draft-filsfil= s-spring-segment-routing-ldp-interop? > https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ld= p-interop/ > =20 > This initial review has been prompted by the spring WG chairs in parallel= with a call for WG adoption. As such, this document qualifies for =93init= ial QA review=94. Please could you provide your initial comments in the ne= xt 3 weeks? As per the QA process, we would also like you to stay with the= document and review it again when it goes to WG last call. > =20 > The following web page contains a briefing on the QA process, and guidanc= e for the QA reviewer. > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa > =20 > Please copy your comments to the spring and rtgdir mailing lists. > =20 > Please let me know whether you can do it, or not. > =20 > Many thanks > Jon > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 29 06:18:02 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0901AC3B6; Wed, 29 Jul 2015 06:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_MY_NAME_IS=0.001, 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 KfzBa2Y4yuCy; Wed, 29 Jul 2015 06:17:55 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E760D1A9236; Wed, 29 Jul 2015 06:17:54 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 13:17:35 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0225.018; Wed, 29 Jul 2015 13:17:35 +0000 From: Alexander Vainshtein To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4roffYaBLXOTjabFYQ9m7cUoAApb99QAAHAcAAAACIm0A== Date: Wed, 29 Jul 2015 13:17:35 +0000 Message-ID: References: <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com> In-Reply-To: <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [109.66.1.206] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:WYrWBIyB7ijOI7VzC8xlwLEKjfCe9VsCngakw8NZ8a13xCdlQdwswszANs4YAhf9bfnl/fPO6AhiS6G2EwbIH0duhYJMU4bhCj1UVAn5Nkh8U3R4w/E+F2917RVo6bQG4azhcy65NmSEMJCY917VOA==; 24:gaWE/tcK3P09UO8VQP0O8u7HzlQgjniOabBvcA5tNnWL9MZ9UdxyLnK+M4mcP3RWpTpIkfG4mYhwsmlsrt9dz/U0SCZpIsjidiwg92tvKU4=; 20:56uUtRGtc/E3Yf6oaIjM8eh+gB8sm39fCbQ3iq7oQbRw7TpX4PAKnKEXiugo8IZtwBdjMoa68RY2SInYoKuhug== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; db3pr03mb0779: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(37854004)(252514010)(66654002)(46102003)(76576001)(66066001)(19580405001)(86362001)(33656002)(54356999)(102836002)(50986999)(2656002)(19580395003)(230783001)(87936001)(555904002)(74316001)(5003600100002)(77156002)(122556002)(62966003)(92566002)(15975445007)(5002640100001)(77096005)(5001920100001)(189998001)(110136002)(2950100001)(5001960100002)(40100003)(76176999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 13:17:35.6391 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 13:17:58 -0000 Hi Stefano, OK by me. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Sent: Wednesday, July 29, 2015 4:13 PM To: Alexander Vainshtein Cc: rtg-ads@tools.ietf.org; Jonathan Hardwick; rtg-dir@ietf.org; spring@iet= f.org; mpls@ietf.org Subject: Re: [spring] Routing directorate QA review of draft-filsfils-sprin= g-segment-routing-ldp-interop Hi Sasha, Many thanks for your review and comments. I'll go through them asap. Thanks. s. On Jul 29, 2015, at 2:52 PM, Alexander Vainshtein wrote: > Hi, > My previous message has been put on hold by the moderator of the SPRING W= G as having too many recipients. > This is partially due to the draft having 12 authors - and have tried to= send the review to each of themJ. > =20 > I am now re-sending it with a shorter (but, hopefully, sufficient - I bel= ieve all the authors are on the SPRING mailing list anyway) list of recipie= nts andwith one more issue I have found in the draft - highlighted. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Alexander Vainshtein=20 > Sent: Tuesday, July 28, 2015 7:37 PM > To: 'rtg-ads@tools.ietf.org' > Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonathan Har= dwick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfil@cis= co.com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkowski@or= ange.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.= shakir@bt.com'; 'saku@ytti.fi'; 'wim.henderickx@alcatel-lucent.com'; 'Jeff = Tantsura (jeff.tantsura@ericsson.com)'; 'edward.crabbe@gmail.com' > Subject: RE: Routing directorate QA review of draft-filsfils-spring-segme= nt-routing-ldp-interop > =20 > Hi, > My name is Sasha Vainshtein, and I have been asked to perform the QA rev= iew of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routi= ng-ldp-interop/. > =20 > Due to health problems I have been very late (but, hopefully, not too lat= e) with this review, and here it is. > =20 > Does the draft solves a real problem? From my POV, definitely yes. > 1. The problem stems from the following combination of = facts fact that: > a. LDP distributes labels for FECs represented by IP prefixes (amon= g other things). > b. LDP-based MPLS network are very widely deployed > c. SR operating over the MPLS DP allocates labels for SIDs that can= represent IP prefixes (again, among other things) > d. As a consequence, LDP and SR may effectively map the same IP pref= ix to different labels. > 2. As SR using the MPLS DP is gaining acceptance in the= industry, the following deployment scenarios look as realistic to me: > a. Coexistence between LDP-based and SR-based control planes in th= e same network > b. Partial deployment of SR in some sub-domains of a network combine= d with the operators' need to use the benefits of SR where it is already de= ployed > c. Gradual transition of services (especially L2 and L3VPN) tunnel= led over LDP-created LSPs to LSPs set up using SR (and, possibly, vice vers= a) > =20 > Is the draft a good enough start for a WG document? From my POV, yes. > 1 The draft covers multiple (if not all) realistic use cases for = coexistence of LDP-based and SR-based control planes and provides what loo= ks to me as reasonable solutions for these scenarios. > 2 At the same I would think that additional work is required to c= omplete the work. > =20 > Specific issues with the current draft: > 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are = used without expansion at the first use, and there is no "Abbreviation" sec= tion in the draft. > 2 Process/Editorial: The draft currently lists 12 authors on its = title page exceeding the recommended RFC Editor maximum of 5 authors. > 3. Technical: The draft does not analyse the use case = of coexistence between SR and LDP with enabled extension for multi-area LSP= s as per RFC 5283. I think that this use case deserves special consideratio= n in the draft because: > a. It mentions the use case of seamless MPLS and refers to the (exp= ired) Seamless MPLS Architecture draft > b. The seamless MPLS Architecture draft, in its turn, explicitly re= fers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received = via the DoD LDP session while only default route is configured in the RIB o= f the access node in the seamless MPLS architecture > c. It is possible that this use case would not add anything to the = draft - but I would prefer to see it in the document with the appropriate e= xplanation > 4. Technical: Section 8 "Manageability Considerations" = is currently left empty. When this section is written, I would expect at le= ast the following: > a. Some level of detail regarding local policies defining whether = LDP-created or SR-created LSPs should be used etc. > b. Discussion of using LSP Ping for LSPs that are produced by stitch= ing an LDP segment with an SR one. > c. Alternatively, it is possible to move this section to a separate= dedicated draft > 5. Technical: I think more information should be provid= ed in Section 5 to explain operational aspects of SR-assisted LDP FR: > a. In Section 5.1 I would expect the draft to explain that: > i. No= de D is selected as the RLFA using the same logic that is defined for sele= cting RLFA in RFC 7490 > ii. The= "bypass LSP" is set up by the SR CP automatically without any need for man= agement intervention > iii. I w= ould like to understand why dynamically set up Targeted LDP sessions are an= operational concern. Such sessions appear also when BGP-based auto-discove= ry for L2VPN is used, and, according to the analysis in RFC 7490, the scala= bility problems associated with these sessions look as negligible. > b. In Section 5.2 I would expect the draft to explain that: > i. Th= e resulting solution is similar to using a bypass LSP to a manually selecte= d RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP ses= sion to such an RLFA would be still needed) > ii. Set= up of the "traffic-engineered bypass LSP" by the SR CP is triggered by an= appropriate management operation > iii. Wha= t information should be provided by the Management Plane for computing the = RLFA and the traffic-engineered bypass LSP? Should it be similar to config= uration parameters used with RSVP-TE? > iv. Which= kind of logic should be responsible for computing the RLFA and the path to= be taken by the engineered bypass LSP: should it be similar to the CSPF us= ed with RSVP-TE? > v. How = the traffic-engineered bypass LSP hat is set up by the SR CP would react to= additional changes in the network topology (the behaviour of the bypass LS= P that is set by RSVP-TE in these situations is well known) > c. In both cases it is not clear how the backup label and NHOP are = installed: > i. In= the FRR with RLFA as per RFC 7490 this is usually done by LDP that receiv= es the backup label as bound to the destination prefix FEC via the Targeted= LDP session, retains it and decides to us it when a route to the destinati= on prefix using the LSP leading to the RLFA as its NHOP is installed in th= e RIB as the best route to the destination prefix by IP FRR > ii. Thi= s scheme definitely would not work if the Targeted LDP session to the selec= ted RLFA is eliminated > iii. Fro= m my POV more details are required here, and the critical question here is,= of course, when the scheme proposed in the draft requires any changes in L= DP. > =20 > =20 > Neither of the issues listed above should be considered as preventing ado= ption of the draft as a WG document IMO. Actually I think that resolving th= ese issues in the context of a WG document would be more effective. > =20 > Hopefully these notes will be useful. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]=20 > Sent: Wednesday, May 20, 2015 12:46 PM > To: Alexander Vainshtein > Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (aretana); = Jon Hudson > Subject: Routing directorate QA review of draft-filsfils-spring-segment-r= outing-ldp-interop > =20 > Hi Sasha > =20 > Please would you be the routing directorate QA reviewer for draft-filsfil= s-spring-segment-routing-ldp-interop? > https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ld= p-interop/ > =20 > This initial review has been prompted by the spring WG chairs in parallel= with a call for WG adoption. As such, this document qualifies for "initia= l QA review". Please could you provide your initial comments in the next 3= weeks? As per the QA process, we would also like you to stay with the doc= ument and review it again when it goes to WG last call. > =20 > The following web page contains a briefing on the QA process, and guidanc= e for the QA reviewer. > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa > =20 > Please copy your comments to the spring and rtgdir mailing lists. > =20 > Please let me know whether you can do it, or not. > =20 > Many thanks > Jon > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 29 07:18:15 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5681A1B82; Wed, 29 Jul 2015 07:18:13 -0700 (PDT) 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 xFwCbwLw9N-5; Wed, 29 Jul 2015 07:18:12 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5F01A1EEE; Wed, 29 Jul 2015 07:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4684; q=dns/txt; s=iport; t=1438179491; x=1439389091; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o2Rjondrqy+/bgItJrN3jeNM8xjgHw+gbt/hgYxXiro=; b=gz6+r0wJrL8FLNXl7OemZlaebhrCe12NU/aTGWKLvfpVOUJwyKZb1hb6 LgM/FCZIyycExNuO96MJhcdrUXhXW//dNLoQN/HHGCTJ1Cuh6YHp7K2VW ohC5dtoiqqAxBok/FZzesJlcjT/BxCGduSlL2vYOO3WA4Z97DctvkwmVk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxAwCl37hV/5xdJa1bgkhNVGkGu34JgXcBCYUvSgKBUjgUAQEBAQEBAYEKhCQBAQQBAQFrCxACAQgOMQchBgsUEQIEDgWIGQMSDcoHDYUvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLToJOgjkHgxiBFAWUcAGKWYFqkgKHLiaDfW+BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,571,1432598400"; d="scan'208,217";a="173551302" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 29 Jul 2015 14:18:11 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6TEIBb3017723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jul 2015 14:18:11 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 29 Jul 2015 09:18:10 -0500 From: "Acee Lindem (acee)" To: Ted Lemon Thread-Topic: [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt Thread-Index: AQHQyUx6fpadDRA2qkqa5St/ATMWqJ3ynpKAgAAhu4CAABFmgIAAAk+A Date: Wed, 29 Jul 2015 14:18:10 +0000 Message-ID: References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> <65260471-77E2-4AEC-9A4B-D8A863069017@fugue.com> In-Reply-To: <65260471-77E2-4AEC-9A4B-D8A863069017@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_BC774C71B9854EED9F8FA073878AB669ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Routing Directorate , Markus Stenberg , Dave Taht , Steven Barth , Thomas Clausen , Routing ADs , "homenet@ietf.org Group" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 14:18:13 -0000 --_000_BC774C71B9854EED9F8FA073878AB669ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 29, 2015, at 10:09 AM, Ted Lemon > wrote: On Jul 29, 2015, at 9:07 AM, Dave Taht > wrote: a bit offtopic, it would be good to have IANA assign some port numbers soon, if they have not already. (?) The way to do this would be for the chairs to ask Terry for an early alloca= tion. Assuming he agrees, the IESG discusses it, and IANA issues it. Hi Ted, As per RFC 7120 (section 3), the request only has to go through the chairs = and ADs - no IESG review required. Anyway, with all the implementation acti= vity, I believe we should move forward with the early allocation process. W= e do this frequently in the routing area. Thanks, Acee _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --_000_BC774C71B9854EED9F8FA073878AB669ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <89547EED1F17C545B47041A0B3523AA6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Jul 29, 2015, at 10:09 AM, Ted Lemon <mellon@fugue.com> wrote:

On Jul 29, 2015, at 9:07 AM, Dave Taht <dave.taht@gmail.com> wrote:
a bit offtopic, it would be good to have IANA assign some port numbers
soon, if they have not already. (?)

The way to do this would be for the chairs to ask Terry for= an early allocation.   Assuming he agrees, the IESG discusses it, and= IANA issues it.

Hi Ted, 
As per RFC 7120 (section 3), the request only has to go through the ch= airs and ADs - no IESG review required. Anyway, with all the implementation= activity, I believe we should move forward with the early allocation proce= ss. We do this frequently in the routing area. 
Thanks,
Acee




_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--_000_BC774C71B9854EED9F8FA073878AB669ciscocom_-- From nobody Wed Jul 29 11:07:55 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9673C1A8764; Wed, 29 Jul 2015 04:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 3h0vvp2wDa1l; Wed, 29 Jul 2015 04:07:10 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.229]) by ietfa.amsl.com (Postfix) with ESMTP id 0940A1A876E; Wed, 29 Jul 2015 04:07:06 -0700 (PDT) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 552B87C90522C5D9; Wed, 29 Jul 2015 14:06:55 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Markus Stenberg In-Reply-To: <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> Date: Wed, 29 Jul 2015 14:06:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> To: Thomas Clausen X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 11:07:53 -0700 Cc: "" , Steven Barth , "homenet@ietf.org Group" , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 11:07:15 -0000 First of all, thanks a lot again for review comments; I think you are = the most critical reviewer we have had yet, and it helps to improve the = document quality a lot :) We have had a number of reviews by this point, = but I believe you have raised order of magnitude more changes than the = second in line who also lives in Paris; is this a coincidence? I think = not. Anyway, on to comments.. Caveat: These are my comments, Steven is likely to fix typos before we = actually hit publish button on -09 :) Executive summary: Minor edits, but as you are good with words, time to = ask for advice - how would you explain =E2=80=9CEndpoint=E2=80=9D in the = terminology? (Anyone else on the list too, feel free to chime up..) Fact: It is not socket. I consider it essentially bidirectional mapping = between an endpoint #, and some transport details (as it is used for = both receiving and sending traffic). Random examples from existing implementations: - _a rule_ that matches that stuff from ::1 is endpoint #1 (on shared = socket) - _a rule_ that we try to contact 2001:db8::1 and denote it as endpoint = #2 (on shared socket) - a socket which is bound to eth0 + port X, and listens to multicast = there, denoted as endpoint #3 - (shared socket on port Y) which is listens to eth1 multicast (and also = deals with eth1 link-local unicast traffic), denoted as endpoint #4 The current text-monster is as follows: Endpoint a locally configured communication endpoint of a DNCP = node, such as a network socket. An endpoint may be bound to a set of = predefined unicast Addresses representing remote DNCP nodes to = individually connect to or to accept connections from whereby = communication with each node is separated (e.g., an individual unicast = UDP message flow per remote node). An endpoint may also be bound to a = whole network interface, then multicast communication is used (in = addition to individual unicast flows) to send certain messages to all = DNCP nodes connected therewith at once as well as to automatically = discover new DNCP nodes. Endpoints are usually in one of the transport = modes specified in Section 4.2. On 28.7.2015, at 18.45, Thomas Clausen wrote: > Authors, for all the points where I have said =E2=80=9Cfine=E2=80=9D, = if you reply to this mail feel free to cut those points out and retain = only outstanding issues. > OK; on a personal-preferences level, the separation between HNCP and = DNCP seems artificial, and it probably is part of the reason why this is = hard to describe. I probably would not have made that separation myself = =E2=80=94 but I am not suggesting that the WG goes back on that decision = (just to be clear), rather that it be called out. >=20 > I can live with what is there. I think the separation makes sense (as DNCP itself is generic algorithm, = more or less); however, the point of separation I am not so sure about = (e.g. concrete TLVs in DNCP feel bit wrong, but there are reasons for = that too; easier to specify DNCP-based protocols). >> We reorganised the document a bit, wrote a better abstract and >> introduction and provided a =E2=80=9CProtocol Overview=E2=80=9D = section, on top of that >> we reorganised the details in an =E2=80=9COperations=E2=80=9D = section. >=20 > OK; I am a good deal more happy now, although not perfectly happy just = yet.=20 >=20 > I still think that it would be fantastic to have an applicability = statement included. Reading the document without any context [as it = might down the line if it was to become an RFC], it=E2=80=99s hard to = understand if =E2=80=9Chey, I have a problem, is DNCP the right lump of = metal to use to make a hammer for it?=E2=80=9D Adding one in -09; however, it is still undergoing edits. Gist of it is = to look at=20 [1] min (keepalive-interval-if-nonzero, churn frequency * number of = nodes) and compare it to Trickle parameters chosen [2] consider amount of TLV change within TLV sets published by nodes = (large set, small changes =3D> may not be the best protocol for the job = due to lack of per-TLV deltas) > As I said in my original review, I think that this is a matter of = scoping the work right. The abstract, and the into, calls out =E2=80=9Ca = generic state synchronization protocol=E2=80=9D =E2=80=94 I=E2=80=99ve = heard OSPF described as such, also (hi Fred!) =E2=80=94 which sounds = very much like =E2=80=9Cboiling the ocean=E2=80=9D, and which I think = the WG is not trying to actually do. WG isn=E2=80=99t, but we wound up doing one anyway. Still, we=E2=80=99re = adding applicability subsection in 09, as I think it is important to = note that DNCP is _not_ the tool for many things. > Why don=E2=80=99t you put a subsection before the last paragraph of = the Introduction =E2=80=9CApplicability=E2=80=9D and then expand on = that? Addressed above. > I just want to note that I enjoyed the expanded terminology - thank = you! There may be a small formatting snafu, at least in the HTML = version, about missing blank lines between (for example) =E2=80=9CAddress=E2= =80=9D and =E2=80=9CEndpoint=E2=80=9D Hopefully fixed. > Going back and looking at that, does it make sense to talk about = =E2=80=9CDNCP network=E2=80=9D, out in the real world, or just in this = document? >=20 > An HNCP network and a TNCP network (that=E2=80=99d be for "Thomas' = Neat Configuration Protocol=E2=80=9D) sure, and such two could co-exist = (but not interoperate) so while they =E2=80=9Cin the abstract=E2=80=9D = would both be instances of DNCP networks, that=E2=80=99d be an abstract = construction altogether. >=20 > Could I suggest that to the definition of =E2=80=9CDNCP network=E2=80=9D= some verbiage to that effect be added? NEW: a set of DNCP nodes running DNCP-based protocol(s) that have = matching DNCP profile. The side effect is that if DNCP profiles match, essentially transit = service is provided even if the implemented protocol is not same. (e.g. = HNCP + SHSP currently.) > Now we=E2=80=99re at tightening up on terminology, I am finding myself = wondering about =E2=80=9CDNCP profile=E2=80=9D and =E2=80=9CDNCP-based = protocol=E2=80=9D as terms, just a little. >=20 > A DNCP profile is=20 > a definition of the set of rules and values > defining the behavior of a fully specified, > implementable protocol which uses DNCP. The DNCP > profile specifies transport method to be used, > which optional parts of the DNCP specification = are > required by that particular protocol, and various > parameters and optional behaviors. In this > document any parameter that a DNCP profile > specifies is prefixed with DNCP_. Contents of a > DNCP profile are specified in Section 9. >=20 > Could we be a little bit more succinct: >=20 > =E2=80=9CA DNCP profile consists of: > o The values for the set of parameters, = given in section 9. > o The set of optional parts of this = specification, which are to be used.=E2=80=9D Adopted the gist of it, although not going to convert to a list (and = retained DNCP_ note as it is useful to understand DNCP_foo coming up = shortly in the next few things). NEW: DNCP profile consists of the values for the set of parameters, given in Section 9. They are prefixed with DNCP_ in this document. It also specifies the set of optional parts of this specification, which are to be used. > For DNCP-based protocol, the doc says: >=20 > A DNCP-based protocol is: > a protocol which provides a DNCP profile, and > potentially much more, e.g., protocol-specific = TLVs > and guidance on how they should be used. >=20 >=20 > Could we be more precise (than =E2=80=9Cpotentially much more=E2=80=9D) = on =E2=80=9CDNCP-based profile=E2=80=9D >=20 > =E2=80=9CA DNCP-based protocol is: > o A DNCP profile, according to Section 9, > o Zero or more TLV assignments from the = registries set up by this specification > o generation and processing rules for = these TLVs NEW: DNCP-based protocol a protocol which provides a DNCP profile, = according to Section 9, and zero or more TLV assignments from the DNCP = profile-specific TLV registry as well as their processing rules. > On the definition of =E2=80=9CAddress=E2=80=9D: >=20 > o What does it mean to be =E2=80=9Crelatively transport = agnostic=E2=80=9D? I=E2=80=99d=20 > say that it=E2=80=99s a little bit like being = =E2=80=9Crelatively pregnant=E2=80=9D =E2=80=94 either you are, or you = are not? Got rid of some relatively=E2=80=99s. > o Why not define an =E2=80=9CAddress=E2=80=9D as = (IPv6-address, Transport, Port)? > (and then, if someone comes along with something that = doesn=E2=80=99t fit that tuple form > down the line, deal with it then?) I am not sure it would help as such. The addressing may also occur = inside transport - think multiple flows multiplexed over single stream = connection, for example. Or local UNIX domain sockets :) > Address, by the way, uses =E2=80=9Cendpoint=E2=80=9D which is defined = below.=20 Transport protocol endpoint and DNCP endpoint are not neccessarily the = same thing. They may have 1:1 relationship, but also 1:N (or possibly = M:N) are possible. Got rid of endpoint in the new definition. NEW: Address an identifier which specifies how to reach a particular instance = of a transport protocol on a particular node. In case of an IPv6 UDP = transport, an address in this specification refers to a tuple (IPv6 = address, UDP port). > Endpoint, then, ends up being defined almost as an =E2=80=9Caddress=E2=80= =9D *except* that there=E2=80=99s the clause =E2=80=9Cmay be bound to a = set of predefined unicast addresses=E2=80=9D [would those be addresses = as previously defined?] >=20 > When I read =E2=80=9CEndpoint=E2=80=9D I end up simply thinking = =E2=80=9CSocket, expressed as (IPv6-address, Transport, Port)=E2=80=9D = but as that was defined above it can=E2=80=99t be it?=20 >=20 > Could you clear that up, please? [Note, it=E2=80=99s better than the = -05, but still confusing] I am not sure how. There has been literally half dozen iterations so = far. I am not sure I like the current one, as it is overly verbose and = apparently not much closer to the goal. (see top) >>> Major Issues: >>> =09 >>> o The introduction does not read well; it contains parts = of something that >>> could be considered as part of an applicability = statement (without it >>> being called out as such, and without forming a complete = applicability >>> statement), and does not actually introduce the = protocol. Reading just >>> the introduction and the abstract, it is very obscure if >>> this is a framework, a protocol, a building block, an = architecture, an >>> algorithm -- and, if either of those, what it is = actually accomplishing, >>> and why one would chose to use DNCP. It does, however, = transpire that >>> "whatever it is", it has two "modes" and that it = requires something >>> (presumably a routing protocol) to provide each "node" = with a topology >>> map. >>> =09 >>> Suggest that a proper introduction consisting of three = parts would be >>> beneficial: (i) what this document is, (ii) what doing = DNCP actually >>> gets you, and (iii) the operating conditions under which = the >>> DNCP is applicable. >>> =09 >>> On the latter point, given that you state that DNCP = requires profiles >>> to provide "actual implementable DNCP based protocols", = it appears >>> important to understand what the limits for "what a = profile can give >>> you" are. >>> =09 >>> I am calling this out as a major issue, since I believe = that it is >>> not just editorial, but is a matter of scoping this = document correctly, >>> and in particular not falling into the trap of "claiming = applicability >>> where it's not". >>=20 >> As noted earlier, the introduction has been reworded and separated = from >> protocol overview also considering your suggestions. >=20 > So this is good, thank you for doing that effort =E2=80=94 it=E2=80=99s = tedious, but it helped. >=20 > To section 3, therefore, a few suggestions: >=20 > 1) Throw an initial paragraph in stating what DNCP does = =E2=80=9Cstate synchronization=E2=80=9D and all that. As this comes after the intro (which does that), I am not sure I agree = with the need. Do you suggest cut-n-paste, or something new here? > 2) =E2=80=9CDNCP discovers the topology of its nodes and = =E2=80=A6=E2=80=9D > Argh=E2=80=A6almost there =E2=80=9Cits nodes=E2=80=9D? > - would that be =E2=80=9Cthe nodes in the = DNCP network=E2=80=9D (which has been defined=E2=80=A6)? > - you=E2=80=99re discovering the topology = (i.e., you actually produce a topology graph?) > or just the presence or absence of nodes = in the network (i.e., a destination list)? > Just state what you do, and it=E2=80=99ll be good. Using the first suggested text. Of course, this =E2=80=99topology=E2=80=99= may be somewhat misleading too as we do not really necessarily have = low-level topology, but just connectivity among DNCP nodes. *sigh* (In point-to-point case, there may be arbitrary number of hops in the = middle DNCP is blissfully unaware of.) > 3) =E2=80=9Cbidirectionally reachable=E2=80=9D =E2=80=94 = call out if that means =E2=80=9Cover one IP hop=E2=80=9D (as in =E2=80=9Co= n the same link=E2=80=9D) > or if it can be =E2=80=9Cbidirectionally reachable, = possibly through a multi-hop path=E2=80=9D >=20 > Actually, why don=E2=80=99t you define that term in the = terminology section, since it appears also > in section 4, and it=E2=80=99d make me go away with this = comment in more places than one ;) Hmm. Given we leave actual transport out, I am not sure how it could be = over one IP hop. Anyway, added a definition (not cut-n-pasting here so Steven has time to = fix it, cough). > 4) =E2=80=9CA hash tree is maintained by each node=E2=80=9D = =E2=80=94 I=E2=80=99ve thought about that, and I think that you may > want to expand a little more. =E2=80=9CA hash tree, = rooted in itself, is maintained by each node=E2=80=9D? > 5) And then, again, the text is almost there, bit just need = a nudge=E2=80=A6how is the tree constructed? > You start fine =E2=80=9Ca node starts with a hash tree = only consisting of itself=E2=80=9D. > Then it announces that, and gets updates. How are those = =E2=80=9Cintegrated=E2=80=9D into the receiving nodes=E2=80=99 > hash tree.=20 > Yes I know how it=E2=80=99d work out (I may be dense, = but not *that* dense ;) ), but I think that it=E2=80=99d be=20 > easy to capture all here and being complete, since = it=E2=80=99s so close. >=20 > By the way, I would state that the hash tree is height 1 in this = section, and add a forward reference to 4.1. Added some forward refs, and updated the text. A hash tree of height 1, rooted in itself, is maintained by each node to = represent the state of all currently reachable nodes (see Section 4.1) = and the Trickle algorithm is used to trigger synchronization (see = Section 4.3).=20 > Section 4, I really like what you have done with it also. As a purely = subjective matter, could there between 4 and 4.1 be some educational = text that describes how the 6 subsections to 4 =E2=80=9Cfit together=E2=80= =9D? As it is right now, it=E2=80=99s a little abrupt. >=20 >>> o The document, in my understanding, defines an exchange = format with >>> limited ability to evolve, as simply "a steam of TLVs". >>>=20 >>> As long as there's never a need to evolve the TLV format = itself, and >>> as long as you do not run out of TLV types, that's not = going to be >>> a problem. The doc sets aside a 16bit TLV type space, = that's reasonable >>> enough, but I worry if eventually a DNCPv2 will need to = evolve the >>> format. One purely hypothetical example could be if a = "sequence number" >>> would be needed in each DNCP message to detect "link = success rates", or >>> something of that sort. >>=20 >> I think on this front we have to agree to disagree; as it is a stream = of >> _unrelated_ TLVs with some rare exceptions (node endpoint ID =3D> = network >> state), a later spec such as DNCPv2 can specify if it wants to that >> every DNCP 'message' contains TLV of type $FOO and uses disjoint set = of >> TLVs to do X. Hell, we do that in HNCP already. >>=20 >=20 > OK, then, in that case what you call a TLV is what I would call a = =E2=80=9CMessage=E2=80=9D =E2=80=94 fair enough, I can do that mental = substitution. >=20 > Now=E2=80=A6that still doesn=E2=80=99t change the fact that you may = end up having to evolve your Message format =E2=80=94 I=E2=80=99m sorry, = your TLV format =E2=80=94 as it appears on the wire, as well as some of = the behaviors that you exhibit through DNCP processing. >=20 > For that, you=E2=80=99ll need a version number. And again, I am sorry, = I cannot come up with a concrete example and =E2=80=94 again =E2=80=94 = that=E2=80=99s part of the dilemma: a future extension that we have not = thought about is, by definition, a future extension that we have not = thought about and so therefore we can=E2=80=99t predict if it will be = interoperable with a what we have now. TLV space is relatively large, and mostly undefined. I still do not see = the problem. I see much more of a problem defining e.g. 4 byte version thing, because = after that speaking =E2=80=98both versions=E2=80=99 of the protocol = becomes hard. >>> I do not have an actual example in mind -- and that's = exactly the point: >>> to be evolutive for the unknown future and (at the very = least) be able >>> to discriminate between "old" and "new". >>> =09 >>> A discussion could be had if a "version number" in each = TLV would do, >>> or if a concept of "protocol message with a version = number" is >>> preferential. I do not believe, however, that "no = version number" is >>> viable. >>=20 >> Since DNCP is an abstract protocol, a concrete protocol on top of it >> might probably want to do versioning for its own purposes (i.e. >> different versions on top of the same DNCP version). In this case = having >> versioning in both DNCP and the derived protocol serves little = purpose. >> HNCP - as first derived protocol - defines a Version-TLV btw. >=20 > Yes but that is a =E2=80=9Cversion TLV=E2=80=9D =E2=80=94 what happens = if the TLV format itself, or some of the DNCP specific processing. >=20 > This, incidentally, goes to the crux of why I =E2=80=94 personally =E2=80= =94 would not have done the split. Had DNCP *exclusively* been an = algorithm, or such, then I could see not needing a version in DNCP, but = in the DNCP-based protocol (HNCP) only. Or, for that matter, had DNCP = been just a frame format with no processing, or something, then I could = see one sequence number sufficing. >=20 > By DNCP being = part-signals-part-procesing-part-behavior-part-framework, which cannot = exist on its own but which requires =E2=80=9Canother protocol which = profiles it and which also defines its own signals, processing, and = behavior=E2=80=9D, yes, you actually having this =E2=80=9Cversion number = conundrum=E2=80=9D. Why? The concrete DNCP-based protocol actually says what it supports, = and e.g. future DNCP extensions are not implicitly part of HNCP, unless = we specify them to be. > You could not fix all this by having a DNCP version number only, but = having a sufficiently large TLV type space? That way, you=E2=80=99d not = need (say) HNCP version numbers, but a HNCPv2 would use TLV types A, B = and D (but not C) from HNCPv1, and would reserve and define TLV types X, = Y, Z ? HNCP has 2^16-few types to play with. Is that not enough? (Only up to 32 and the local tinkering range are excluded from the DNCP = profile specific registry HNCP will set up. However, conflicts in = handling the 256+ range are currently being considered on how they = should be handled.) >>>=20 >>> o Noting that the "overhearing n reduncant transmissions" = is a key >>> retransmission suppression mechanism in Trickle, and = that this >>> seems to assume broad/multicast, using unicast seems to = contradict >>> the statement of "consists of Trickle", at least in the = way the >>> algorithm is defined in RFC6206. Note: it's fine to use = an algorithm >>> outside of its initial scope, but it should be with the = caveat of >>> "which of the characteristics still hold, and which do = not" >> If k < 2, even on point-to-point link, Trickle does reap benefits and >> provides exponential backoff timer. Obviously, we can spell this out >> more explicitly if it helps. > YES, that sort of explanation would be good. Added that to the applicability subsection too. (Pending Steven check, = *grin*) >>> o Section 5.3, penultimate paragraph: >>> =09 >>> "If keep-alives specified in Section 6.1 are NOT = sent by the peer >>> (either the DNCP profile does not specify the use = of keep-alives or >>> the particular peer chooses not to send = keep-alives), some other >>> means MUST be employed to ensure its presence. = When the peer is no >>> longer present, the Neighbor TLV and the local DNCP = peer state MUST >>> be removed." >>> =09 >>> "...some other means MUST be employed to ensure its = presence." -- >>> followed by more MUST verage when a peer disappears...I = am not sure that >>> that's conductive to interoperable implementations. >>> =09 >>> Two implementatons may chose different "means" and then = turn off keep- >>> alives - and be non-interoperable. >>> =09 >>> For interoperability, we need: >>> =09 >>> o A mandatory to implement = mechanism, that always is >>> present, but can be complemented = by another "means", or >>> =09 >>> o A mandatory to implement = mechanism, which by way of a >>> specified negotiation mechanism = can be turned off between >>> two peers, to allow them to use = another "means". >>> =09 >>> If you argument is "...this will be specified in the = profile", then >>> you still should provide the two above in this document, = with the note >>> that "...and a profile may specify which from among = these MUST be >>> used in a given deployment" >>=20 >> Clarified that =E2=80=9Cother means=E2=80=9D, refers to existing = transport-provided >> mechanism, e.g. Ethernet carrier-detection, TCP keep-alives etc. >=20 > Alright, good. Now where is it specified which is to be used? Is that = part of the profile, or should it be? If so, call that out here. >=20 > I=E2=80=99m trying to avoid interoperability issues, for example if I = am using =E2=80=9CTCP keep-alives=E2=80=9D and you are using something = else, can we work together? If this is not a problem, call that out as = something which a device can do as it sees fit (although, for example. = TCP keep-alives presumably expects TCP which is a profile matter =E2=80=A6= ) > I *think* that we are almost there also with this point, so convince = me that the text there won=E2=80=99t cause interoperability issues? = Hiving it off to a profile to specify would do just that (of course, = I=E2=80=99d come back on that in HNCP, instead ;) ). This (like many other things in the spec actually) are local = implementation choices; the MUST is that _a method_ must be used (if no = keep-alives are used). However, to cover the case without any method available, added = following: If the peer does not send keep-alives, and no means to verify presence of the peer are available, the peer MUST be considered = no longer present and it SHOULD not be added back as a peer until = it starts sending keep-alives again. .. omitted security stuff. >>> Minor Issues: >>>=20 >>> Introduction: >>> o 1st paragraph: "reachable nodes"; two things: >>> =09 >>> - I always have a problem with the = term "node"; it is often >>> used as a shorthand for "routers = and hosts, both". I was >>> given to understand that homenet = specifically did not want >>> to consider host changes? >> DNCP is not strictly speaking about homenet (but a strict requirement >> for HNCP which is). Also even in homenet-case non-routers may join = the >> network temporarily in order to e.g. do monitoring. >=20 > But, would those =E2=80=9Cnon-routers=E2=80=9D not speak at least part = of the =E2=80=9Chome net specific protocols=E2=80=9D and thereby not be = =E2=80=9Chosts=E2=80=9D in the =E2=80=9Cgot them from Best Buy and just = clicked OK=E2=80=9D sort of sense?=20 >=20 > So is the crux that we have =E2=80=9Chomenet-aware devices=E2=80=9D = and =E2=80=9Clegacy hosts=E2=80=9D, and that either of us just need to = get with the program? If so, can I insist (gently) on =E2=80=9Chomenet-awa= re devices=E2=80=9D [with a suitable definition] instead of =E2=80=9Cnodes= =E2=80=9D since =E2=80=9Cnodes=E2=80=9D are such an overloaded term that = it=E2=80=99s not even fun any more. Again, this has nothing to do with homenet, but it=E2=80=99s being = pushed in homenet just because it is strict dependency on HNCP. There is already one existing use of DNCP which is very non homenet, = demoed in IETF93 BnB and presented in the WG; I expect there might be = more if we do not make the spec overtly homenet-y. >>> - "Reachable" - does that mean = something as in "radio range", >>> does it mean "on the same link", = does it mean within a >>> specific (DNCP?) domain, or does = it mean simply "on the >>> Internet somewhere"? >> Clarified in the text as =E2=80=9Cbidirectionally reachable=E2=80=9D, = also added >> fwd-references to actual definition. > Suggest also defining in Terminology, and clarifying if this is a = one-hop, or a multi-hop-within-the-homenet, concept. In section 1, I do = not see a forward reference, btw, at least not in latest rev. Added rather verbose description. >>=20 >>> =09 >>> o DNCP network: I read this twice, and came away = with two different >>> understandings, perhaps you can clarify which it = is: >>>=20 >>> o A set of nodes running DNCP, = within the same domain, and >>> for which a path betwen any two = DNCP nodes includes only >>> other DNCP nodes; i.e., a DNCP = network forms a connected >>> component with only other DNCP = nodes. >>> =09 >>> o A set of nodes running DNCP. = They may be anywhere on the >>> Internet, they are part of the = same DNCP network as long >>> as they (through other means) = have learned of each others >>> addresses. >>> =09 >>> In the former, that'd be (for example) a = deployment within my >>> home -- in the latter, it could be a node in my = home and a node in >>> your home forming a DNCP network. >>> =09 >>> The text is not quite clear on this point. >> Both are valid use cases; hopefully clarified. > OK, sadly you clarified it ;) Well, no, not sadly, but you clarified = it to be understandable to me in the above sense. But, if I come up with = the aforementioned TNCP and I use the same transport as HNCP, would a = TNCP and a HNCP node be on the same DNCP network, then? Yes. E.g. SHSP and HNCP share transport, but are ships passing each = other in the night as far as understanding TLVs go. (And unwittingly, = they proxy each other=E2=80=99s state.) >>> o Link: a point of clarification here. In "DNCP = network", there was >>> talk about "unidirectional links" and = "bidirectional links"; in >>> "Link" the definition is somewhat vague = "directly connected" and >>> "can communicate". Could something like "without = decrementing TTL/ >>> hop-count" be added, and could a statement on = bidirectionality >>> (IOW, that this is just an IP link) be added? >> This isn=E2=80=99t IP specific as such; however, some better = definition is >> welcome. some types of IP links are not strictly bidirectional either >> (hello, mesh).=09 > Hi, you rang? ;) >=20 > Actually =E2=80=9Csome mesh protocols=E2=80=9D do go through the = exercise of verifying bidirectionally before even considering them as = useful for whatever the protocol tries to do. >=20 > What I am trying to get at, though, is not this discussion but rather: = what does this Link present to the IP layer, in terms of properties? (802-style) broadcast domain is what we=E2=80=99re probably looking for. = There=E2=80=99s also =E2=80=98multiple access link=E2=80=99 in one place = in the spec, to denote availability of link-local multicast I guess. This terminology could use some further work I think though. =09 >>> Operation >>> =09 >>> o First a generic comment that Trickle itself has = some operating >>> conditions which scopes its applicability, and = it would behove >>> this document to, in its own applicability = statement, call out >>> those. >> Added some comments regarding applicability. >=20 > Better, but I would like to see that reflected also in a dedicated = applicability statement. I do not think we can actually provide so concrete applicability stmt as = Trickle does though (e.g. RAM, LoC, etc) as it depends mostly on the = protocol it runs on + network size + .. >>> Added protocol overview and made connection between trickle, merkle = tree >> and requests more clear. > Indeed, and =E2=80=9Cmerkle trees=E2=80=9D disappeared and became hash = trees somewhere along the line ;) We were misusing the term actually; original Merkle tree was binary hash = tree _only_, and while later on the term became synonymous with (N-ary) = hash tree, when asked for Merkle references, just renaming it hash tree = seemed to be the sensible choice as we were abusing the (original) = definition. >>>=20 >>> o Section 6.2: >>> =09 >>> "An upper bound for the number of neighbors that = are allowed for a >>> (particular type of) link that an endpoint runs = on SHOULD be >>> provided by a DNCP profile, user configuration, = or some hardcoded >>> default in the implementation." >>> =09 >>> A couple of things to that: >>> 1) Can you explain the parenthesis? What = type of link? >>> 2) How does "an endpoint runs on" a link? >>> 3) Why SHOULD? >>> 4) Is this specification seriously = suggesting "some hardcoded >>> default in the implementation" as a = SHOULD? >>>=20 >>> [I am tempted to upgrade this to a "Major issue" simply = because of 4) ] =09 >> Clarified, the choice to use it is not really visible externally. Now >> the text has per multicast-enabled link type constraints, and also >> per-profile support for extension at all. >>=20 >> =09 >>> =09 >>> =09 >>> Also to 6.2, this particular optimization, do you have = any >>> quantification of its actual benefit? What should I look = for to >>> determine if this "optimization" yields a benefit or = not? What are >>> you trying to optimize? Over what link types does this = function? >>> I am dubious that it "optimizes" much, if anything, = across an Ethernet, for example ... >> Oddly enough, most link-state routing protocols have this = optimization. >> Added further description on why it is helpful. >>=20 >=20 > So, the things that you did to this, and the precious comment, helps. = The =E2=80=9Cdesignated router=E2=80=9D (or equivalent/derivatives/*) = mechanism is, as you point out, well known and well used. I was yanking = your chain a little bit here to get, well, pretty much the explanation = and discussion that you gave. Thank you for that. >=20 > Nit, though, just so that I feel useful in doing this: >=20 > OLD: > MAY also be chosen at runtime. Main consideration when = selecting=20 >=20 > NEW: > MAY also be chosen at runtime. The main consideration = when selecting=20 >=20 >=20 > But, good job here. Thanks :) Addressed. =09 >>> o Section 7.2.3, I worry when I see something like this: >>> =09 >>> "The whole network should have roughly the same = idea about the time >>> since origination of any particular published = state." >>> =09 >>> What is the definition of "roughly"? >>> Is the "should" intentionally in non-caps? >>> What're the consequences if not? >>> [Note that trickle almost mechanically makes information = propagate >>> with non-trivial jitter across a network, so how do you = ensure this?] >> Clarified the paragraph, since the original text could be interpreted >> invertedly. > Another nit=E2=80=A6 >=20 > Every node, including the originating one >=20 > what is =E2=80=9Cthe originating one=E2=80=9D, is it =E2=80=9C=E2=80=A6i= ncluding the node originating this TLV=E2=80=9D? >=20 > Otherwise, yes to your clarification. =E2=80=98this TLV=E2=80=99 is also confusing, as you could say the TLV = itself is sent by all nodes and as it is not passed verbatim (timestamp = changes) it cannot be said to be originated by someone. Inserted =E2=80=9CEvery node, including the node publishing the node = data,=E2=80=9D for now. Cheers, -Markus= From SRS0=pK59=IF=darou.fr=pierre@bounces.m4x.org Wed Jul 29 05:02:21 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A3E1A8874; Wed, 29 Jul 2015 05:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9aHHn3N4sTVV; Wed, 29 Jul 2015 05:02:14 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BFC1A886F; Wed, 29 Jul 2015 05:01:59 -0700 (PDT) Received: from [10.148.10.17] (unknown [173.38.220.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id BF988140912F0; Wed, 29 Jul 2015 14:01:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Pierre Pfister In-Reply-To: <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> Date: Wed, 29 Jul 2015 14:01:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.2102) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Jul 29 14:01:56 2015 +0200 (CEST)) Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 11:07:53 -0700 Cc: "" , Steven Barth , "homenet@ietf.org Group" , Thomas Clausen , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 12:05:32 -0000 Hello Markus, I could not find-out what french-guy-living-in-Paris you are referring = to, so I wanted to make sure I at least have the 3rd position. ;) I think the complexity about the Endpoint definition mostly comes from = the fact that a DNCP Endpoint is half-defined by configuration and = half-defined by the profile. Some parameters such as trickle parameters = are defined as Profile parameters, while they should, IMHO, be defined = "per-endpoint". This may require some work but I think the document should specify on = one side what are the global parameters that must be shared by all = participating nodes (the global profile), and on another side what are = the different endpoint parameters that must (or sometimes not, as = Trickle parameters) be shared by all DNCP nodes on a given = =E2=80=98=E2=80=99=E2=80=99=E2=80=99=E2=80=99link=E2=80=99=E2=80=99=E2=80=99= =E2=80=99=E2=80=99 (with lots of =E2=80=98=E2=80=99=E2=80=99), i.e., the = endpoint profile, and allow them to exchange packets and establish a = durable neighboring relationship. With that approach it looks to me that a Endpoint could be defined this = way (Probably not best wording, but you will get the idea): Endpoint: Set of rules and parameters associated with a unique Endpoint = identifier which: - Determines how to send DNCP packets toward other DNCP nodes. - Determines how to establish, keep and teardown neighboring = relationships between two DNCP nodes. - Classifies a received DNCP packet as received on a given = Endpoint (If a received packet can=E2=80=99t be associated with any = Endpoint, it MUST be ignored). Now, adopting such an approach in the document may have significant = impact over its organization, but at least it would help separate what = is globally unique from what is local to neighboring relationships. On a different topic, I think reserving 32 TLV types to DNCP is far from = being enough.=20 If DNCP is successful, it may be used by many different profiles. There = could be a need to extend DNCP in order to improve all profiles at once. = Limiting DNCP extensions to only 21 new TLVs is unnecessary and would = make that process harder. Reserving more TLVs would be virtually free = and help in the future. I guess that comment joins Thomas=E2=80=99 comment about version = numbers, with which I agree (that we should add one). It=E2=80=99s not = because DNCP is not a protocol that we should not think about how it = could be improved and extended such that all already-defined profiles = profit from the improvement. Sure it would not be *impossible* to do it = with the current document. But it costs nothing to make it easier. Cheers - Pierre > Le 29 juil. 2015 =C3=A0 13:06, Markus Stenberg = a =C3=A9crit : >=20 > First of all, thanks a lot again for review comments; I think you are = the most critical reviewer we have had yet, and it helps to improve the = document quality a lot :) We have had a number of reviews by this point, = but I believe you have raised order of magnitude more changes than the = second in line who also lives in Paris; is this a coincidence? I think = not. Anyway, on to comments.. >=20 > Caveat: These are my comments, Steven is likely to fix typos before we = actually hit publish button on -09 :) >=20 > Executive summary: Minor edits, but as you are good with words, time = to ask for advice - how would you explain =E2=80=9CEndpoint=E2=80=9D in = the terminology? (Anyone else on the list too, feel free to chime up..) >=20 > Fact: It is not socket. I consider it essentially bidirectional = mapping between an endpoint #, and some transport details (as it is used = for both receiving and sending traffic). >=20 > Random examples from existing implementations: >=20 > - _a rule_ that matches that stuff from ::1 is endpoint #1 (on shared = socket) > - _a rule_ that we try to contact 2001:db8::1 and denote it as = endpoint #2 (on shared socket) > - a socket which is bound to eth0 + port X, and listens to multicast = there, denoted as endpoint #3 > - (shared socket on port Y) which is listens to eth1 multicast (and = also deals with eth1 link-local unicast traffic), denoted as endpoint #4 >=20 > The current text-monster is as follows: >=20 > Endpoint a locally configured communication endpoint of a DNCP = node, such as a network socket. An endpoint may be bound to a set of = predefined unicast Addresses representing remote DNCP nodes to = individually connect to or to accept connections from whereby = communication with each node is separated (e.g., an individual unicast = UDP message flow per remote node). An endpoint may also be bound to a = whole network interface, then multicast communication is used (in = addition to individual unicast flows) to send certain messages to all = DNCP nodes connected therewith at once as well as to automatically = discover new DNCP nodes. Endpoints are usually in one of the transport = modes specified in Section 4.2. >=20 > On 28.7.2015, at 18.45, Thomas Clausen wrote: >> Authors, for all the points where I have said =E2=80=9Cfine=E2=80=9D, = if you reply to this mail feel free to cut those points out and retain = only outstanding issues. >> OK; on a personal-preferences level, the separation between HNCP and = DNCP seems artificial, and it probably is part of the reason why this is = hard to describe. I probably would not have made that separation myself = =E2=80=94 but I am not suggesting that the WG goes back on that decision = (just to be clear), rather that it be called out. >>=20 >> I can live with what is there. >=20 > I think the separation makes sense (as DNCP itself is generic = algorithm, more or less); however, the point of separation I am not so = sure about (e.g. concrete TLVs in DNCP feel bit wrong, but there are = reasons for that too; easier to specify DNCP-based protocols). >=20 >>> We reorganised the document a bit, wrote a better abstract and >>> introduction and provided a =E2=80=9CProtocol Overview=E2=80=9D = section, on top of that >>> we reorganised the details in an =E2=80=9COperations=E2=80=9D = section. >>=20 >> OK; I am a good deal more happy now, although not perfectly happy = just yet.=20 >>=20 >> I still think that it would be fantastic to have an applicability = statement included. Reading the document without any context [as it = might down the line if it was to become an RFC], it=E2=80=99s hard to = understand if =E2=80=9Chey, I have a problem, is DNCP the right lump of = metal to use to make a hammer for it?=E2=80=9D >=20 > Adding one in -09; however, it is still undergoing edits. Gist of it = is to look at=20 >=20 > [1] min (keepalive-interval-if-nonzero, churn frequency * number of = nodes) and compare it to Trickle parameters chosen > [2] consider amount of TLV change within TLV sets published by nodes = (large set, small changes =3D> may not be the best protocol for the job = due to lack of per-TLV deltas) >=20 >> As I said in my original review, I think that this is a matter of = scoping the work right. The abstract, and the into, calls out =E2=80=9Ca = generic state synchronization protocol=E2=80=9D =E2=80=94 I=E2=80=99ve = heard OSPF described as such, also (hi Fred!) =E2=80=94 which sounds = very much like =E2=80=9Cboiling the ocean=E2=80=9D, and which I think = the WG is not trying to actually do. >=20 > WG isn=E2=80=99t, but we wound up doing one anyway. Still, we=E2=80=99re= adding applicability subsection in 09, as I think it is important to = note that DNCP is _not_ the tool for many things. >=20 >> Why don=E2=80=99t you put a subsection before the last paragraph of = the Introduction =E2=80=9CApplicability=E2=80=9D and then expand on = that? >=20 > Addressed above. >=20 >> I just want to note that I enjoyed the expanded terminology - thank = you! There may be a small formatting snafu, at least in the HTML = version, about missing blank lines between (for example) =E2=80=9CAddress=E2= =80=9D and =E2=80=9CEndpoint=E2=80=9D >=20 > Hopefully fixed. >=20 >> Going back and looking at that, does it make sense to talk about = =E2=80=9CDNCP network=E2=80=9D, out in the real world, or just in this = document? >>=20 >> An HNCP network and a TNCP network (that=E2=80=99d be for "Thomas' = Neat Configuration Protocol=E2=80=9D) sure, and such two could co-exist = (but not interoperate) so while they =E2=80=9Cin the abstract=E2=80=9D = would both be instances of DNCP networks, that=E2=80=99d be an abstract = construction altogether. >>=20 >> Could I suggest that to the definition of =E2=80=9CDNCP network=E2=80=9D= some verbiage to that effect be added? >=20 > NEW: a set of DNCP nodes running DNCP-based protocol(s) that have = matching DNCP profile. >=20 > The side effect is that if DNCP profiles match, essentially transit = service is provided even if the implemented protocol is not same. (e.g. = HNCP + SHSP currently.) >=20 >> Now we=E2=80=99re at tightening up on terminology, I am finding = myself wondering about =E2=80=9CDNCP profile=E2=80=9D and =E2=80=9CDNCP-ba= sed protocol=E2=80=9D as terms, just a little. >>=20 >> A DNCP profile is=20 >> a definition of the set of rules and values >> defining the behavior of a fully specified, >> implementable protocol which uses DNCP. The DNCP >> profile specifies transport method to be used, >> which optional parts of the DNCP specification = are >> required by that particular protocol, and various >> parameters and optional behaviors. In this >> document any parameter that a DNCP profile >> specifies is prefixed with DNCP_. Contents of a >> DNCP profile are specified in Section 9. >>=20 >> Could we be a little bit more succinct: >>=20 >> =E2=80=9CA DNCP profile consists of: >> o The values for the set of parameters, = given in section 9. >> o The set of optional parts of this = specification, which are to be used.=E2=80=9D >=20 > Adopted the gist of it, although not going to convert to a list (and = retained DNCP_ note as it is useful to understand DNCP_foo coming up = shortly in the next few things). >=20 > NEW: > DNCP profile consists of the values for the set of parameters, > given in Section 9. They are prefixed with DNCP_ = in > this document. It also specifies the set of > optional parts of this specification, which are to > be used. >=20 >=20 >> For DNCP-based protocol, the doc says: >>=20 >> A DNCP-based protocol is: >> a protocol which provides a DNCP profile, and >> potentially much more, e.g., protocol-specific = TLVs >> and guidance on how they should be used. >>=20 >>=20 >> Could we be more precise (than =E2=80=9Cpotentially much more=E2=80=9D)= on =E2=80=9CDNCP-based profile=E2=80=9D >>=20 >> =E2=80=9CA DNCP-based protocol is: >> o A DNCP profile, according to Section 9, >> o Zero or more TLV assignments from the = registries set up by this specification >> o generation and processing rules for = these TLVs >=20 >=20 > NEW: > DNCP-based protocol a protocol which provides a DNCP profile, = according to Section 9, and zero or more TLV assignments from the DNCP = profile-specific TLV registry as well as their processing rules. >=20 >> On the definition of =E2=80=9CAddress=E2=80=9D: >>=20 >> o What does it mean to be =E2=80=9Crelatively transport = agnostic=E2=80=9D? I=E2=80=99d=20 >> say that it=E2=80=99s a little bit like being = =E2=80=9Crelatively pregnant=E2=80=9D =E2=80=94 either you are, or you = are not? >=20 > Got rid of some relatively=E2=80=99s. >=20 >> o Why not define an =E2=80=9CAddress=E2=80=9D as = (IPv6-address, Transport, Port)? >> (and then, if someone comes along with something that = doesn=E2=80=99t fit that tuple form >> down the line, deal with it then?) >=20 > I am not sure it would help as such. The addressing may also occur = inside transport - think multiple flows multiplexed over single stream = connection, for example. Or local UNIX domain sockets :) >=20 >> Address, by the way, uses =E2=80=9Cendpoint=E2=80=9D which is defined = below.=20 >=20 > Transport protocol endpoint and DNCP endpoint are not neccessarily the = same thing. They may have 1:1 relationship, but also 1:N (or possibly = M:N) are possible. Got rid of endpoint in the new definition. >=20 > NEW: >=20 > Address an identifier which specifies how to reach a particular = instance of a transport protocol on a particular node. In case of an = IPv6 UDP transport, an address in this specification refers to a tuple = (IPv6 address, UDP port). >=20 >> Endpoint, then, ends up being defined almost as an =E2=80=9Caddress=E2=80= =9D *except* that there=E2=80=99s the clause =E2=80=9Cmay be bound to a = set of predefined unicast addresses=E2=80=9D [would those be addresses = as previously defined?] >>=20 >> When I read =E2=80=9CEndpoint=E2=80=9D I end up simply thinking = =E2=80=9CSocket, expressed as (IPv6-address, Transport, Port)=E2=80=9D = but as that was defined above it can=E2=80=99t be it?=20 >>=20 >> Could you clear that up, please? [Note, it=E2=80=99s better than the = -05, but still confusing] >=20 > I am not sure how. There has been literally half dozen iterations so = far. I am not sure I like the current one, as it is overly verbose and = apparently not much closer to the goal. >=20 > (see top) >=20 >>>> Major Issues: >>>> =09 >>>> o The introduction does not read well; it contains parts = of something that >>>> could be considered as part of an applicability = statement (without it >>>> being called out as such, and without forming a complete = applicability >>>> statement), and does not actually introduce the = protocol. Reading just >>>> the introduction and the abstract, it is very obscure if >>>> this is a framework, a protocol, a building block, an = architecture, an >>>> algorithm -- and, if either of those, what it is = actually accomplishing, >>>> and why one would chose to use DNCP. It does, however, = transpire that >>>> "whatever it is", it has two "modes" and that it = requires something >>>> (presumably a routing protocol) to provide each "node" = with a topology >>>> map. >>>> =09 >>>> Suggest that a proper introduction consisting of three = parts would be >>>> beneficial: (i) what this document is, (ii) what doing = DNCP actually >>>> gets you, and (iii) the operating conditions under which = the >>>> DNCP is applicable. >>>> =09 >>>> On the latter point, given that you state that DNCP = requires profiles >>>> to provide "actual implementable DNCP based protocols", = it appears >>>> important to understand what the limits for "what a = profile can give >>>> you" are. >>>> =09 >>>> I am calling this out as a major issue, since I believe = that it is >>>> not just editorial, but is a matter of scoping this = document correctly, >>>> and in particular not falling into the trap of "claiming = applicability >>>> where it's not". >>>=20 >>> As noted earlier, the introduction has been reworded and separated = from >>> protocol overview also considering your suggestions. >>=20 >> So this is good, thank you for doing that effort =E2=80=94 it=E2=80=99s= tedious, but it helped. >>=20 >> To section 3, therefore, a few suggestions: >>=20 >> 1) Throw an initial paragraph in stating what DNCP does = =E2=80=9Cstate synchronization=E2=80=9D and all that. >=20 > As this comes after the intro (which does that), I am not sure I agree = with the need. Do you suggest cut-n-paste, or something new here? >=20 >> 2) =E2=80=9CDNCP discovers the topology of its nodes and = =E2=80=A6=E2=80=9D >> Argh=E2=80=A6almost there =E2=80=9Cits nodes=E2=80=9D? >> - would that be =E2=80=9Cthe nodes in the = DNCP network=E2=80=9D (which has been defined=E2=80=A6)? >> - you=E2=80=99re discovering the topology = (i.e., you actually produce a topology graph?) >> or just the presence or absence of nodes = in the network (i.e., a destination list)? >> Just state what you do, and it=E2=80=99ll be good. >=20 > Using the first suggested text. Of course, this =E2=80=99topology=E2=80=99= may be somewhat misleading too as we do not really necessarily have = low-level topology, but just connectivity among DNCP nodes. *sigh* >=20 > (In point-to-point case, there may be arbitrary number of hops in the = middle DNCP is blissfully unaware of.) >=20 >> 3) =E2=80=9Cbidirectionally reachable=E2=80=9D =E2=80=94 = call out if that means =E2=80=9Cover one IP hop=E2=80=9D (as in =E2=80=9Co= n the same link=E2=80=9D) >> or if it can be =E2=80=9Cbidirectionally reachable, = possibly through a multi-hop path=E2=80=9D >>=20 >> Actually, why don=E2=80=99t you define that term in the = terminology section, since it appears also >> in section 4, and it=E2=80=99d make me go away with this = comment in more places than one ;) >=20 > Hmm. Given we leave actual transport out, I am not sure how it could = be over one IP hop. >=20 > Anyway, added a definition (not cut-n-pasting here so Steven has time = to fix it, cough). >=20 >> 4) =E2=80=9CA hash tree is maintained by each node=E2=80=9D = =E2=80=94 I=E2=80=99ve thought about that, and I think that you may >> want to expand a little more. =E2=80=9CA hash tree, = rooted in itself, is maintained by each node=E2=80=9D? >> 5) And then, again, the text is almost there, bit just need = a nudge=E2=80=A6how is the tree constructed? >> You start fine =E2=80=9Ca node starts with a hash tree = only consisting of itself=E2=80=9D. >> Then it announces that, and gets updates. How are those = =E2=80=9Cintegrated=E2=80=9D into the receiving nodes=E2=80=99 >> hash tree.=20 >> Yes I know how it=E2=80=99d work out (I may be dense, = but not *that* dense ;) ), but I think that it=E2=80=99d be=20 >> easy to capture all here and being complete, since = it=E2=80=99s so close. >>=20 >> By the way, I would state that the hash tree is height 1 in this = section, and add a forward reference to 4.1. >=20 > Added some forward refs, and updated the text. >=20 > A hash tree of height 1, rooted in itself, is maintained by each node = to represent the state of all currently reachable nodes (see Section = 4.1) and the Trickle algorithm is used to trigger synchronization (see = Section 4.3).=20 >=20 >> Section 4, I really like what you have done with it also. As a purely = subjective matter, could there between 4 and 4.1 be some educational = text that describes how the 6 subsections to 4 =E2=80=9Cfit together=E2=80= =9D? As it is right now, it=E2=80=99s a little abrupt. >>=20 >>>> o The document, in my understanding, defines an exchange = format with >>>> limited ability to evolve, as simply "a steam of TLVs". >>>>=20 >>>> As long as there's never a need to evolve the TLV format = itself, and >>>> as long as you do not run out of TLV types, that's not = going to be >>>> a problem. The doc sets aside a 16bit TLV type space, = that's reasonable >>>> enough, but I worry if eventually a DNCPv2 will need to = evolve the >>>> format. One purely hypothetical example could be if a = "sequence number" >>>> would be needed in each DNCP message to detect "link = success rates", or >>>> something of that sort. >>>=20 >>> I think on this front we have to agree to disagree; as it is a = stream of >>> _unrelated_ TLVs with some rare exceptions (node endpoint ID =3D> = network >>> state), a later spec such as DNCPv2 can specify if it wants to that >>> every DNCP 'message' contains TLV of type $FOO and uses disjoint set = of >>> TLVs to do X. Hell, we do that in HNCP already. >>>=20 >>=20 >> OK, then, in that case what you call a TLV is what I would call a = =E2=80=9CMessage=E2=80=9D =E2=80=94 fair enough, I can do that mental = substitution. >>=20 >> Now=E2=80=A6that still doesn=E2=80=99t change the fact that you may = end up having to evolve your Message format =E2=80=94 I=E2=80=99m sorry, = your TLV format =E2=80=94 as it appears on the wire, as well as some of = the behaviors that you exhibit through DNCP processing. >>=20 >> For that, you=E2=80=99ll need a version number. And again, I am = sorry, I cannot come up with a concrete example and =E2=80=94 again =E2=80= =94 that=E2=80=99s part of the dilemma: a future extension that we have = not thought about is, by definition, a future extension that we have not = thought about and so therefore we can=E2=80=99t predict if it will be = interoperable with a what we have now. >=20 > TLV space is relatively large, and mostly undefined. I still do not = see the problem. >=20 > I see much more of a problem defining e.g. 4 byte version thing, = because after that speaking =E2=80=98both versions=E2=80=99 of the = protocol becomes hard. >=20 >>>> I do not have an actual example in mind -- and that's = exactly the point: >>>> to be evolutive for the unknown future and (at the very = least) be able >>>> to discriminate between "old" and "new". >>>> =09 >>>> A discussion could be had if a "version number" in each = TLV would do, >>>> or if a concept of "protocol message with a version = number" is >>>> preferential. I do not believe, however, that "no = version number" is >>>> viable. >>>=20 >>> Since DNCP is an abstract protocol, a concrete protocol on top of it >>> might probably want to do versioning for its own purposes (i.e. >>> different versions on top of the same DNCP version). In this case = having >>> versioning in both DNCP and the derived protocol serves little = purpose. >>> HNCP - as first derived protocol - defines a Version-TLV btw. >>=20 >> Yes but that is a =E2=80=9Cversion TLV=E2=80=9D =E2=80=94 what = happens if the TLV format itself, or some of the DNCP specific = processing. >>=20 >> This, incidentally, goes to the crux of why I =E2=80=94 personally = =E2=80=94 would not have done the split. Had DNCP *exclusively* been an = algorithm, or such, then I could see not needing a version in DNCP, but = in the DNCP-based protocol (HNCP) only. Or, for that matter, had DNCP = been just a frame format with no processing, or something, then I could = see one sequence number sufficing. >>=20 >> By DNCP being = part-signals-part-procesing-part-behavior-part-framework, which cannot = exist on its own but which requires =E2=80=9Canother protocol which = profiles it and which also defines its own signals, processing, and = behavior=E2=80=9D, yes, you actually having this =E2=80=9Cversion number = conundrum=E2=80=9D. >=20 > Why? The concrete DNCP-based protocol actually says what it supports, = and e.g. future DNCP extensions are not implicitly part of HNCP, unless = we specify them to be. >=20 >> You could not fix all this by having a DNCP version number only, but = having a sufficiently large TLV type space? That way, you=E2=80=99d not = need (say) HNCP version numbers, but a HNCPv2 would use TLV types A, B = and D (but not C) from HNCPv1, and would reserve and define TLV types X, = Y, Z ? >=20 > HNCP has 2^16-few types to play with. Is that not enough? >=20 > (Only up to 32 and the local tinkering range are excluded from the = DNCP profile specific registry HNCP will set up. However, conflicts in = handling the 256+ range are currently being considered on how they = should be handled.) >=20 >>>>=20 >>>> o Noting that the "overhearing n reduncant transmissions" = is a key >>>> retransmission suppression mechanism in Trickle, and = that this >>>> seems to assume broad/multicast, using unicast seems to = contradict >>>> the statement of "consists of Trickle", at least in the = way the >>>> algorithm is defined in RFC6206. Note: it's fine to use = an algorithm >>>> outside of its initial scope, but it should be with the = caveat of >>>> "which of the characteristics still hold, and which do = not" >>> If k < 2, even on point-to-point link, Trickle does reap benefits = and >>> provides exponential backoff timer. Obviously, we can spell this out >>> more explicitly if it helps. >> YES, that sort of explanation would be good. >=20 > Added that to the applicability subsection too. (Pending Steven check, = *grin*) >=20 >>>> o Section 5.3, penultimate paragraph: >>>> =09 >>>> "If keep-alives specified in Section 6.1 are NOT = sent by the peer >>>> (either the DNCP profile does not specify the use = of keep-alives or >>>> the particular peer chooses not to send = keep-alives), some other >>>> means MUST be employed to ensure its presence. = When the peer is no >>>> longer present, the Neighbor TLV and the local DNCP = peer state MUST >>>> be removed." >>>> =09 >>>> "...some other means MUST be employed to ensure its = presence." -- >>>> followed by more MUST verage when a peer disappears...I = am not sure that >>>> that's conductive to interoperable implementations. >>>> =09 >>>> Two implementatons may chose different "means" and then = turn off keep- >>>> alives - and be non-interoperable. >>>> =09 >>>> For interoperability, we need: >>>> =09 >>>> o A mandatory to implement = mechanism, that always is >>>> present, but can be complemented = by another "means", or >>>> =09 >>>> o A mandatory to implement = mechanism, which by way of a >>>> specified negotiation mechanism = can be turned off between >>>> two peers, to allow them to use = another "means". >>>> =09 >>>> If you argument is "...this will be specified in the = profile", then >>>> you still should provide the two above in this document, = with the note >>>> that "...and a profile may specify which from among = these MUST be >>>> used in a given deployment" >>>=20 >>> Clarified that =E2=80=9Cother means=E2=80=9D, refers to existing = transport-provided >>> mechanism, e.g. Ethernet carrier-detection, TCP keep-alives etc. >>=20 >> Alright, good. Now where is it specified which is to be used? Is that = part of the profile, or should it be? If so, call that out here. >>=20 >> I=E2=80=99m trying to avoid interoperability issues, for example if I = am using =E2=80=9CTCP keep-alives=E2=80=9D and you are using something = else, can we work together? If this is not a problem, call that out as = something which a device can do as it sees fit (although, for example. = TCP keep-alives presumably expects TCP which is a profile matter =E2=80=A6= ) >> I *think* that we are almost there also with this point, so convince = me that the text there won=E2=80=99t cause interoperability issues? = Hiving it off to a profile to specify would do just that (of course, = I=E2=80=99d come back on that in HNCP, instead ;) ). >=20 > This (like many other things in the spec actually) are local = implementation choices; the MUST is that _a method_ must be used (if no = keep-alives are used). >=20 > However, to cover the case without any method available, added = following: >=20 > If the peer does not send keep-alives, and no means to verify > presence of the peer are available, the peer MUST be considered = no > longer present and it SHOULD not be added back as a peer until = it > starts sending keep-alives again. >=20 > .. omitted security stuff. >=20 >>>> Minor Issues: >>>>=20 >>>> Introduction: >>>> o 1st paragraph: "reachable nodes"; two things: >>>> =09 >>>> - I always have a problem with the = term "node"; it is often >>>> used as a shorthand for "routers = and hosts, both". I was >>>> given to understand that homenet = specifically did not want >>>> to consider host changes? >>> DNCP is not strictly speaking about homenet (but a strict = requirement >>> for HNCP which is). Also even in homenet-case non-routers may join = the >>> network temporarily in order to e.g. do monitoring. >>=20 >> But, would those =E2=80=9Cnon-routers=E2=80=9D not speak at least = part of the =E2=80=9Chome net specific protocols=E2=80=9D and thereby = not be =E2=80=9Chosts=E2=80=9D in the =E2=80=9Cgot them from Best Buy = and just clicked OK=E2=80=9D sort of sense?=20 >>=20 >> So is the crux that we have =E2=80=9Chomenet-aware devices=E2=80=9D = and =E2=80=9Clegacy hosts=E2=80=9D, and that either of us just need to = get with the program? If so, can I insist (gently) on =E2=80=9Chomenet-awa= re devices=E2=80=9D [with a suitable definition] instead of =E2=80=9Cnodes= =E2=80=9D since =E2=80=9Cnodes=E2=80=9D are such an overloaded term that = it=E2=80=99s not even fun any more. >=20 > Again, this has nothing to do with homenet, but it=E2=80=99s being = pushed in homenet just because it is strict dependency on HNCP. >=20 > There is already one existing use of DNCP which is very non homenet, = demoed in IETF93 BnB and presented in the WG; I expect there might be = more if we do not make the spec overtly homenet-y. >=20 >>>> - "Reachable" - does that mean = something as in "radio range", >>>> does it mean "on the same link", = does it mean within a >>>> specific (DNCP?) domain, or does = it mean simply "on the >>>> Internet somewhere"? >>> Clarified in the text as =E2=80=9Cbidirectionally reachable=E2=80=9D, = also added >>> fwd-references to actual definition. >> Suggest also defining in Terminology, and clarifying if this is a = one-hop, or a multi-hop-within-the-homenet, concept. In section 1, I do = not see a forward reference, btw, at least not in latest rev. >=20 > Added rather verbose description. >=20 >>>=20 >>>> =09 >>>> o DNCP network: I read this twice, and came away = with two different >>>> understandings, perhaps you can clarify which it = is: >>>>=20 >>>> o A set of nodes running DNCP, = within the same domain, and >>>> for which a path betwen any two = DNCP nodes includes only >>>> other DNCP nodes; i.e., a DNCP = network forms a connected >>>> component with only other DNCP = nodes. >>>> =09 >>>> o A set of nodes running DNCP. = They may be anywhere on the >>>> Internet, they are part of the = same DNCP network as long >>>> as they (through other means) = have learned of each others >>>> addresses. >>>> =09 >>>> In the former, that'd be (for example) a = deployment within my >>>> home -- in the latter, it could be a node in my = home and a node in >>>> your home forming a DNCP network. >>>> =09 >>>> The text is not quite clear on this point. >>> Both are valid use cases; hopefully clarified. >> OK, sadly you clarified it ;) Well, no, not sadly, but you clarified = it to be understandable to me in the above sense. But, if I come up with = the aforementioned TNCP and I use the same transport as HNCP, would a = TNCP and a HNCP node be on the same DNCP network, then? >=20 > Yes. E.g. SHSP and HNCP share transport, but are ships passing each = other in the night as far as understanding TLVs go. (And unwittingly, = they proxy each other=E2=80=99s state.) >=20 >>>> o Link: a point of clarification here. In "DNCP = network", there was >>>> talk about "unidirectional links" and = "bidirectional links"; in >>>> "Link" the definition is somewhat vague = "directly connected" and >>>> "can communicate". Could something like "without = decrementing TTL/ >>>> hop-count" be added, and could a statement on = bidirectionality >>>> (IOW, that this is just an IP link) be added? >>> This isn=E2=80=99t IP specific as such; however, some better = definition is >>> welcome. some types of IP links are not strictly bidirectional = either >>> (hello, mesh).=09 >> Hi, you rang? ;) >>=20 >> Actually =E2=80=9Csome mesh protocols=E2=80=9D do go through the = exercise of verifying bidirectionally before even considering them as = useful for whatever the protocol tries to do. >>=20 >> What I am trying to get at, though, is not this discussion but = rather: what does this Link present to the IP layer, in terms of = properties? >=20 > (802-style) broadcast domain is what we=E2=80=99re probably looking = for. There=E2=80=99s also =E2=80=98multiple access link=E2=80=99 in one = place in the spec, to denote availability of link-local multicast I = guess. >=20 > This terminology could use some further work I think though. > =09 >>>> Operation >>>> =09 >>>> o First a generic comment that Trickle itself has = some operating >>>> conditions which scopes its applicability, and = it would behove >>>> this document to, in its own applicability = statement, call out >>>> those. >>> Added some comments regarding applicability. >>=20 >> Better, but I would like to see that reflected also in a dedicated = applicability statement. >=20 > I do not think we can actually provide so concrete applicability stmt = as Trickle does though (e.g. RAM, LoC, etc) as it depends mostly on the = protocol it runs on + network size + .. >=20 >>>> Added protocol overview and made connection between trickle, merkle = tree >>> and requests more clear. >> Indeed, and =E2=80=9Cmerkle trees=E2=80=9D disappeared and became = hash trees somewhere along the line ;) >=20 > We were misusing the term actually; original Merkle tree was binary = hash tree _only_, and while later on the term became synonymous with = (N-ary) hash tree, when asked for Merkle references, just renaming it = hash tree seemed to be the sensible choice as we were abusing the = (original) definition. >=20 >>>>=20 >>>> o Section 6.2: >>>> =09 >>>> "An upper bound for the number of neighbors that = are allowed for a >>>> (particular type of) link that an endpoint runs = on SHOULD be >>>> provided by a DNCP profile, user configuration, = or some hardcoded >>>> default in the implementation." >>>> =09 >>>> A couple of things to that: >>>> 1) Can you explain the parenthesis? What = type of link? >>>> 2) How does "an endpoint runs on" a link? >>>> 3) Why SHOULD? >>>> 4) Is this specification seriously = suggesting "some hardcoded >>>> default in the implementation" as a = SHOULD? >>>>=20 >>>> [I am tempted to upgrade this to a "Major issue" simply = because of 4) ] =09 >>> Clarified, the choice to use it is not really visible externally. = Now >>> the text has per multicast-enabled link type constraints, and also >>> per-profile support for extension at all. >>>=20 >>> =09 >>>> =09 >>>> =09 >>>> Also to 6.2, this particular optimization, do you have = any >>>> quantification of its actual benefit? What should I look = for to >>>> determine if this "optimization" yields a benefit or = not? What are >>>> you trying to optimize? Over what link types does this = function? >>>> I am dubious that it "optimizes" much, if anything, = across an Ethernet, for example ... >>> Oddly enough, most link-state routing protocols have this = optimization. >>> Added further description on why it is helpful. >>>=20 >>=20 >> So, the things that you did to this, and the precious comment, helps. = The =E2=80=9Cdesignated router=E2=80=9D (or equivalent/derivatives/*) = mechanism is, as you point out, well known and well used. I was yanking = your chain a little bit here to get, well, pretty much the explanation = and discussion that you gave. Thank you for that. >>=20 >> Nit, though, just so that I feel useful in doing this: >>=20 >> OLD: >> MAY also be chosen at runtime. Main consideration when = selecting=20 >>=20 >> NEW: >> MAY also be chosen at runtime. The main consideration = when selecting=20 >>=20 >>=20 >> But, good job here. >=20 > Thanks :) Addressed. > =09 >>>> o Section 7.2.3, I worry when I see something like this: >>>> =09 >>>> "The whole network should have roughly the same = idea about the time >>>> since origination of any particular published = state." >>>> =09 >>>> What is the definition of "roughly"? >>>> Is the "should" intentionally in non-caps? >>>> What're the consequences if not? >>>> [Note that trickle almost mechanically makes information = propagate >>>> with non-trivial jitter across a network, so how do you = ensure this?] >>> Clarified the paragraph, since the original text could be = interpreted >>> invertedly. >> Another nit=E2=80=A6 >>=20 >> Every node, including the originating one >>=20 >> what is =E2=80=9Cthe originating one=E2=80=9D, is it =E2=80=9C=E2=80=A6= including the node originating this TLV=E2=80=9D? >>=20 >> Otherwise, yes to your clarification. >=20 > =E2=80=98this TLV=E2=80=99 is also confusing, as you could say the TLV = itself is sent by all nodes and as it is not passed verbatim (timestamp = changes) it cannot be said to be originated by someone. >=20 > Inserted =E2=80=9CEvery node, including the node publishing the node = data,=E2=80=9D for now. >=20 > Cheers, >=20 > -Markus > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Wed Jul 29 11:07:57 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C787D1A906C; Wed, 29 Jul 2015 06:07:43 -0700 (PDT) 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 pWEWyEUzWgLZ; Wed, 29 Jul 2015 06:07:38 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 145D41A906A; Wed, 29 Jul 2015 06:07:38 -0700 (PDT) Received: by obre1 with SMTP id e1so6564751obr.1; Wed, 29 Jul 2015 06:07:37 -0700 (PDT) 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=w4V310BSIwgY4CfBCEojCucVkNcYyJ5ZMrwxH1tSFD4=; b=YgZ+b3HFYuH6lSGRSlTsXPO6hg+5pcR5fHZXueOjOuIheUGrcer9wRQEEO4AlCFzQd lfuvsS8E0F3BFk0dPX13IknCshb0r7dwKW3isXZON+i64WrSMjwW3aG7FtPBz2hufFYw munNrZ0XBcQEawXY5CyDl3Cnh1VPDEPyQwRcY16+LClXo08fFIN5B6GWdoN8X5G23huo yZiYZAE87ouDwdIrYrg3bqBGLfWheoQa6tOc9ZlGdJfi5rYNoqRbrf+YMggijD1PSUPn q7dUSAA+4uNAZJzZbmKPVegGr8bF45P/KUrgOhIX+iUCthpdoMjIS0ZK1mY54OZ6AIn8 zuSA== MIME-Version: 1.0 X-Received: by 10.60.37.166 with SMTP id z6mr39616529oej.63.1438175257537; Wed, 29 Jul 2015 06:07:37 -0700 (PDT) Received: by 10.202.73.2 with HTTP; Wed, 29 Jul 2015 06:07:37 -0700 (PDT) In-Reply-To: <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> Date: Wed, 29 Jul 2015 15:07:37 +0200 Message-ID: From: Dave Taht To: Markus Stenberg Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 11:07:53 -0700 Cc: "" , Steven Barth , "homenet@ietf.org Group" , Thomas Clausen , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 13:07:44 -0000 a bit offtopic, it would be good to have IANA assign some port numbers soon, if they have not already. (?) From nobody Wed Jul 29 11:07:59 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437811A040C; Wed, 29 Jul 2015 06:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 GOJWxYxssvOl; Wed, 29 Jul 2015 06:31:23 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id D1AE61A039F; Wed, 29 Jul 2015 06:31:22 -0700 (PDT) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 552B87C9052312CA; Wed, 29 Jul 2015 16:31:20 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Markus Stenberg In-Reply-To: Date: Wed, 29 Jul 2015 16:31:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0AB20247-237C-487F-8795-0AC12BCC3FBE@iki.fi> References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> To: Pierre Pfister X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Wed, 29 Jul 2015 11:07:53 -0700 Cc: "" , "homenet@ietf.org Group" , Thomas Clausen , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 13:31:25 -0000 On 29.7.2015, at 15.01, Pierre Pfister wrote: > Hello Markus, >=20 > I could not find-out what french-guy-living-in-Paris you are referring = to, so I wanted to make sure I at least have the 3rd position. ;) You probably do. It is clearly a conspiracy. > I think the complexity about the Endpoint definition mostly comes from = the fact that a DNCP Endpoint is half-defined by configuration and = half-defined by the profile. Some parameters such as trickle parameters = are defined as Profile parameters, while they should, IMHO, be defined = "per-endpoint". >=20 > This may require some work but I think the document should specify on = one side what are the global parameters that must be shared by all = participating nodes (the global profile), and on another side what are = the different endpoint parameters that must (or sometimes not, as = Trickle parameters) be shared by all DNCP nodes on a given = =E2=80=98=E2=80=99=E2=80=99=E2=80=99=E2=80=99link=E2=80=99=E2=80=99=E2=80=99= =E2=80=99=E2=80=99 (with lots of =E2=80=98=E2=80=99=E2=80=99), i.e., the = endpoint profile, and allow them to exchange packets and establish a = durable neighboring relationship. >=20 > With that approach it looks to me that a Endpoint could be defined = this way (Probably not best wording, but you will get the idea): >=20 > Endpoint: Set of rules and parameters associated with a unique = Endpoint identifier which: > - Determines how to send DNCP packets toward other DNCP nodes. > - Determines how to establish, keep and teardown neighboring = relationships between two DNCP nodes. > - Classifies a received DNCP packet as received on a given = Endpoint (If a received packet can=E2=80=99t be associated with any = Endpoint, it MUST be ignored). >=20 > Now, adopting such an approach in the document may have significant = impact over its organization, but at least it would help separate what = is globally unique from what is local to neighboring relationships. I think this is overriding (or perhaps compressing) terminology too = much; I believe you are describing an instance of a =E2=80=99endpoint = profile=E2=80=99 (and how one maps to endpoint identifiers), which does = not describe what _is being identified_, i.e. the endpoint itself. At = least to me, your description of =E2=80=98endpoint=E2=80=99 is actually = less clear than Steven=E2=80=99s (in the current dncp-08 text), and I = find both unclear. Given a protocol that uses actually two types of transport (e.g. = someday-updated SHSP draft will have both [some scope] unicast-only and = link-local unicast+multicast endpoints - I have some of the code but not = the updated spec yet), it gets even more murky. While the profile may = specify that this is the transport, how it maps to the particular = endpoint identifiers (and what those identifiers identify) becomes = rather painful. Not to mention if we want to provide per-link type = handling guidance on Trickle k value.. sigh. :p > On a different topic, I think reserving 32 TLV types to DNCP is far = from being enough.=20 > If DNCP is successful, it may be used by many different profiles. = There could be a need to extend DNCP in order to improve all profiles at = once. Limiting DNCP extensions to only 21 new TLVs is unnecessary and = would make that process harder. Reserving more TLVs would be virtually = free and help in the future. > I guess that comment joins Thomas=E2=80=99 comment about version = numbers, with which I agree (that we should add one). It=E2=80=99s not = because DNCP is not a protocol that we should not think about how it = could be improved and extended such that all already-defined profiles = profit from the improvement. Sure it would not be *impossible* to do it = with the current document. But it costs nothing to make it easier. I guess I have to discuss this with Steven; the original idea was to = essentially leave 8 bits in the type unused for e.g. bit vector use at = some point, when I chose the 16-bit T size, but it did not make it to = the DNCP draft.=20 Current texts we have are wrong at any rate, as 256+ are specified as = available _both_ in DNCP and HNCP registry (based on the current .xml = texts we have for not-yet-published dncp-09 and hncp-08), and that is = not optimal situation either if there is a conflict.=20 Cheers, -Markus= From nobody Thu Jul 30 01:47:49 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C08E1B2D33; Thu, 30 Jul 2015 01:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=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 3CBBvKbulRpx; Thu, 30 Jul 2015 01:47:46 -0700 (PDT) Received: from mail.core-networks.de (mx1.core-networks.de [IPv6:2001:1bc0:d::4:8]) (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 AB9D91B2D31; Thu, 30 Jul 2015 01:47:46 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZKjV6-0000ew-IX with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Thu, 30 Jul 2015 10:47:40 +0200 To: Thomas Clausen , Markus Stenberg References: <55857123.90205@openwrt.org> <43C47623-C61D-4397-BA4A-8CBF8878B516@thomasclausen.org> <9630E81F-8AA0-4516-A9AE-56E0EB634599@iki.fi> From: Steven Barth Message-ID: <55B9E4AB.9020803@openwrt.org> Date: Thu, 30 Jul 2015 10:47:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040204060104030501090308" Archived-At: Cc: "" , "homenet@ietf.org Group" , "" Subject: Re: [RTG-DIR] [homenet] RtgDir review: draft-ietf-homenet-dncp-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2015 08:47:48 -0000 This is a multi-part message in MIME format. --------------040204060104030501090308 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit > Recapitulating, I see basically two potential issues where we do not yet have resolution: > > oVersioning > oAddress/Endpoint terminology > We have changed the IANA section like this now: 11-31: Free - policy of 'standards action' should be used 32-511: Reserved for per-DNCP profile use 512-767: Free - policy of 'standards action' should be used 768-1023: Private use 1024-65535: Reserved for future protocol evolution (for example, DNCP version 2) This gives us 6-bits to play with later on (e.g. versioning, flags, etc.) and also a broader pre-defined range for DNCP and per-profile TLVs. We also did another rewrite of address and endpoint to make them less verbose. The following is what at least passed our "internal review" ;) Address an identifier used as source or destination of a DNCP message flow, e.g., a tuple (IPv6 address, UDP port) for an IPv6 UDP transport. Endpoint a locally configured termination point for (potential or established) DNCP message flows. An endpoint is the source and destination for separate unicast message flows to individual nodes and optionally for multicast messages to all thereby reachable nodes (e.g., for node discovery). Endpoints are usually in one of the transport modes specified in . Besides that all instances of "broadcast" should be gone now and have been, replaced by "multicast" or "multicast enabled" or similar since that seemed to be more accurate in most cases anyway. Please let us know what you think ;) Cheers, Steven --------------040204060104030501090308 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Recapitulating, I see basically two potential issues where we do not yet have resolution:

o Versioning 
o Address/Endpoint terminology


We have changed the IANA section like this now:

      <t>11-31: Free - policy of 'standards action' should be used</t>
      <t>32-511: Reserved for per-DNCP profile use</t>
      <t>512-767: Free - policy of 'standards action' should be used</t>
      <t>768-1023: Private use</t>
      <t>1024-65535: Reserved for future protocol evolution (for example, DNCP version 2)</t>

This gives us 6-bits to play with later on (e.g. versioning, flags, etc.) and also a broader pre-defined range for DNCP and per-profile TLVs.


We also did another rewrite of address and endpoint to make them less verbose. The following is
what at least passed our "internal review" ;)

      <c>Address</c>

      <c>an identifier used as source or destination of a DNCP message flow,
      e.g., a tuple (IPv6 address, UDP port) for an IPv6 UDP transport.</c>

      <c /><c />

      <c>Endpoint</c>

      <c>a locally configured termination point for (potential or established)
      DNCP message flows. An endpoint is the source and destination for separate
      unicast message flows to individual nodes and optionally for multicast
      messages to all thereby reachable nodes (e.g., for node discovery).
     
      Endpoints are usually in one of the transport modes specified in <xref
      target="dt" />.


Besides that all instances of "broadcast" should be gone now and have been,
replaced by "multicast" or "multicast enabled" or similar since that seemed to
be more accurate in most cases anyway.

Please let us know what you think ;)



Cheers,

Steven
--------------040204060104030501090308-- From nobody Fri Jul 31 07:17:36 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C7B1A88D2; Fri, 31 Jul 2015 07:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3Mrv0SYCcdl; Fri, 31 Jul 2015 07:17:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8471D1A88B8; Fri, 31 Jul 2015 07:17:32 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id EFEC6955D4D6E; Fri, 31 Jul 2015 14:06:17 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6VE60L0013936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 16:06:20 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 16:06:04 +0200 From: "Bocci, Matthew (Matthew)" To: "rtg-ads@tools.ietf.org" Thread-Topic: =?utf-8?B?UnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi10cmlsbC1kaXJlY3RvcnktYXNz?= =?utf-8?B?aXN0LW1lY2hhbmlzbXPigIstMDMudHh0?= Thread-Index: AQHQy5oJMZHfM9eHXk29iFdDazgy4g== Date: Fri, 31 Jul 2015 14:06:04 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_D1E13F5E7F2AFmatthewboccialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-trill-directory-assist-mechanisms.all@tools.ietf.org" , "trill@ietf.org" Subject: [RTG-DIR] =?utf-8?q?RtgDir_review=3A_draft-ietf-trill-directory-a?= =?utf-8?q?ssist-mechanisms=E2=80=8B-03=2Etxt?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 14:17:35 -0000 --_000_D1E13F5E7F2AFmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuDQpUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVr cyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQpkcmFmdHMgYXMgdGhl eSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQNCnNvbWV0 aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8g cHJvdmlkZQ0KYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBSb3V0aW5nDQpEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZQ0K4oCLaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3Vn aCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5n IEFEcywgaXQNCndvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgSUVURg0KTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2Vp dmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gNCmRpc2N1c3Npb24gb3IgYnkg dXBkYXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi10cmlsbC1kaXJlY3Rv cnktYXNzaXN0LW1lY2hhbmlzbXPigIstMDMudHh0DQpSZXZpZXdlcjogTWF0dGhldyBCb2NjaQ0K UmV2aWV3IERhdGU6IEp1bHkgMjAxNQ0KSUVURiBMQyBFbmQgRGF0ZTogVW5rbm93bg0KSW50ZW5k ZWQgU3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZA0KDQpTdW1tYXJ5Og0KSSBoYXZlIHNvbWUgbWlu b3IgY29uY2VybnMgYWJvdXQgdGhpcw0KZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSBy ZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpUaGUgZHJhZnQgaXMg bW9zdGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IEkgaGF2ZSBzb21lIGNvbW1lbnRzIHJl bGF0ZWQgdG8NCndoaWNoIHByb2NlZHVyZXMgYXJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQsIGFu ZCB3aGljaCBhcmUgb3B0aW9uYWwgKHNlZSBtaW5vcg0KaXNzdWVzIGJlbG93KS4gSSd2ZSBmbGFn Z2VkIHRoaXMgYmVjYXVzZSBpbiBteSBleHBlcmllbmNlDQppdCBpcyB2ZXJ5IGltcG9ydGFudCBm b3IgYW4gUkZDIHRvIGJlIGNyeXN0YWwgY2xlYXIgYWJvdXQgd2hhdCBpcyBtYW5kYXRvcnkgZm9y DQpzdWNjZXNzZnVsIGludGVyb3BlcmFiaWxpdHkuDQoNCg0KDQpNYWpvciBJc3N1ZXM6DQoNCk5v IG1ham9yIGlzc3Vlcy4NCg0KTWlub3IgSXNzdWVzOg0KDQpJbiBnZW5lcmFsLCBpdCBpcyB2ZXJ5 IHVuY2xlYXIgaWYgaXQgaXMgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBib3RoIHB1c2ggYW5kIHB1 bGwsDQpvciBpZiBpdCBpcyBhZGVxdWF0ZSB0byBqdXN0IGltcGxlbWVudCBvbmUgb3IgdGhlIG90 aGVyLiBJIGFwcHJlY2lhdGUgdGhhdCBhIGh5YnJpZA0KbW9kZSBpcyBwb3NzaWJsZSwgaW4gd2hp Y2ggY2FzZSBhbiBpbXBsZW1lbnRhdGlvbiB3b3VsZCBuZWVkIHRvIHN1cHBvcnQgYm90aCwgYnV0 DQp0aGlzIGlzIG9ubHkgZGVzY3JpYmVkIGF0IHRoZSBlbmQgaW4gc2VjdGlvbiA0LCBhbG1vc3Qg YXMgYW4gYWZ0ZXJ0aG91Z2h0LiBJdCB3b3VsZA0KYmUgbXVjaCBiZXR0ZXIgaWYgdGhlIGRyYWZ0 IGNvdWxkIGJlIGNsZWFyIHVwLWZyb250IHdoaWNoIGlzIHRoZSBtYW5kYXRvcnkgKGRlZmF1bHQp DQptb2RlLCBvciBpZiBib3RoIG11c3QgYmUgaW1wbGVtZW50ZWQgaWYgdGhlIGV4cGVjdGF0aW9u IGlzIHRoYXQgdGhlIGRlZmF1bHQgb3BlcmF0aW5nDQptb2RlbCBpcyBoeWJyaWQuDQoNClNlY3Rp b246ICIxLiBJbnRyb2R1Y3Rpb24iDQoxc3QgUGFyYWdyYXBoOiBMYXN0IHNlbnRlbmNlDQoiVGhl c2UgbWVjaGFuaXNtcyBhcmUgb3B0aW9uYWwgdG8gaW1wbGVtZW50LiINClRoaXMgc3RhdGVtZW50 IHNlZW1zIHJlZHVuZGFudCwgc2luY2UgdGVjaG5pY2FsbHkgdGhlIHdob2xlIFJGQyBpcyBvcHRp b25hbA0KdW5sZXNzIGFub3RoZXIgUkZDIG1ha2VzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBp dCA6KSBJIHRoaW5rIHlvdSBzaG91bGQgZWl0aGVyDQpyZW1vdmUgdGhpcyBzdGF0ZW1lbnQsIG9y IHVzZSBpdCB0byBjbGFyaWZ5IHdoaWNoIG1vZGVzIGFyZSBvcHRpb25hbCBhbmQgd2hpY2ggYXJl DQptYW5kYXRvcnkuDQoNClBnMTQ6DQoiSWYgaW5mb3JtYXRpb24gcHJldmlvdXNseQ0KICAgcHVs bGVkIGlzIGFib3V0IHRvIGV4cGlyZSwgYSBUUklMTCBzd2l0Y2ggTUFZIHRyeSB0byByZWZyZXNo IGl0IGJ5DQogICBpc3N1aW5nIGEgbmV3IHB1bGwgcmVxdWVzdCBidXQsIHRvIGF2b2lkIHVubmVj ZXNzYXJ5IHJlcXVlc3RzLCBTSE9VTEQNCiAgIE5PVCBkbyBzbyBpZiBpdCBoYXMgbm90IGJlZW4g cmVjZW50bHkgdXNlZC4iDQoNCkNhbiB5b3UgZ2l2ZSBtb3JlIGluZm9ybWF0aW9uIG9uIHdoYXQg eW91IG1lYW4gYnkgInJlY2VudGx5Ij8gU29tZSBub24tbm9ybWF0aXZlDQpndWlkYW5jZSBtaWdo dCBiZSBoZWxwZnVsIHRvIHByZXZlbnQgd2lsZGx5IGRpZmZlcmluZyBvciB1bnByZWRpY3RhYmxl IGJlaGF2aW91cnMNCmluIGEgbXVsdGktdmVuZG9yIGRlcGxveW1lbnQuDQoNCk5pdHM6DQoNCi0g VGhlcmUgYXJlIGEgZmV3IHVuY29tbW9uIGFjcm9ueW1zLiBQbGVhc2UgZXhwYW5kIGFsbCBhY3Jv bnltcyBvbiBmaXJzdCB1c2UuDQotIFBnNCBzL01hY0RBL01BQyBEQQ0KLSBQZzggcy9hbmdlbCBi cmFja2V0L2FuZ2xlIGJyYWNrZXQNCg0KDQoNCg== --_000_D1E13F5E7F2AFmatthewboccialcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <7C41968EC3F219468B770411A7953E19@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkhlbGxvLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBo YXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuPC9kaXY+DQo8ZGl2PlRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRv IHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQ8L2Rpdj4NCjxkaXY+ZHJhZnRz IGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5k PC9kaXY+DQo8ZGl2PnNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9m IHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZTwvZGl2Pg0KPGRpdj5hc3Npc3RhbmNlIHRvIHRoZSBS b3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmc8L2Rpdj4N CjxkaXY+RGlyZWN0b3JhdGUsIHBsZWFzZSBzZWU8L2Rpdj4NCjxkaXY+4oCLaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3Ig dGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0PC9kaXY+DQo8ZGl2PndvdWxkIGJlIGhlbHBm dWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURjwv ZGl2Pg0KPGRpdj5MYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaDwvZGl2Pg0KPGRpdj5kaXNjdXNzaW9uIG9yIGJ5IHVw ZGF0aW5nIHRoZSBkcmFmdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvY3VtZW50 OiBkcmFmdC1pZXRmLXRyaWxsLWRpcmVjdG9yeS1hc3Npc3QtbWVjaGFuaXNtc+KAiy0wMy50eHQm bmJzcDs8L2Rpdj4NCjxkaXY+UmV2aWV3ZXI6IE1hdHRoZXcgQm9jY2kmbmJzcDs8L2Rpdj4NCjxk aXY+UmV2aWV3IERhdGU6IEp1bHkgMjAxNSZuYnNwOzwvZGl2Pg0KPGRpdj5JRVRGIExDIEVuZCBE YXRlOiBVbmtub3duJm5ic3A7PC9kaXY+DQo8ZGl2PkludGVuZGVkIFN0YXR1czogUHJvcG9zZWQg U3RhbmRhcmQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlN1bW1hcnk6Jm5ic3A7PC9k aXY+DQo8ZGl2PkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXM8L2Rpdj4NCjxk aXY+ZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGlj YXRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Db21tZW50czo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBkcmFmdCBpcyBtb3N0bHkgcmVhZHkgZm9y IHB1YmxpY2F0aW9uLCBidXQgSSBoYXZlIHNvbWUgY29tbWVudHMgcmVsYXRlZCB0bzwvZGl2Pg0K PGRpdj53aGljaCBwcm9jZWR1cmVzIGFyZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LCBhbmQgd2hp Y2ggYXJlIG9wdGlvbmFsIChzZWUgbWlub3I8L2Rpdj4NCjxkaXY+aXNzdWVzIGJlbG93KS4gSSd2 ZSBmbGFnZ2VkIHRoaXMgYmVjYXVzZSBpbiBteSBleHBlcmllbmNlJm5ic3A7PC9kaXY+DQo8ZGl2 Pml0IGlzIHZlcnkgaW1wb3J0YW50IGZvciBhbiBSRkMgdG8gYmUgY3J5c3RhbCBjbGVhciBhYm91 dCB3aGF0IGlzIG1hbmRhdG9yeSBmb3ImbmJzcDs8L2Rpdj4NCjxkaXY+c3VjY2Vzc2Z1bCBpbnRl cm9wZXJhYmlsaXR5LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5NYWpvciBJc3N1ZXM6PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5ObyBtYWpvciBpc3N1ZXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5NaW5vciBJc3N1ZXM6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ SW4gZ2VuZXJhbCwgaXQgaXMgdmVyeSB1bmNsZWFyIGlmIGl0IGlzIG1hbmRhdG9yeSB0byBpbXBs ZW1lbnQgYm90aCBwdXNoIGFuZCBwdWxsLCZuYnNwOzwvZGl2Pg0KPGRpdj5vciBpZiBpdCBpcyBh ZGVxdWF0ZSB0byBqdXN0IGltcGxlbWVudCBvbmUgb3IgdGhlIG90aGVyLiBJIGFwcHJlY2lhdGUg dGhhdCBhIGh5YnJpZDwvZGl2Pg0KPGRpdj5tb2RlIGlzIHBvc3NpYmxlLCBpbiB3aGljaCBjYXNl IGFuIGltcGxlbWVudGF0aW9uIHdvdWxkIG5lZWQgdG8gc3VwcG9ydCBib3RoLCBidXQmbmJzcDs8 L2Rpdj4NCjxkaXY+dGhpcyBpcyBvbmx5IGRlc2NyaWJlZCBhdCB0aGUgZW5kIGluIHNlY3Rpb24g NCwgYWxtb3N0IGFzIGFuIGFmdGVydGhvdWdodC4gSXQgd291bGQmbmJzcDs8L2Rpdj4NCjxkaXY+ YmUgbXVjaCBiZXR0ZXIgaWYgdGhlIGRyYWZ0IGNvdWxkIGJlIGNsZWFyIHVwLWZyb250IHdoaWNo IGlzIHRoZSBtYW5kYXRvcnkgKGRlZmF1bHQpPC9kaXY+DQo8ZGl2Pm1vZGUsIG9yIGlmIGJvdGgg bXVzdCBiZSBpbXBsZW1lbnRlZCBpZiB0aGUgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGUgZGVmYXVs dCBvcGVyYXRpbmc8L2Rpdj4NCjxkaXY+bW9kZWwgaXMgaHlicmlkLjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWN0aW9uOiAmcXVvdDsxLiBJbnRyb2R1Y3Rpb24mcXVv dDs8L2Rpdj4NCjxkaXY+MXN0IFBhcmFncmFwaDogTGFzdCBzZW50ZW5jZTwvZGl2Pg0KPGRpdj4m cXVvdDtUaGVzZSBtZWNoYW5pc21zIGFyZSBvcHRpb25hbCB0byBpbXBsZW1lbnQuJnF1b3Q7Jm5i c3A7PC9kaXY+DQo8ZGl2PlRoaXMgc3RhdGVtZW50IHNlZW1zIHJlZHVuZGFudCwgc2luY2UgdGVj aG5pY2FsbHkgdGhlIHdob2xlIFJGQyBpcyBvcHRpb25hbCZuYnNwOzwvZGl2Pg0KPGRpdj51bmxl c3MgYW5vdGhlciBSRkMgbWFrZXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGl0IDopIEkgdGhp bmsgeW91IHNob3VsZCBlaXRoZXI8L2Rpdj4NCjxkaXY+cmVtb3ZlIHRoaXMgc3RhdGVtZW50LCBv ciB1c2UgaXQgdG8gY2xhcmlmeSB3aGljaCBtb2RlcyBhcmUgb3B0aW9uYWwgYW5kIHdoaWNoIGFy ZSZuYnNwOzwvZGl2Pg0KPGRpdj5tYW5kYXRvcnkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5QZzE0OjwvZGl2Pg0KPGRpdj4mcXVvdDtJZiBpbmZvcm1hdGlvbiBwcmV2aW91c2x5PC9k aXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtwdWxsZWQgaXMgYWJvdXQgdG8gZXhwaXJlLCBhIFRSSUxM IHN3aXRjaCBNQVkgdHJ5IHRvIHJlZnJlc2ggaXQgYnk8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNw O2lzc3VpbmcgYSBuZXcgcHVsbCByZXF1ZXN0IGJ1dCwgdG8gYXZvaWQgdW5uZWNlc3NhcnkgcmVx dWVzdHMsIFNIT1VMRDwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7Tk9UIGRvIHNvIGlmIGl0IGhh cyBub3QgYmVlbiByZWNlbnRseSB1c2VkLiZxdW90OzwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7 PC9kaXY+DQo8ZGl2PkNhbiB5b3UgZ2l2ZSBtb3JlIGluZm9ybWF0aW9uIG9uIHdoYXQgeW91IG1l YW4gYnkgJnF1b3Q7cmVjZW50bHkmcXVvdDs/IFNvbWUgbm9uLW5vcm1hdGl2ZSZuYnNwOzwvZGl2 Pg0KPGRpdj5ndWlkYW5jZSBtaWdodCBiZSBoZWxwZnVsIHRvIHByZXZlbnQgd2lsZGx5IGRpZmZl cmluZyBvciB1bnByZWRpY3RhYmxlIGJlaGF2aW91cnMmbmJzcDs8L2Rpdj4NCjxkaXY+aW4gYSBt dWx0aS12ZW5kb3IgZGVwbG95bWVudC4gJm5ic3A7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyAm bmJzcDs8L2Rpdj4NCjxkaXY+Tml0czo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0g VGhlcmUgYXJlIGEgZmV3IHVuY29tbW9uIGFjcm9ueW1zLiBQbGVhc2UgZXhwYW5kIGFsbCBhY3Jv bnltcyBvbiBmaXJzdCB1c2UuPC9kaXY+DQo8ZGl2Pi0gUGc0IHMvTWFjREEvTUFDIERBPC9kaXY+ DQo8ZGl2Pi0gUGc4IHMvYW5nZWwgYnJhY2tldC9hbmdsZSBicmFja2V0PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D1E13F5E7F2AFmatthewboccialcatellucentcom_--