From nobody Tue Aug 2 01:56:52 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD0112D179; Tue, 2 Aug 2016 01:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qmSnOYzl44GA; Tue, 2 Aug 2016 01:56:48 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 61CCF12D181; Tue, 2 Aug 2016 01:56:48 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id f6so266069018ith.1; Tue, 02 Aug 2016 01:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pgoh1OutfycH+Go9Vs6PvXaTNTPcCKRUw+PekSgfHqk=; b=skx+66Nsx6aC94XKHw1Rc8t6k6GfK1QX6vaBL+VNCRfYNDxFxfL3nbgihg7fMkyvah rzlS1lbSXvntt6kvjTGLPsDpxrV9coZiRKBu+lWlJRqEzKIa7gkmiVlOYh+fvYL+EVlB DQXbyw3Cvhswb4BhQDDEtbkf8qDCD9fRkqwdhE+XZX7/u8ksYkW4cboVORgv0jxMh8DA vLkpn7hd8O6isOz2dGCf8TMG7lwG00j3bIwYtb9qFYqVMslePRuubPDWtaKiTPlrpGEX J0c4nt4dlgG4rhYnHrK51INscWAlLd0V1exkDCiWLr8anro2P38EQPSHKhYpyHptkY1k 2BXA== 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; bh=pgoh1OutfycH+Go9Vs6PvXaTNTPcCKRUw+PekSgfHqk=; b=X2IVWDtL1XQOBmnPm/LcpEB8udusGQTCW3qoJbRBq/3ATtorM9EjfyU3rBTlVPeZUD tqF49FdwZmrc5z6SzEn1xxrNoVjyyJegYIM3Dk5mLPUBcQGkoQ6wTNthFhlyAHljs/TY T4wtA+CYx+zb30AqfKHaoUBSea4S9Z9GuxgDmPM9nIYq14BPDbYtTTjVHrSDIKBgcf9R Y2/q+1cIY/z59QMv3C+Zth/bG3CijkYUOk/oqFG1+iEFSJmq6VqEx92jD4mVoyJYKdID MMkIM6kL2diMjoFB5sKyBZvN+hmGgxKO8m52YeZg6Lcd4ViT8ub6P63WpC+5RXcG8sRW 0p0g== X-Gm-Message-State: AEkoouvwPWGz6PqG+faVGs+l77qLKZvIjcjaEr3mbeAJEHwG633FJFLsD3wPvR3GmyKaEqzExZ5nhq2YM0O1mg== X-Received: by 10.36.219.65 with SMTP id c62mr17107929itg.44.1470128207503; Tue, 02 Aug 2016 01:56:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.32.11 with HTTP; Tue, 2 Aug 2016 01:56:46 -0700 (PDT) In-Reply-To: References: From: GangChen Date: Tue, 2 Aug 2016 16:56:46 +0800 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-mif-happy-eyeballs-extension.all" , Hui Deng , int-ads@ietf.org, "" Subject: Re: [Int-dir] INTDIR review of draft-ietf-mif-happy-eyeballs-extension-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 08:56:51 -0000 Dear Ralph, We have posted a new update on mif happy eyeballs according to your comments. The edition has also been polished after reviewer's detailed reviews. Your further guidance is appreciated. Many thanks Gang A new version of I-D, draft-ietf-mif-happy-eyeballs-extension-10.txt has been successfully submitted by Gang Chen and posted to the IETF repository. Name: draft-ietf-mif-happy-eyeballs-extension Revision: 10 Title: Happy Eyeballs Extension for Multiple Interfaces Document date: 2016-08-02 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-mif-happy-eyeballs-extension-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/ Htmlized: https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mif-happy-eyeballs-extension-10 Abstract: This memo proposes extensions to the Happy Eyeball's algorithm requirements defined in RFC6555 for use with the multiple provisioning domain architecture. The Happy Eyeballs in MIF would make the selection process smoother by using connectivity tests over pre-filtered interfaces according to defined policy. This would choose the best interface with an automatic fallback mechanism. 2016-06-16 15:59 GMT+08:00, GangChen : > Dear Ralph, > > I apologize for this late reply. > Thank you for the comments. > Those are informative for us. > Please see my replies inline. > > 2016-05-04 5:15 GMT+08:00, Ralph Droms : >> I am an assigned INT directorate reviewer for >> draft-ietf-mif-happy-eyeballs-extension-09. These comments were >> written primarily for the benefit of the Internet Area >> Directors. Document editors and shepherd(s) should treat these >> comments just like they would treat comments from any other IETF >> contributors and resolve them along with any other Last Call comments >> that have been received. For more details on the INT Directorate, see >> http://www.ietf.org/iesg/directorate.html. >> >> In my opinion, the documents lacks - and needs - a clear statement of >> purpose. What result is the document trying to achieve? Who is the >> audience? How would the audience put the contents of the document to >> use? > > the draft mainly intends to address the issue where a node has > selected an interface > and obtained a valid IP address from the network, but Internet > connectivity > is not available. Such scenario is described in the "WiFi is broken" > of use cases section. > The purpose of HE-MIF is to avoid such issue. The audience is supposed > to be connection manager implementors or web browser developer, who > could integrate the HE-MIF framework into their implementations. > > This comment inspire me to re-construct the draft to clear the purpose > statement. > It's may probably be better to combine section 1 and 3, since the > section 3 is major use cases description that may help to state the > issue HE-MIF targeted. > > > >> The document must be edited carefully for english language usage >> before publication. I would consider this issue to be worthy of a >> "Discuss" on the document. I found that the document is unclear in >> several areas, which prevented me from understanding the meaning of >> that text. For example, in section 2, does "within a single home." >> mean a device in one home or a device with just one interface? In >> section 5.1, does: >> >> users may dedicatedly prefer a 3GPP >> network interface to seek high-reliability or security benefits even >> to manually turn off WiFi interface. >> >> mean: >> >> users may turn off a device's WiFi interface to guarantee use of a >> 3GPP network interface to assure higher reliability or security. > > Your interpretation is correct and great example to me. > I have realized there are several similiar language issues. > Those days, I'm inviting english knowledged persons to help me fix the > bugs. > we will publish an new version to promote the readability. > >> Some sections seem to make observations about conditions that might >> have an influence on an implementation of MIF-HE, but don't have any >> actionable guidance for implementors. This lack of clarity is related >> to the lack of a clear statement of purpose for the document. For >> example, in section 5.1: >> >> The decision on mergence of >> policies may be made by implementations, by node administrators, even >> by other standards investigating customer behavior. However, it's >> worth to note that a demand from users should be normally considered >> higher priority than from other actors. >> >> I don't see anything in this text that I would consider actionable as >> an implementor. > > The draft is virtually not a algorithm, but requirements for the > algorithm or implementations. > The section 5.1 reflects the wg discussion outcome. The actionable for > implementors is to open an interface to accept user's input expressing > their preference. And, this preference should be superior to other > inputs. > >> It is unclear where the document explicitly choosing one interface as >> "faster". Section 5.2 includes text about "the outcome of each >> connection attempt"; does this text refer to recording the connection >> time and using that time as the basis for future interface selection? > > It's correct. A timer is used to flush each cache entry and triger > next connection attempt. > > >> How does HE-MIF interact with HE for selecting between IPv4 and IPv6? > > HE-MIF and HE are two parallel threads. They don't have compulsive > interactions. > In other words, a device use HE-MIF to choose the faster interface, > afterwards it may > use HE to select suitable IP family or it just uses default address > selection to determine. > > > I hope above could clarify. > > Many thanks > > Best Regards > > Gang > > >> > From nobody Tue Aug 2 02:00:45 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0834B12D18E for ; Tue, 2 Aug 2016 02:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZEnpQl2Yy5qA for ; Tue, 2 Aug 2016 02:00:41 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 1287312D13A for ; Tue, 2 Aug 2016 02:00:21 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id j124so197023753ith.1 for ; Tue, 02 Aug 2016 02:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bbBBxECYq5ERtPljJ0Nk26CNsyf/GfEZath3+7Ivc3w=; b=xM+gMnYzajHRzxOvvU3od57jxOv+IRkbzW4v6/fI7nF/0prDtuQpFZ2dm/jC5/AFSJ q4zsEBMk2oZG+VyxO3TNcOCuw+jbtYEe1hEzW18/Eebb/BtGMklzwgIhUZIknITaNIt/ uEUckloWTYGvatCBYVqdGb0tVLSTo+HY5nak23ORms6krUDlVFUMePLy6ALbBzdr+Rpx q3FlJpjEHn9mv+Jcp1R40H3+9+46ryGRHwFC26o+O5KUmjiKhm3ELSCTDDokUVHPbtPh Hug3OtlPKu3mZ146Ksc35bvAL6S+FXHeTfSkZTgXPBRmysQDrrpn4P+EGuz4eyHnZ12o ar3Q== 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; bh=bbBBxECYq5ERtPljJ0Nk26CNsyf/GfEZath3+7Ivc3w=; b=ClJo/vRdcaz26O+R39++31z9JAIrzKcHT5xTaQo0t6K13jQsUdoVlzk8fyoLkUec2w 9W+dtxbpKSI2GdWb+Oeap7B5U2mzoYHWBAIWcc22U+rNBRG7rpGKVW7w0aUgo4ObGzmR Aba22qeiq6b4SJtfbMENS9B62Gc/J6AmGVq34Lsz1Nf/T1kaC6F3+T0/WuyxbxB67i9E 0Rr8CX5zdz3IgFmK3oG/NIMbah7zpe5bQdUeL4a1eb3DkVJlJ720yANWSn/93CB/Sy8V qgyidxnYOv+9DfUPN9QIypoA0UloMASpOH13EQHBm4mHcEWXZblRQXjcxzI1clN+HVaY zeFw== X-Gm-Message-State: AEkoouuBuBwhGajh+IEqPaqyLyNbuxf48R7lUKZ5jRiYEqlSkPNnA6VA9HsnRKApwHNOeZiniTRB2ShPbKBbWA== X-Received: by 10.36.219.65 with SMTP id c62mr17118693itg.44.1470128420411; Tue, 02 Aug 2016 02:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.32.11 with HTTP; Tue, 2 Aug 2016 02:00:19 -0700 (PDT) In-Reply-To: <5734B9F9.1070309@gmail.com> References: <5734B9F9.1070309@gmail.com> From: GangChen Date: Tue, 2 Aug 2016 17:00:19 +0800 Message-ID: To: jouni.nospam@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-mif-happy-eyeballs-extension.all@tools.ietf.org, "" Subject: Re: [Int-dir] INT-DIR review of draft-ietf-mif-happy-eyeballs-extension-09 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 09:00:43 -0000 Dear Jouni, We have posted a new update on mif happy eyeballs according to your comments. The edition has also been polished after reviewer's detailed reviews. Your further guidance is appreciated. Many thanks Gang A new version of I-D, draft-ietf-mif-happy-eyeballs-extension-10.txt has been successfully submitted by Gang Chen and posted to the IETF repository. Name: draft-ietf-mif-happy-eyeballs-extension Revision: 10 Title: Happy Eyeballs Extension for Multiple Interfaces Document date: 2016-08-02 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-mif-happy-eyeballs-extension-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/ Htmlized: https://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mif-happy-eyeballs-extension-10 Abstract: This memo proposes extensions to the Happy Eyeball's algorithm requirements defined in RFC6555 for use with the multiple provisioning domain architecture. The Happy Eyeballs in MIF would make the selection process smoother by using connectivity tests over pre-filtered interfaces according to defined policy. This would choose the best interface with an automatic fallback mechanism. 2016-05-13 1:14 GMT+08:00, Jouni Korhonen : > I am an assigned INT directorate reviewer for > draft-ietf-mif-happy-eyeballs-extension-09. These comments were > written primarily for the benefit of the Internet Area > Directors. Document editors and shepherd(s) should treat these > comments just like they would treat comments from any other IETF > contributors and resolve them along with any other Last Call comments > that have been received. For more details on the INT Directorate, see > http://www.ietf.org/iesg/directorate.html. > > I recon the review is way late but I am doing it still. > > * The document is not ready for publication. The first issues that comes > out is the language and grammar, which needs a major facelift. In many > places the reader is left wondering what exactly was meant on the first > few reads. The second issue really is the technical recommendations how > to implement HE-MIF enabled device. I cannot say Section 5 describes the > behaviour well enough for me to be able to implement anything (I do > realize this is an Informational document but still..). Furthermore, > Section 6 implementation framework description is somewhat thin. > > * Some acronyms such as MIF and PVD are never expanded while some are > multiple times (like HE). > > * The document uses "fast interface" and "most fast path".. Does it mean > fast by link bandwidth or actually the smallest connection RTT? All > references to "fast" should be revisited and clarified what is actually > meant. > > * HE-MIF is described as adopting happy eyeballs to MPVD. After reading > the document this connection is somewhat vague. The document should be a > bit more concrete on how to apply MPVD specifically to happy eyeballs. > > * Use case WiFi is broken: > 121 might not be the case for several reasons, such as authentication > 122 requirements, instability at layer 2, or even, perhaps, the WiFi > > It is unclear to me how "authentication requirements" applies here. > Does it actually try to mean captive portal type scenario? > Also, it is unclear to me how "instability at layer 2" applies here. > Does it mean the connection is so bad that no packets go through? In > that case it is likely the device would not be able to acquire or > keep its IP address either on that interface. > > * WiFi use case makes a sudden assumption the device is a mobile phone. > While this is probably the case the use case description starts off > with "MIF node".. recommend using something like "MIF enabled mobile > device". > > * I do not understand what the "time slot" means here: > 127 to wait an appropriate time slot but not forever. After the > timer is > > * No Reference to ANDSF.. most readers are linkely unfamiliar with it. > > * Sections 5 should really be more concrete with its guidance to > implementers what to do. > > - Jouni > > From nobody Tue Aug 9 07:04:24 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C6F12D7F7 for ; Tue, 9 Aug 2016 07:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 T1StFXK_8SUW for ; Tue, 9 Aug 2016 07:04:20 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 968DD12D810 for ; Tue, 9 Aug 2016 07:04:20 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id iw10so5791351pac.2 for ; Tue, 09 Aug 2016 07:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=o6hX7FsoSEayIrHJ5DWJbTmdIKJfpTQBu2ioyqE3oUM=; b=S8aFigMaQw8UfVX40UKdgMOb/UIRWT5oGbPMFcCvbaGzyzEKlZ70tgRNXrZA532F6Y rconK1RcHJaJ2d8KMw6MKLSYx3bj98HKHz3AphX3e5Lqfa+JXHc+YH0RdEzY5l3crx+d 1P1Rg1W6wdG7DUujZj/G6QSpdd18bw/YWMq3g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=o6hX7FsoSEayIrHJ5DWJbTmdIKJfpTQBu2ioyqE3oUM=; b=cgc+pymNd9RUsg0gQbR1wyq6SA0GHa0uVEI3ah5Ak45N4fVKr419bR5BbNKT1ddfgk NHP1gie7ZnRUfffAOyZGbGyyIJtHN7huiKdqVqM9QFsSCnKiJWt4k0Jrqbfff4VSmiHy bl5hBB6IPJzo7PqAYWaaj7wJ66mhiZXo/ZgPkXivrvDzSwnpkCSDE5fNnZBNJw/s8sFc m8ho8/J+QqqCuSnLKdGhYJXsOX/Xo1op3bCrCuRY/m0IUVf2yeno94yLsVHspnXRsDZK ImaKhJr3bYf4BdIjieyoyBVDvf0K80nOkQwBXFiLotJeNFraAkwbdj9L9XUrJdXJO5CI u9zA== X-Gm-Message-State: AEkoouuslE8lYFuDHm+K14zPGGLmKW7ezaR3lE5Rkn7nX5UUXxB04ITTgITRFpm5LHm5Ew== X-Received: by 10.66.221.229 with SMTP id qh5mr88216685pac.66.1470751459994; Tue, 09 Aug 2016 07:04:19 -0700 (PDT) Received: from node-131fed22zaif2019l8.ipv6.teksavvy.com (node-131fed22zaif2019l8.ipv6.teksavvy.com. [2607:f2c0:101:202:38c5:2d4c:fd1e:9ecc]) by smtp.gmail.com with ESMTPSA id l81sm56390902pfi.50.2016.08.09.07.04.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Aug 2016 07:04:19 -0700 (PDT) From: Joe Abley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 9 Aug 2016 10:04:12 -0400 Message-Id: To: int-ads@ietf.org, int-dir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: craig.schelp@pmcs.com, shalex@tx.technion.ac.il, Richard.Tse@pmcs.com Subject: [Int-dir] INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 14:04:23 -0000 I am an assigned INT directorate reviewer for this draft. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherds should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details of the INT directorate, see . Summary This document is clearly-written and informative. I identified a couple of areas where some additional discussion might be useful, but no glaring ommission or other problem that would be a reason not to publish as-is, if the authors prefer. Suggestions for Section 5 The document says, reasonably, that "the set of IP addresses for each clock should be chosen in a way that enables the establishment of paths that are the most different." This is sensible advice, and I understand the generality of the recommendation since it is difficult to provide detailed advice for the many component networks of the Internet, many of which are presumably operated differently from each other in this regard. However, I think it might be worth giving an easy example derived from global routing operations with BGP. For example, choosing multiple addresses for a clock that are covered by the same prefix exported from the local autonomous system (AS) is likely to yield fewer candidate return paths than choosing addresses covered by different exported prefixes, since the former can only provide a single exit for all addresses from a remote AS while the latter potentially can provide more. Other examples are no doubt possible. I think it would be useful to include at least one example, however, since the advice might otherwise be overlooked. Suggestions for Section 5.3 1. Header parameters used for flow hashing in traceroute vs. clock protocol It was observed earlier in the document that in some networks flow buckets are associated with a tuple of packet headers that includes transport protocol identifiers (e.g. UDP) and transport layer addresses (e.g. UDP port numbers). A traceroute implementation that wants to identify the path used by the timing protocol would need to take care to use the same values in the headers of its probe packets as is used by the network timing protocol, to the extent that routers in the intermediate networks between master and slave use those values to identify individual packets that will be forwarded along congruent paths. However, some or even most implementations (e.g. the original Van Jacobsen traceroute that continues to ship with BSD variants) vary some of these parameters in order to support concurrent operation by multiple users of the same system, or to allow multiple probe packets to be in flight simultaneously to speed up the process of mapping a path. VJ traceroute varies the destination UDP port number, for example. I think it is worth noting in this section that if the particular algorithm employed for traceroute is not identical to the clock protocol being used, as seen by the network, it is entirely possible that the paths taken by traceroute probe packets and packets associated with the clock protocol will be different. The extent to which traceroute will be useful in the identification of identical paths for the clock protocol will vary in practice, and in applications where the possibility of path diversity is more important than the cost of identical paths is high it might be better to forego identical path identification and instead acknowledge that some work will likely be wasted. 2. Temporal stability of paths Some networks might re-route individual flows over time. The path (A, B) and the path (C, D) might be different at time T0, but the same at T1, then different again at T2, as individual routers in the path experience topology changes (e.g. interfaces come up and down, or a routing protocol reacts to an LSA received from a neighbour). I think it is worth mentioning that if paths are to be compared to assess whether they are identical, that assessment needs to be repeated regularly in order to be useful over the lifetime of an association between a clock master and slave, which is presumed to be long compared to the expected stability of an arbitrary path over the Internet. From nobody Thu Aug 11 00:03:28 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2613512D0C4; Thu, 11 Aug 2016 00:03:27 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0lJpX-FrK8VU; Thu, 11 Aug 2016 00:03:25 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 EAF2B12B04F; Thu, 11 Aug 2016 00:03:24 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u7B71SHl018837; Thu, 11 Aug 2016 00:03:18 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 24nfdkngfm-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Aug 2016 00:03:17 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Aug 2016 10:03:14 +0300 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Thu, 11 Aug 2016 10:03:14 +0300 From: Tal Mizrahi To: Joe Abley , "suresh.krishnan@ericsson.com" Thread-Topic: INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 Thread-Index: AQHR8kbvi87OvekaBESNH/Asj6GPxKBBwSlQgAGU0LCAAAB0wA== Date: Thu, 11 Aug 2016 07:03:13 +0000 Message-ID: <9deea586dda54874922fc3fcf481d124@IL-EXCH01.marvell.com> References: <8B30F88D2EFEB944A62BB42C50B81C0A16144C19@avsrvexchmbx1.microsemi.net> <1c7e0b8243c44f018a135b5fbbf7694a@IL-EXCH01.marvell.com> In-Reply-To: <1c7e0b8243c44f018a135b5fbbf7694a@IL-EXCH01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-11_05:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608110091 Archived-At: Cc: "Alex Shpiner \(alex.shpiner@gmail.com\)" , "Richard Tse \(richard.tse@microsemi.com\)" , "Karen ODonoghue \(odonoghue@isoc.org\)" , "int-ads@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 07:03:27 -0000 Hi Joe, Many thanks for the thorough review and detailed comments. Please see my responses below. Please let us know if you have further comments. Regards, Tal Mizrahi. >-----Original Message----- >From: Joe Abley [mailto:jabley@hopcount.ca] >Sent: Tuesday, August 9, 2016 7:04 AM >To: int-ads@ietf.org; int-dir@ietf.org >Cc: shalex@tx.technion.ac.il; Richard Tse; craig.schelp@pmcs.com >Subject: INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 > >EXTERNAL EMAIL > > >I am an assigned INT directorate reviewer for this draft. These comments >were written primarily for the benefit of the Internet Area Directors. >Document editors and shepherds should treat these comments just like they >would treat comments from any other IETF contributors and resolve them >along with any other Last Call comments that have been received. For more >details of the INT directorate, see >. > >Summary > >This document is clearly-written and informative. I identified a couple of= areas >where some additional discussion might be useful, but no glaring ommission >or other problem that would be a reason not to publish as-is, if the autho= rs >prefer. > >Suggestions for Section 5 > >The document says, reasonably, that "the set of IP addresses for each cloc= k >should be chosen in a way that enables the establishment of paths that are >the most different." > >This is sensible advice, and I understand the generality of the recommenda= tion >since it is difficult to provide detailed advice for the many component >networks of the Internet, many of which are presumably operated differentl= y >from each other in this regard. > >However, I think it might be worth giving an easy example derived from glo= bal >routing operations with BGP. > >For example, choosing multiple addresses for a clock that are covered by t= he >same prefix exported from the local autonomous system (AS) is likely to yi= eld >fewer candidate return paths than choosing addresses covered by different >exported prefixes, since the former can only provide a single exit for all >addresses from a remote AS while the latter potentially can provide more. > >Other examples are no doubt possible. I think it would be useful to includ= e at >least one example, however, since the advice might otherwise be overlooked= . > [TM] Agreed. We propose to update the existing text to the following paragr= aph: If possible, the set of IP addresses for each clock should be chosen in a w= ay that enables the establishment of paths that are the most different. If = the load balancing rules in the network are known, it is possible to choose= the IP addresses in a way that enforces path diversity. However, even if t= he load balancing scheme is not known, a careful choice of the IP addresses= can increase the probability of path diversity. For example, choosing mult= iple addresses with different prefixes is likely to produce higher path div= ersity, as BGP routers are more likely to route these different prefixes th= rough different routes. >Suggestions for Section 5.3 > >1. Header parameters used for flow hashing in traceroute vs. clock protoco= l > >It was observed earlier in the document that in some networks flow buckets >are associated with a tuple of packet headers that includes transport prot= ocol >identifiers (e.g. UDP) and transport layer addresses (e.g. UDP port number= s). > >A traceroute implementation that wants to identify the path used by the >timing protocol would need to take care to use the same values in the head= ers >of its probe packets as is used by the network timing protocol, to the ext= ent >that routers in the intermediate networks between master and slave use tho= se >values to identify individual packets that will be forwarded along congrue= nt >paths. > >However, some or even most implementations (e.g. the original Van Jacobsen >traceroute that continues to ship with BSD variants) vary some of these >parameters in order to support concurrent operation by multiple users of t= he >same system, or to allow multiple probe packets to be in flight simultaneo= usly >to speed up the process of mapping a path. VJ traceroute varies the >destination UDP port number, for example. > >I think it is worth noting in this section that if the particular algorith= m >employed for traceroute is not identical to the clock protocol being used,= as >seen by the network, it is entirely possible that the paths taken by trace= route >probe packets and packets associated with the clock protocol will be >different. The extent to which traceroute will be useful in the identifica= tion of >identical paths for the clock protocol will vary in practice, and in appli= cations >where the possibility of path diversity is more important than the cost of >identical paths is high it might be better to forego identical path identi= fication >and instead acknowledge that some work will likely be wasted. > [TM] Agreed. We have rephrased the paragraph about Traceroute, and the new = proposed text is: Traceroute-based path discovery can be used for filtering only the IP addre= sses that obtain diverse paths. 'Paris Traceroute' [PARIS] and 'TraceFlow' = [TRACEFLOW] are examples of tools that discover the paths between two point= s in the network. It should be noted that this filtering approach is effect= ive only if the Traceroute implementation uses the same IP addresses and UD= P ports as the synchronization protocol packets. Since some Traceroute impl= ementations vary the UDP ports, they may not be effective in identifying an= d filtering redundant paths. >2. Temporal stability of paths > >Some networks might re-route individual flows over time. The path (A, B) a= nd >the path (C, D) might be different at time T0, but the same at T1, then >different again at T2, as individual routers in the path experience topolo= gy >changes (e.g. interfaces come up and down, or a routing protocol reacts to= an >LSA received from a neighbour). I think it is worth mentioning that if pa= ths are >to be compared to assess whether they are identical, that assessment needs >to be repeated regularly in order to be useful over the lifetime of an >association between a clock master and slave, which is presumed to be long >compared to the expected stability of an arbitrary path over the Internet. [TM] Agreed, we propose to add the following paragraph: Since network routes change over time, path discovery and redundant path fi= ltering should be performed periodically. Two {master,slave} pairs that pro= duce two diverse paths may be rerouted to use the same paths. Thus, the set= of addresses that are used by each clock should be reassessed regularly. From nobody Thu Aug 11 02:24:59 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE8712D742; Thu, 11 Aug 2016 02:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 I6geLP_DEFnj; Thu, 11 Aug 2016 02:24:56 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 A2BFD12D0AC; Thu, 11 Aug 2016 02:24:56 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p186so68320836qkd.1; Thu, 11 Aug 2016 02:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=4R2uuswK32wnPR+32Kbqo/bMuZyy9d0bvX4+n30LU1w=; b=Is3LGq6ykYgKt2EDFC9TChhAwgOUZT3IrAcMgpfwmfG5RAzgK3QywecXn7qkP3idim ttsrjz74hG/P/23k7rYWubQ6hOmVRFA68bl2rXGB1TUUUp6ysALIILtdGsT8eME1xDZA fltE0YtpJzodmOp8b8nqWKNIqEMFpUbc7CTOPRrlAvbXdXiaVigbL5AEnCBopGJD/LHk xewmwqjADIC3WYKaVlnZoo4kN4hFxFVVmhrxHDe+Lav149iViLV0xNZDVab6TXKCIxkE AvSEvJFQCCsG4pUMaP5VQNqkqGTwT39wsiAn44GJxVNsgtE7vfWQg/+DDJurnLcTJrJ0 6KEQ== 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; bh=4R2uuswK32wnPR+32Kbqo/bMuZyy9d0bvX4+n30LU1w=; b=gQOsw9e8bmL6eENEI+DIzRihUCQSu71WXxtLyK0J3ddAEs+P6DfSa/2RkoPIAGdW6X Jf61nlsOp+KTNGk/h0IrImj2OWWf3GJkaCoN6l+vWOFiGtHF6y4zhxQeapxFaWLCDCL8 66qsWHDs/IffORGWbF44DcdmuTZT6+UhXq09PvM4X93hMAk/wcO03wvtIhqiTKTBCKG9 z6uBIdDoID+EKrHPxR2DtVCiU1Yzlp9moMXQdJ9XOH2sf1RKRyzXBN+1p9teyLbgzwGS 2SwiygZnuXZz12vTZIf9MJFjfJhHwbTQOCsTgMq46EZn+I4ji5ycgjVyQ7IC19jQF0ju tm2w== X-Gm-Message-State: AEkoouuWamGiFVLTbQkj3Hxy6gv196wtHF8SzGL/rt9TU+EdKJrvOy9Ov3pl/50k9jR4cznwN3+dYL+88UW01Q== X-Received: by 10.55.198.156 with SMTP id s28mr9934340qkl.202.1470907495619; Thu, 11 Aug 2016 02:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.169.135 with HTTP; Thu, 11 Aug 2016 02:24:55 -0700 (PDT) From: Zhen Cao Date: Thu, 11 Aug 2016 17:24:55 +0800 Message-ID: To: int-dir@ietf.org, int-ads@ietf.org Content-Type: multipart/alternative; boundary=001a1146e50cc61fb10539c85672 Archived-At: Cc: draft-ietf-tictoc-multi-path-synchronization@tools.ietf.org Subject: [Int-dir] INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 09:24:58 -0000 --001a1146e50cc61fb10539c85672 Content-Type: text/plain; charset=UTF-8 I am an assigned INT directorate reviewer for this draft. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherds should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details of the INT directorate, see . Summary I do not see any strong reason to delay the publication of this document as it is. I do have some questions/comments below for discussion. Comments: (I am not experts of NTP/PTP exchanges, but I worked on some MIF (multiple interface, a concluding wg) technology for a while. So the comments./questions stem there) 1. What's the impact of NAT on the MP-NTP/PTP exchanges. The packet from the client will bear with an IP address that collude with some one else, how does the server handle this solution? If this is relevant, I would like to see some discussion in the document. 2. What's the impact of the delay variance of multiple paths on the combining algorithm? Should the server wait for a while before abandoning the message from a certain path? Generally speaking, UDP traffic from multiple paths have big variance. 3. The default route on the host may block the transmission of traffic along a certain IP address that is not within the default interface. This is identified by RFC 6418. A well-known problem is that a multiple-interface host can only send packets through the one with a better route metric. This may have some impact to the operation of MP-NTP/PTP. Some discussion or pointer to the this problem would help implementer to save their digging time. Thanks, Zhen --001a1146e50cc61fb10539c85672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am an assigned INT dire= ctorate reviewer for this draft. These
comments were written primarily for the b= enefit of the Internet
Area Directors. Document editors and shepherds should tre= at these
comments just like they would treat comments from any other IETF=
contributor= s and resolve them along with any other Last Call comments
that have been recei= ved. For more details of the INT directorate,
see <http://www.ietf.org/iesg/directorate.html<= span style=3D"font-size:12.8px">>.

Summary= =C2=A0

<= div>I do not see any strong reason to dela= y the publication of this document as it is.=C2=A0 I do have some questions= /comments below for discussion.=C2=A0


Comments:=C2=A0
(I am not experts of NTP/PTP exchang= es, but I worked on some MIF (multiple interface, a concluding wg) technolo= gy for a while. So the comments./questions stem there)

1. What's the impac= t of NAT on the MP-NTP/PTP exchanges.=C2=A0 The packet from the client will= bear with an IP address that collude with some one else, how does the serv= er handle this solution?=C2=A0 If this is relevant, I would like to see som= e discussion in the document.=C2=A0

2. What's = the impact of the delay variance of multiple paths on the combining algorit= hm?=C2=A0 Should the server wait for a while before abandoning the message = from a certain path? =C2=A0 Generally speaking, UDP traffic from multiple p= aths have big variance.=C2=A0

3. The default route= on the host may block the transmission of traffic along a certain IP addre= ss that is not within the default interface.=C2=A0 This is identified by RF= C=C2=A06418.=C2=A0 A well-known problem is that a multiple-interface host c= an only send packets through the one with a better route metric.=C2=A0 This= may have some impact to the operation of MP-NTP/PTP.=C2=A0 Some discussion= or pointer to the this problem would help implementer to save their diggin= g time.=C2=A0


Thanks,
Zhe= n
--001a1146e50cc61fb10539c85672-- From nobody Thu Aug 11 06:20:47 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1891F12D0FF for ; Thu, 11 Aug 2016 06:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 LrpmjNwbOikX for ; Thu, 11 Aug 2016 06:20:44 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 3968112D0EF for ; Thu, 11 Aug 2016 06:20:44 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id p64so1047315pfb.1 for ; Thu, 11 Aug 2016 06:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Cv93JF9u0j+spfKuAEVBWtWTD5X4P6LQ6zGq3h9s41k=; b=drBX9dZuK2Y5qZXQVsZpU3rmWNbO/Uhfb0o69/TSZwPqCGleYir67GR7hUip1bhZre GiZDpDlVKSomWDO4lXKvYZ/NuOjJjyAeqlSkDsYwPdwqDnHxUFxyyp62yC2IOyGsmgQP QKRgvXi/7sBxzLpG+2vqp4xKO91XtA3PNuw2E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Cv93JF9u0j+spfKuAEVBWtWTD5X4P6LQ6zGq3h9s41k=; b=ii42jJ1IGcleQ3dQuW82RkuCO1yFHqxyxTVTRAX3FuEE1TKZGQJhZU5cm3Kned8Kzr /JQfiq9dWzR7WPt/3nJVrEzWXzJaSXu2ACnJ2BR7+B0gX41Hm3kJZDsU1r7m8TwKKx2h FxZXPDtvfzJAcZe7FUOOAUALMW63uPPtS8q04oHgT34RuIEkA3tiglna0PdUd27y5tOg Ykz3ZFqHc3LwTftw5jjkV7CX8aNd/4oB65W341gx1x3HVNsKighJIndnBEOqlAH8FJzx cdmhma1Z+hkbIeTtbPEG319aC/aRTiIYfekk4T6fLa3gpjkFThvCQkGZLoGr8Nbk7Z8g VJSQ== X-Gm-Message-State: AEkoouuRJH/PMiEB23eC528b9Awo94DlUWT7aezSvy5t/y8/b/HKUSuQZp69sjBbdTtQjg== X-Received: by 10.98.54.134 with SMTP id d128mr17126126pfa.150.1470921643709; Thu, 11 Aug 2016 06:20:43 -0700 (PDT) Received: from [199.212.92.30] ([199.212.92.30]) by smtp.gmail.com with ESMTPSA id a21sm5470771pfe.81.2016.08.11.06.20.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Aug 2016 06:20:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Joe Abley In-Reply-To: <9deea586dda54874922fc3fcf481d124@IL-EXCH01.marvell.com> Date: Thu, 11 Aug 2016 09:20:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <704036BE-CB82-42A0-9343-BD10D7E309D4@hopcount.ca> References: <8B30F88D2EFEB944A62BB42C50B81C0A16144C19@avsrvexchmbx1.microsemi.net> <1c7e0b8243c44f018a135b5fbbf7694a@IL-EXCH01.marvell.com> <9deea586dda54874922fc3fcf481d124@IL-EXCH01.marvell.com> To: Tal Mizrahi X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "int-ads@ietf.org" , "Karen ODonoghue \(odonoghue@isoc.org\)" , "int-dir@ietf.org" , "Alex Shpiner \(alex.shpiner@gmail.com\)" , "suresh.krishnan@ericsson.com" , "Richard Tse \(richard.tse@microsemi.com\)" Subject: Re: [Int-dir] INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 13:20:46 -0000 Hi Tal! Sounds great, glad I could be of use. Nice document. Joe > On 11 Aug 2016, at 03:03, Tal Mizrahi wrote: >=20 > Hi Joe, >=20 > Many thanks for the thorough review and detailed comments. >=20 > Please see my responses below. >=20 > Please let us know if you have further comments. > Regards, > Tal Mizrahi. >=20 >=20 >=20 >> -----Original Message----- >> From: Joe Abley [mailto:jabley@hopcount.ca] >> Sent: Tuesday, August 9, 2016 7:04 AM >> To: int-ads@ietf.org; int-dir@ietf.org >> Cc: shalex@tx.technion.ac.il; Richard Tse; craig.schelp@pmcs.com >> Subject: INT dir review of = draft-ietf-tictoc-multi-path-synchronization-04 >>=20 >> EXTERNAL EMAIL >>=20 >>=20 >> I am an assigned INT directorate reviewer for this draft. These = comments >> were written primarily for the benefit of the Internet Area = Directors. >> Document editors and shepherds should treat these comments just like = they >> would treat comments from any other IETF contributors and resolve = them >> along with any other Last Call comments that have been received. For = more >> details of the INT directorate, see >> . >>=20 >> Summary >>=20 >> This document is clearly-written and informative. I identified a = couple of areas >> where some additional discussion might be useful, but no glaring = ommission >> or other problem that would be a reason not to publish as-is, if the = authors >> prefer. >>=20 >> Suggestions for Section 5 >>=20 >> The document says, reasonably, that "the set of IP addresses for each = clock >> should be chosen in a way that enables the establishment of paths = that are >> the most different." >>=20 >> This is sensible advice, and I understand the generality of the = recommendation >> since it is difficult to provide detailed advice for the many = component >> networks of the Internet, many of which are presumably operated = differently >> from each other in this regard. >>=20 >> However, I think it might be worth giving an easy example derived = from global >> routing operations with BGP. >>=20 >> For example, choosing multiple addresses for a clock that are covered = by the >> same prefix exported from the local autonomous system (AS) is likely = to yield >> fewer candidate return paths than choosing addresses covered by = different >> exported prefixes, since the former can only provide a single exit = for all >> addresses from a remote AS while the latter potentially can provide = more. >>=20 >> Other examples are no doubt possible. I think it would be useful to = include at >> least one example, however, since the advice might otherwise be = overlooked. >>=20 >=20 > [TM] Agreed. We propose to update the existing text to the following = paragraph: >=20 > If possible, the set of IP addresses for each clock should be chosen = in a way that enables the establishment of paths that are the most = different. If the load balancing rules in the network are known, it is = possible to choose the IP addresses in a way that enforces path = diversity. However, even if the load balancing scheme is not known, a = careful choice of the IP addresses can increase the probability of path = diversity. For example, choosing multiple addresses with different = prefixes is likely to produce higher path diversity, as BGP routers are = more likely to route these different prefixes through different routes. >=20 >=20 >=20 >> Suggestions for Section 5.3 >>=20 >> 1. Header parameters used for flow hashing in traceroute vs. clock = protocol >>=20 >> It was observed earlier in the document that in some networks flow = buckets >> are associated with a tuple of packet headers that includes transport = protocol >> identifiers (e.g. UDP) and transport layer addresses (e.g. UDP port = numbers). >>=20 >> A traceroute implementation that wants to identify the path used by = the >> timing protocol would need to take care to use the same values in the = headers >> of its probe packets as is used by the network timing protocol, to = the extent >> that routers in the intermediate networks between master and slave = use those >> values to identify individual packets that will be forwarded along = congruent >> paths. >>=20 >> However, some or even most implementations (e.g. the original Van = Jacobsen >> traceroute that continues to ship with BSD variants) vary some of = these >> parameters in order to support concurrent operation by multiple users = of the >> same system, or to allow multiple probe packets to be in flight = simultaneously >> to speed up the process of mapping a path. VJ traceroute varies the >> destination UDP port number, for example. >>=20 >> I think it is worth noting in this section that if the particular = algorithm >> employed for traceroute is not identical to the clock protocol being = used, as >> seen by the network, it is entirely possible that the paths taken by = traceroute >> probe packets and packets associated with the clock protocol will be >> different. The extent to which traceroute will be useful in the = identification of >> identical paths for the clock protocol will vary in practice, and in = applications >> where the possibility of path diversity is more important than the = cost of >> identical paths is high it might be better to forego identical path = identification >> and instead acknowledge that some work will likely be wasted. >>=20 >=20 > [TM] Agreed. We have rephrased the paragraph about Traceroute, and the = new proposed text is: >=20 > Traceroute-based path discovery can be used for filtering only the IP = addresses that obtain diverse paths. 'Paris Traceroute' [PARIS] and = 'TraceFlow' [TRACEFLOW] are examples of tools that discover the paths = between two points in the network. It should be noted that this = filtering approach is effective only if the Traceroute implementation = uses the same IP addresses and UDP ports as the synchronization protocol = packets. Since some Traceroute implementations vary the UDP ports, they = may not be effective in identifying and filtering redundant paths. >=20 >=20 >=20 >=20 >=20 >> 2. Temporal stability of paths >>=20 >> Some networks might re-route individual flows over time. The path (A, = B) and >> the path (C, D) might be different at time T0, but the same at T1, = then >> different again at T2, as individual routers in the path experience = topology >> changes (e.g. interfaces come up and down, or a routing protocol = reacts to an >> LSA received from a neighbour). I think it is worth mentioning that = if paths are >> to be compared to assess whether they are identical, that assessment = needs >> to be repeated regularly in order to be useful over the lifetime of = an >> association between a clock master and slave, which is presumed to be = long >> compared to the expected stability of an arbitrary path over the = Internet. >=20 > [TM] Agreed, we propose to add the following paragraph: >=20 > Since network routes change over time, path discovery and redundant = path filtering should be performed periodically. Two {master,slave} = pairs that produce two diverse paths may be rerouted to use the same = paths. Thus, the set of addresses that are used by each clock should be = reassessed regularly. From nobody Thu Aug 11 06:32:11 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F85912D182; Thu, 11 Aug 2016 06:32:09 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jcbxtEawgaxD; Thu, 11 Aug 2016 06:32:07 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 9FE1712B051; Thu, 11 Aug 2016 06:32:07 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u7BDOWbF012649; Thu, 11 Aug 2016 06:32:04 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 24quaqyh77-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Aug 2016 06:32:04 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Aug 2016 16:32:00 +0300 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Thu, 11 Aug 2016 16:32:00 +0300 From: Tal Mizrahi To: Zhen Cao , "int-dir@ietf.org" , "int-ads@ietf.org" , "suresh.krishnan@ericsson.com" Thread-Topic: INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 Thread-Index: AQHR87JBmD0Bhj/kGkKQCgsiLqX1m6BDisowgAAAG7A= Date: Thu, 11 Aug 2016 13:31:59 +0000 Message-ID: <35cdd8616aac476e999c6fea48fb8eb4@IL-EXCH01.marvell.com> References: <8c1d352d1497485ca097257c44b5fe1e@IL-EXCH01.marvell.com> In-Reply-To: <8c1d352d1497485ca097257c44b5fe1e@IL-EXCH01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-11_10:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608110181 Archived-At: Cc: "draft-ietf-tictoc-multi-path-synchronization@tools.ietf.org" Subject: Re: [Int-dir] INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 13:32:09 -0000 RGVhciBaaGVuLA0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcuDQoNClBsZWFzZSBz ZWUgbXkgcmVzcG9uc2VzIGlubGluZSwgYW5kIHBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGVyZSBh cmUgYW55IGZ1cnRoZXIgY29tbWVudHMuDQoNClRoYW5rcywNClRhbC4NCg0KDQo+RnJvbTogWmhl biBDYW8gW21haWx0bzp6aGVuY2FvLmlldGZAZ21haWwuY29tXQ0KPlNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMTEsIDIwMTYgMTI6MjUgUE0NCj5UbzogaW50LWRpckBpZXRmLm9yZzsgaW50LWFkc0Bp ZXRmLm9yZw0KPkNjOiBkcmFmdC1pZXRmLXRpY3RvYy1tdWx0aS1wYXRoLXN5bmNocm9uaXphdGlv bkB0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IElOVCBkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYt dGljdG9jLW11bHRpLXBhdGgtc3luY2hyb25pemF0aW9uLTA0DQo+DQo+SSBhbSBhbiBhc3NpZ25l ZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZXNlIGNvbW1lbnRz DQo+d2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0 IEFyZWEgRGlyZWN0b3JzLg0KPkRvY3VtZW50IGVkaXRvcnMgYW5kIHNoZXBoZXJkcyBzaG91bGQg dHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIHRoZXkNCj53b3VsZCB0cmVhdCBjb21tZW50 cyBmcm9tIGFueSBvdGhlciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQgcmVzb2x2ZSB0aGVtDQo+YWxv bmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIHJlY2Vp dmVkLiBGb3IgbW9yZQ0KPmRldGFpbHMgb2YgdGhlIElOVCBkaXJlY3RvcmF0ZSwgc2VlDQo+PGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS5odG1sPi4NCj4NCj5TdW1tYXJ5DQo+ DQo+SSBkbyBub3Qgc2VlIGFueSBzdHJvbmcgcmVhc29uIHRvIGRlbGF5IHRoZSBwdWJsaWNhdGlv biBvZiB0aGlzIGRvY3VtZW50IGFzIGl0DQo+aXMuwqAgSSBkbyBoYXZlIHNvbWUgcXVlc3Rpb25z L2NvbW1lbnRzIGJlbG93IGZvciBkaXNjdXNzaW9uLg0KPg0KPg0KPkNvbW1lbnRzOg0KPihJIGFt IG5vdCBleHBlcnRzIG9mIE5UUC9QVFAgZXhjaGFuZ2VzLCBidXQgSSB3b3JrZWQgb24gc29tZSBN SUYgKG11bHRpcGxlDQo+aW50ZXJmYWNlLCBhIGNvbmNsdWRpbmcgd2cpIHRlY2hub2xvZ3kgZm9y IGEgd2hpbGUuIFNvIHRoZQ0KPmNvbW1lbnRzLi9xdWVzdGlvbnMgc3RlbSB0aGVyZSkNCj4NCj4x LiBXaGF0J3MgdGhlIGltcGFjdCBvZiBOQVQgb24gdGhlIE1QLU5UUC9QVFAgZXhjaGFuZ2VzLsKg IFRoZSBwYWNrZXQgZnJvbQ0KPnRoZSBjbGllbnQgd2lsbCBiZWFyIHdpdGggYW4gSVAgYWRkcmVz cyB0aGF0IGNvbGx1ZGUgd2l0aCBzb21lIG9uZSBlbHNlLCBob3cNCj5kb2VzIHRoZSBzZXJ2ZXIg aGFuZGxlIHRoaXMgc29sdXRpb24/wqAgSWYgdGhpcyBpcyByZWxldmFudCwgSSB3b3VsZCBsaWtl IHRvIHNlZQ0KPnNvbWUgZGlzY3Vzc2lvbiBpbiB0aGUgZG9jdW1lbnQuDQoNCltUTV0gUG9pbnQg d2VsbC10YWtlbi4NCldlIHByb3Bvc2UgdG8gYWRkIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIHRv IFNlY3Rpb24gNToNCg0KVGhlIHVzZSBvZiBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gKE5B VCkgbWF5IHNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSBlZmZlY3RpdmVuZXNzIG9mIG11bHRpLXBh dGggc3luY2hyb25pemF0aW9uIGluIHNvbWUgY2FzZXMuIEZvciBleGFtcGxlLCBpZiBhIG1hc3Rl ciB1c2VzIG11bHRpcGxlIElQIGFkZHJlc3NlcyB0aGF0IGFyZSB0cmFuc2xhdGVkIHRvIGEgc2lu Z2xlIElQIGFkZHJlc3MsIHRoZSBwYXRoIGRpdmVyc2l0eSBpcyBsaWtlbHkgdG8gYmUgbG93ZXIg dGhhbiBpbiBhIG5ldHdvcmsgdGhhdCBkb2VzIG5vdCB1c2UgTkFULiBUaHVzLCBwYXRoIGRpc2Nv dmVyeSBzaG91bGQgYmUgdXNlZCB0byBpZGVudGlmeSB0aGUgcG9zc2libGUgcGF0aHMgYmV0d2Vl biB0aGUgbWFzdGVyIGFuZCBzbGF2ZS4gUGF0aCBkaXNjb3ZlcnkgaXMgZnVydGhlciBkaXNjdXNz ZWQgaW4gU2VjdGlvbiDigI41LjMuDQoNCg0KDQo+DQo+Mi4gV2hhdCdzIHRoZSBpbXBhY3Qgb2Yg dGhlIGRlbGF5IHZhcmlhbmNlIG9mIG11bHRpcGxlIHBhdGhzIG9uIHRoZSBjb21iaW5pbmcNCj5h bGdvcml0aG0/wqAgU2hvdWxkIHRoZSBzZXJ2ZXIgd2FpdCBmb3IgYSB3aGlsZSBiZWZvcmUgYWJh bmRvbmluZyB0aGUgbWVzc2FnZQ0KPmZyb20gYSBjZXJ0YWluIHBhdGg/IMKgIEdlbmVyYWxseSBz cGVha2luZywgVURQIHRyYWZmaWMgZnJvbSBtdWx0aXBsZSBwYXRocw0KPmhhdmUgYmlnIHZhcmlh bmNlLg0KDQpbVE1dIFllcywgaW5kZWVkIHRoZSBkZWxheSB2YXJpYXRpb24gaXMgYSBtYWpvciBm YWN0b3IgaW4gdGhlIGNvbWJpbmluZyBhbGdvcml0aG0uIA0KVGhlIGN1cnJlbnQgZG9jdW1lbnQg YnJpZWZseSBtZW50aW9ucyB0aGUgbmVlZCBmb3IgYSBjb21iaW5pbmcgYWxnb3JpdGhtIGluIFNl Y3Rpb24gNiwgd2l0aCBhIHJlZmVyZW5jZSB0byBvdGhlciBkb2N1bWVudHMgdGhhdCBkaXNjdXNz IHBvc3NpYmxlIGNvbWJpbmluZyBhbGdvcml0aG1zLiBJbmRlZWQsIHRoZXNlIG90aGVyIGRvY3Vt ZW50cyBtYWtlIHVzZSBvZiB0aGUgZGVsYXkgdmFyaWF0aW9uIGFzIG9uZSBvZiB0aGUgbW9zdCBp bXBvcnRhbnQgZmFjdG9ycyBpbiB0aGUgYWxnb3JpdGhtLg0KV2UgYmVsaWV2ZSB0aGUgY3VycmVu dCB0ZXh0IGluIFNlY3Rpb24gNiBpcyBzdWZmaWNpZW50LCBnaXZlbiB0aGF0IGNvbWJpbmluZyBh bGdvcml0aG1zIGFyZSBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KUGxl YXNlIGxldCB1cyBrbm93IGlmIHlvdSBiZWxpZXZlIG90aGVyd2lzZS4NCg0KDQo+DQo+My4gVGhl IGRlZmF1bHQgcm91dGUgb24gdGhlIGhvc3QgbWF5IGJsb2NrIHRoZSB0cmFuc21pc3Npb24gb2Yg dHJhZmZpYyBhbG9uZyBhDQo+Y2VydGFpbiBJUCBhZGRyZXNzIHRoYXQgaXMgbm90IHdpdGhpbiB0 aGUgZGVmYXVsdCBpbnRlcmZhY2UuwqAgVGhpcyBpcyBpZGVudGlmaWVkIGJ5DQo+UkZDwqA2NDE4 LsKgIEEgd2VsbC1rbm93biBwcm9ibGVtIGlzIHRoYXQgYSBtdWx0aXBsZS1pbnRlcmZhY2UgaG9z dCBjYW4gb25seQ0KPnNlbmQgcGFja2V0cyB0aHJvdWdoIHRoZSBvbmUgd2l0aCBhIGJldHRlciBy b3V0ZSBtZXRyaWMuwqAgVGhpcyBtYXkgaGF2ZSBzb21lDQo+aW1wYWN0IHRvIHRoZSBvcGVyYXRp b24gb2YgTVAtTlRQL1BUUC7CoCBTb21lIGRpc2N1c3Npb24gb3IgcG9pbnRlciB0byB0aGUNCj50 aGlzIHByb2JsZW0gd291bGQgaGVscCBpbXBsZW1lbnRlciB0byBzYXZlIHRoZWlyIGRpZ2dpbmcg dGltZS4NCg0KW1RNXSBSaWdodC4gVGhhbmtzIGZvciBwb2ludGluZyB0aGF0IG91dC4gV2UgcHJv cG9zZSB0aGUgZm9sbG93aW5nIHBhcmFncmFwaDoNCg0KVGhlIGNvbmNlcHQgb2YgdXNpbmcgbXVs dGlwbGUgSVAgYWRkcmVzc2VzIG9yIG11bHRpcGxlIGludGVyZmFjZXMgaXMgYSB3ZWxsLWVzdGFi bGlzaGVkIGNvbmNlcHQgdGhhdCBpcyBiZWluZyB1c2VkIHRvZGF5IGJ5IHZhcmlvdXMgYXBwbGlj YXRpb25zIGFuZCBwcm90b2NvbHMsIGUuZy4sIFtNUFRDUF0uIEl0IHNob3VsZCBiZSBub3RlZCB0 aGF0IHVzaW5nIG11bHRpcGxlIGludGVyZmFjZXMgaW50cm9kdWNlcyBzb21lIGNoYWxsZW5nZXMg YW5kIGlzc3Vlcywgd2hpY2ggd2VyZSBwcmVzZW50ZWQgYW5kIGRpc2N1c3NlZCBpbiBbUkZDNjQx OF0uDQoNCg0KPg0KPlRoYW5rcywNCj5aaGVuDQo= From nobody Mon Aug 15 07:14:27 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AE512DE12; Mon, 15 Aug 2016 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 Q2qwDM-klnw9; Mon, 15 Aug 2016 07:14:25 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615E612DE30; Mon, 15 Aug 2016 07:14:25 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 34BCB880DB; Mon, 15 Aug 2016 07:14:25 -0700 (PDT) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9B5BF3280ADF; Mon, 15 Aug 2016 07:14:24 -0700 (PDT) To: "" , "int-ads@ietf.org" , draft-ietf-6lo-6lobac@ietf.org From: Brian Haberman Message-ID: <78a152f9-45e0-f29a-dfe3-b3121f5f5db9@innovationslab.net> Date: Mon, 15 Aug 2016 10:14:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mMMghnNrJ8w6QNOvc1a98GoFK4K8NRsAi" Archived-At: Subject: [Int-dir] INT Dir Review : draft-ietf-6lo-6lobac X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 14:14:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mMMghnNrJ8w6QNOvc1a98GoFK4K8NRsAi Content-Type: multipart/mixed; boundary="QMG1Jcxc7ksxlMC9OVBxkpnUTtmXdb1HR" From: Brian Haberman To: "" , "int-ads@ietf.org" , draft-ietf-6lo-6lobac@ietf.org Message-ID: <78a152f9-45e0-f29a-dfe3-b3121f5f5db9@innovationslab.net> Subject: INT Dir Review : draft-ietf-6lo-6lobac --QMG1Jcxc7ksxlMC9OVBxkpnUTtmXdb1HR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am an assigned INT directorate reviewer for this draft. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherds should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details of the INT directorate, see . Summary This document is clearly written and informative. I just have a few comments/questions that would be good to clear up prior to publication. - Section 1.3 shows a padding option, but does not sufficiently describe when/how to use it. Is there sufficient discussion in the BACnet spec on the use of the padding option? - In section 3, the document says that multicast is not supported at the link layer so IPv6 multicast packets SHOULD be sent as broadcast. If multicast is not supported, why is the requirement to broadcast only a "SHOULD"? What other options could be used to disseminate the IPv6 multicast packets? This also applies to section 9. - Section 6 uses the phrase "forwardable address". Do you really mean "globally scoped address"? If so, why not just say that since "globally scoped" is generally acceptable? If this is changed in section 6, it also needs to be changed in section 12. Regards, Brian --QMG1Jcxc7ksxlMC9OVBxkpnUTtmXdb1HR-- --mMMghnNrJ8w6QNOvc1a98GoFK4K8NRsAi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXsc4/AAoJEBOZRqCi7goq99oH/RcNhy8qTNeHcr1t5gObRDrB HOEGUzBWAeeiINvmOQ9Sifnhy9IywNBKOwi3Qx8w8o1PZZN+bi9EIXiwC4+9rCbM kwD5PXhy6Vz9mU5cn+uw9bYmSFLzqoLtGau54xDJ5axWkm2phJHJxo94DTADZYmW IbWdEcJ7by9hmRUMVIzJ8qJOsc3TtDubNsWNCEK3vGCWU+J25rP0ogvOUoi2UGYh ZyLMj7g0bZx220qJ47Zl9SnAYYUwu9c2M8mpdkOVYY7IMg4HF/Qas0UH7ztzOdS/ 6YP9mn9rPsD+pEWvctPZg17HwcnfsmhQpznrRv42zmlJY/aWGq65KgQybQb8DbM= =M/1B -----END PGP SIGNATURE----- --mMMghnNrJ8w6QNOvc1a98GoFK4K8NRsAi-- From nobody Mon Aug 15 09:29:23 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB412D68B; Mon, 15 Aug 2016 09:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gQv0_g4PNgk9; Mon, 15 Aug 2016 09:29:18 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1630612D0DC; Mon, 15 Aug 2016 09:29:12 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id b62so83849883iod.3; Mon, 15 Aug 2016 09:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=w8MTGbWwo3Gag3SKq4b5fTccrhl/vKC7l6qefKDf9ks=; b=xRqBnaReiyacfUcemm0vYLFK2Ol1nxE2qYopWRsQnVDSCl5SXTtXBALne2vZ14Cvq+ zZM3YEJve4z0SAJQLccaGRNbDUFOBt3qxSSy6bh8kuvhieCiNhAn4gbxsJR6WmkDR5rC AzQAzUBN6aWixZC8uOyC5BIGSMpPGNEJO7esR97igsNtYsX0YWn+K94qXSKAzonp50Tw X+fpI49WQHLusJJRKtBi0cpaEvg/SMhdCDJpMFcUOUINYkbNgCBwXqHRPNCyrJ2PQIjA wPfVggzZvPuQgyQKJKUMe4+RnOxpR26KexiQk5JpgyH9k7VjB0FiMaYqa8NdOzS+j1Ef SrtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=w8MTGbWwo3Gag3SKq4b5fTccrhl/vKC7l6qefKDf9ks=; b=LH/9YrAIX3waTdqq+Rlf5TPe8LXuxZFoxaVC4Xl1GRr+cSOdR7a8tBZLP/jMGWM+gz pynaf0L8QzF6Wq+6Bv4LvpjDIx7sGaiJhlDggIGAvU9H8KxqBeg5DIfYJKQ8A0X8/Xew rMj1gv9wWZIFoywNtdfDLG26zoXc+r1Bw4fcTbmhfku4ZOTovA0EfChG5nt4O1l0M6Qe fe7fWnkrkZNR0np+b37QdtEOej7Sbx34WQIUW2dbZNivQjhO8ZaxlIJQSY+kcpGNuXJI sNF3+P16C/zUXnq1LumQzLvKoro2S6enJdnNIZOGPu0YAceBg6l5AVdVmHatzbuu98mQ fJZQ== X-Gm-Message-State: AEkoousO3loGZvlI/rEMZvQdCR9TCmHIEVeW2OUCjKkl0SceIlrN3BZi/d3QLIfyE8LX8vBOVKtwtooxn5p3nA== X-Received: by 10.107.171.2 with SMTP id u2mr34355159ioe.111.1471278551411; Mon, 15 Aug 2016 09:29:11 -0700 (PDT) MIME-Version: 1.0 Sender: kerlyn2001@gmail.com Received: by 10.107.9.22 with HTTP; Mon, 15 Aug 2016 09:29:10 -0700 (PDT) In-Reply-To: <78a152f9-45e0-f29a-dfe3-b3121f5f5db9@innovationslab.net> References: <78a152f9-45e0-f29a-dfe3-b3121f5f5db9@innovationslab.net> From: Kerry Lynn Date: Mon, 15 Aug 2016 12:29:10 -0400 X-Google-Sender-Auth: G6OkMDWXIU8EqmoDupoGY6biAgw Message-ID: To: Brian Haberman Content-Type: multipart/alternative; boundary=94eb2c05ea7e6c3399053a1ebb6e Archived-At: Cc: draft-ietf-6lo-6lobac@ietf.org, "int-ads@ietf.org" , "" Subject: Re: [Int-dir] INT Dir Review : draft-ietf-6lo-6lobac X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:29:21 -0000 --94eb2c05ea7e6c3399053a1ebb6e Content-Type: text/plain; charset=UTF-8 Hi Brian, Thanks for the review. The MS/TP (Master-Slave/Token Passing) specification is embedded as clause 9 in the ISO/ANSI/ASHRAE 135-2012 spec. It is open, but not not free. I can, however, provide a copy of the relevant sections of the BACnet spec for any IETF reviewer who would like them. Answers inline... On Mon, Aug 15, 2016 at 10:14 AM, Brian Haberman wrote: > I am an assigned INT directorate reviewer for this draft. These comments > were written primarily for the benefit of the Internet Area Directors. > Document editors and shepherds should treat these comments just like > they would treat comments from any other IETF contributors and resolve > them along with any other Last Call comments that have been received. > For more details of the INT directorate, see > . > > Summary > > This document is clearly written and informative. I just have a few > comments/questions that would be good to clear up prior to publication. > > - Section 1.3 shows a padding option, but does not sufficiently describe > when/how to use it. Is there sufficient discussion in the BACnet spec on > the use of the padding option? > > The padding octet is discussed in BACnet sub-clause 9.2.3: "Transmitter disable: A node shall not disable its EIA-485 driver until the stop bit of the final octet of a frame has been generated. The node shall disable its EIA-485 driver within Tpostdrive after the beginning of the stop bit of the final octet of a frame in order that it not interfere with any subsequent frame transmitted by another node. This specification allows, but does not encourage, the use of a "padding" octet after the final octet of a frame in order to facilitate the use of common UART transmit interrupts for driver disable control. If a "padding" octet is used, its value shall be X'FF'. The "padding" octet is not considered part of the frame, that is, it shall be included within T postdrive . - In section 3, the document says that multicast is not supported at the > link layer so IPv6 multicast packets SHOULD be sent as broadcast. If > multicast is not supported, why is the requirement to broadcast only a > "SHOULD"? What other options could be used to disseminate the IPv6 > multicast packets? This also applies to section 9. > > This was changed to a SHOULD during WG review of the document. The other option is to serially unicast packets with multicast destination addresses (though I have no idea why you'd want to do this over a wired medium). > - Section 6 uses the phrase "forwardable address". Do you really mean > "globally scoped address"? If so, why not just say that since "globally > scoped" is generally acceptable? If this is changed in section 6, it > also needs to be changed in section 12. > > This is an attempt to align with the definitions of RFC 6890 (although I failed to add this RFC to the references and will do so in the next revision). By using this term, I mean "non link-local", that is, global as well as unique local addresses. HTH, Kerry > Regards, > Brian > > --94eb2c05ea7e6c3399053a1ebb6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

Thanks for the review.=C2=A0 = The MS/TP (Master-Slave/Token Passing) specification
is embedded = as clause 9 in the ISO/ANSI/ASHRAE 135-2012 spec.=C2=A0 It is open,
but not not free.=C2=A0 I can, however, provide a copy of the relevant s= ections of the
BACnet spec for any IETF reviewer who would like t= hem.=C2=A0 Answers inline...

On Mon, Aug 15, 2016 at 10:14 AM, Brian Haberman <= brian@innovationslab.net> wrote:
I am an assigned INT directorate reviewer for this= draft. These comments
were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherds should treat these comments just like
they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received.
For more details of the INT directorate, see
<http://www.ietf.org/iesg/directorate.html>.=

Summary

This document is clearly written and informative. I just have a few
comments/questions that would be good to clear up prior to publication.

- Section 1.3 shows a padding option, but does not sufficiently describe when/how to use it. Is there sufficient discussion in the BACnet spec on the use of the padding option?

The padding octet is discussed in BACnet sub-clause 9= .2.3:

"Transmitter disable: A node shall not = disable its EIA-485 driver until the stop
bit of the final octet = of a frame has been generated.=C2=A0 The node shall disable its
E= IA-485 driver within Tpostdrive=C2=A0 after the beg= inning of the stop bit of the final
octet of a frame in order tha= t it not interfere with any subsequent frame
transmitted by anoth= er node. This specification allows, but does not encourage,
the u= se of a "padding" octet after the final octet of a frame in order= to facilitate
the use of common UART transmit interrupts for dri= ver disable control. If a
"padding" octet is used, its = value shall be X'FF'. The "padding" octet is not
considered part of the frame, that is, it shall be included within Tpostdrive .

- In section 3, the document says that multicast is not supported at the link layer so IPv6 multicast packets SHOULD be sent as broadcast. If
multicast is not supported, why is the requirement to broadcast only a
"SHOULD"? What other options could be used to disseminate the IPv= 6
multicast packets? This also applies to section 9.

This was changed to a SHOULD during WG review of the = document.=C2=A0 The
other option is to serially unicast packets w= ith multicast destination addresses
(though I have no idea why yo= u'd want to do this over a wired medium).
=C2=A0
- Section 6 uses the phrase "forwardable address". Do you really = mean
"globally scoped address"? If so, why not just say that since &qu= ot;globally
scoped" is generally acceptable? If this is changed in section 6, it also needs to be changed in section 12.

This is an attempt to align with the definitions of R= FC 6890 (although I
failed to add this RFC to the references and = will do so in the next revision).
By using this term, I mean &quo= t;non link-local", that is, global as well as unique
local a= ddresses.

HTH, Kerry
=C2=A0=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Regards,
Brian


--94eb2c05ea7e6c3399053a1ebb6e-- From nobody Mon Aug 15 10:02:24 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB76112D0DC; Mon, 15 Aug 2016 10:02:23 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 FNUhzrOFEyHX; Mon, 15 Aug 2016 10:02:22 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D9F12D0B1; Mon, 15 Aug 2016 10:02:22 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7429288119; Mon, 15 Aug 2016 10:02:22 -0700 (PDT) Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C01953280ADF; Mon, 15 Aug 2016 10:02:21 -0700 (PDT) To: Kerry Lynn References: <78a152f9-45e0-f29a-dfe3-b3121f5f5db9@innovationslab.net> From: Brian Haberman Message-ID: Date: Mon, 15 Aug 2016 13:02:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xD6KX5LbKM9ih4i9v0BHULOHRuEPcNGEP" Archived-At: Cc: draft-ietf-6lo-6lobac@ietf.org, "int-ads@ietf.org" , "" Subject: Re: [Int-dir] INT Dir Review : draft-ietf-6lo-6lobac X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 17:02:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xD6KX5LbKM9ih4i9v0BHULOHRuEPcNGEP Content-Type: multipart/mixed; boundary="U4ltcJh3uGwJLkh8NbWfwtd7vFdP1xxLK" From: Brian Haberman To: Kerry Lynn Cc: "" , "int-ads@ietf.org" , draft-ietf-6lo-6lobac@ietf.org Message-ID: Subject: Re: INT Dir Review : draft-ietf-6lo-6lobac References: <78a152f9-45e0-f29a-dfe3-b3121f5f5db9@innovationslab.net> In-Reply-To: --U4ltcJh3uGwJLkh8NbWfwtd7vFdP1xxLK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kerry, On 8/15/16 12:29 PM, Kerry Lynn wrote: > Hi Brian, >=20 > Thanks for the review. The MS/TP (Master-Slave/Token Passing) specific= ation > is embedded as clause 9 in the ISO/ANSI/ASHRAE 135-2012 spec. It is op= en, > but not not free. I can, however, provide a copy of the relevant secti= ons > of the > BACnet spec for any IETF reviewer who would like them. Answers inline.= =2E. >=20 > On Mon, Aug 15, 2016 at 10:14 AM, Brian Haberman > wrote: >=20 >> I am an assigned INT directorate reviewer for this draft. These commen= ts >> were written primarily for the benefit of the Internet Area Directors.= >> Document editors and shepherds should treat these comments just like >> they would treat comments from any other IETF contributors and resolve= >> them along with any other Last Call comments that have been received. >> For more details of the INT directorate, see >> . >> >> Summary >> >> This document is clearly written and informative. I just have a few >> comments/questions that would be good to clear up prior to publication= =2E >> >> - Section 1.3 shows a padding option, but does not sufficiently descri= be >> when/how to use it. Is there sufficient discussion in the BACnet spec = on >> the use of the padding option? >> >> The padding octet is discussed in BACnet sub-clause 9.2.3: >=20 > "Transmitter disable: A node shall not disable its EIA-485 driver until= the > stop > bit of the final octet of a frame has been generated. The node shall > disable its > EIA-485 driver within Tpostdrive after the beginning of the stop bit o= f > the final > octet of a frame in order that it not interfere with any subsequent fra= me > transmitted by another node. This specification allows, but does not > encourage, > the use of a "padding" octet after the final octet of a frame in order = to > facilitate > the use of common UART transmit interrupts for driver disable control. = If a > "padding" octet is used, its value shall be X'FF'. The "padding" octet = is > not > considered part of the frame, that is, it shall be included within T > postdrive . It may be useful to say in 1.3 that use of the padding is described in the BACnet spec. Not crucial, so I will leave it up to you and Suresh to decide. >=20 > - In section 3, the document says that multicast is not supported at th= e >> link layer so IPv6 multicast packets SHOULD be sent as broadcast. If >> multicast is not supported, why is the requirement to broadcast only a= >> "SHOULD"? What other options could be used to disseminate the IPv6 >> multicast packets? This also applies to section 9. >> >> This was changed to a SHOULD during WG review of the document. The > other option is to serially unicast packets with multicast destination > addresses > (though I have no idea why you'd want to do this over a wired medium). >=20 I agree that I wouldn't want to use serial unicast, especially given the token passing nature of the medium. If the link is heavily populated, would a node get a chance to transmit all those copies in a single period= ? If the SHOULD stays, and I don't think it should, I would suggest adding a *brief* blurb on any interoperability issues that would arise by using the alternative approach. >=20 >> - Section 6 uses the phrase "forwardable address". Do you really mean >> "globally scoped address"? If so, why not just say that since "globall= y >> scoped" is generally acceptable? If this is changed in section 6, it >> also needs to be changed in section 12. >> >> This is an attempt to align with the definitions of RFC 6890 (although= I > failed to add this RFC to the references and will do so in the next > revision). > By using this term, I mean "non link-local", that is, global as well as= > unique > local addresses. >=20 Well... ULAs are globally scoped, per RFC 4193, so I think saying "globally scoped" is more accurate. Again, this is up to you and Suresh to decide. Regards, Brian --U4ltcJh3uGwJLkh8NbWfwtd7vFdP1xxLK-- --xD6KX5LbKM9ih4i9v0BHULOHRuEPcNGEP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXsfWcAAoJEBOZRqCi7goqKY8IAKKes/A/VvjJWuqbTkeVIHyG efnrTAX0xWBil+r/k6/ROndXp3kSEnFibRvgEHM++a1MQAV2/RmTUPqhTmS/NW1h B4LOd+ZXCYllJ8MmTHcVvpHd53St6NMTV45N/yzwOP53chBaVePuAvpWBgAVTMFZ UmFh8CMHUMfWGPRhuNH4G+GpZ4fMiVqVCJTVxo8VbSVN5ycMA4JgUlzWHZ07/0CM iuftr+WXVR5drFwW4jfSwqkaLgyxLSpm8X15lxXniYcvYVPeT5q6R2EcHr6++BmS kkZ2ncFpDjQOUoW82Kg8FspaRxR0eU1ei3T7Bfv+Llvkd8LqyFztvnmV34ZS7Go= =Rt5C -----END PGP SIGNATURE----- --xD6KX5LbKM9ih4i9v0BHULOHRuEPcNGEP-- From nobody Thu Aug 18 07:57:57 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E0212DF5C for ; Thu, 18 Aug 2016 07:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 atGxeDB2Fmcj for ; Thu, 18 Aug 2016 07:57:51 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6064812DF57 for ; Thu, 18 Aug 2016 07:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q3dVvOfKWyOgiiKlwF0FhUjYSM05uLdisErnkio3U/Q=; b=S5EavvODMFtnGana7RE/x+iwRLBtfwUaJFvzs96L6yFp7erndNYL5t4slYtTP9GSpTxr6xat6169cMHpTlKjB7NjWmGKTpyxlm+2NVZlv32k9CPilnO2Tx02C3ZASWJ+c2aovzhOgjkTdq+6QN0p1R5POSib3KBv7xNKTDYYOio= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0081.outbound.protection.outlook.com [94.245.120.81]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-10-CXcbUp0fPyOfk9-O4wWhPg-1; Thu, 18 Aug 2016 15:57:44 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 18 Aug 2016 14:57:41 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0549.023; Thu, 18 Aug 2016 14:57:43 +0000 From: Tim Chown To: "draft-ietf-6lo-6lobac@ietf.org" , "int-dir@ietf.org" , "int-ads@ietf.org" Thread-Topic: INT-DIR review of draft-ietf-6lo-6lobac-05 Thread-Index: AQHR+WDfo4oti3rCJEipc7WYkQEYmA== Date: Thu, 18 Aug 2016 14:57:43 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:40e7:11b4:5d66:22af] x-ms-office365-filtering-correlation-id: 74f601e4-da61-40be-2c46-08d3c778024c x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:BFVw2p3kXfdM/2DdRImCcZWVhK9sD8cy9Dx/RzKZBqQWGbQQlJnSa98ePj790X+4zu8fD8yFJJnkS79gMH+E5mwsETcXV2Pw3lpeVJgbuRPGS9sLhK7JARumJRNBNoV7nTJdcRclocIZ2NG1V9pB7DLxRaX1znP/yOlmXN9RBUA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0038DE95A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(2900100001)(105586002)(2501003)(7736002)(2201001)(50226002)(92566002)(50986999)(19580395003)(83716003)(7846002)(87936001)(8676002)(8936002)(15975445007)(7906003)(107886002)(586003)(101416001)(81156014)(57306001)(81166006)(82746002)(229853001)(36756003)(10400500002)(3660700001)(2906002)(230783001)(106356001)(19617315012)(77096005)(19300405004)(450100001)(68736007)(33656002)(122556002)(86362001)(6116002)(106116001)(19273905006)(189998001)(74482002)(102836003)(16236675004)(97736004)(5002640100001)(5001770100001)(3280700002)(3826002)(562404015)(104396002)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2016 14:57:43.3938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: CXcbUp0fPyOfk9-O4wWhPg-1 Content-Type: multipart/alternative; boundary="_000_A14FE5692CFB4D7A9ED1D0710C3F2521jiscacuk_" Archived-At: Subject: [Int-dir] INT-DIR review of draft-ietf-6lo-6lobac-05 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 14:57:56 -0000 --_000_A14FE5692CFB4D7A9ED1D0710C3F2521jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gYW4gYXNzaWduZWQgSU5UIGRpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlz IGRyYWZ0LiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVu ZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJlYSBEaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5k IHNoZXBoZXJkcyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIHRoZXkgd291 bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kIHJl c29sdmUgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBo YXZlIGJlZW4gcmVjZWl2ZWQuIEZvciBtb3JlIGRldGFpbHMgb2YgdGhlIElOVCBkaXJlY3RvcmF0 ZSwgc2VlIDxodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUuaHRtbD4uDQoNClN1 bW1hcnkNCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBtZWNoYW5pc21zIGZvciBkZWxpdmVy aW5nIElQdjYgb3ZlciBNYXN0ZXItU2xhdmUvVG9rZW4gUGFzc2luZyAoTVMvVFApLCB3aGljaCBp cyBhIE1BQyBwcm90b2NvbCBjb21tb25seSB1c2VkIGluIGJ1aWxkaW5nIGF1dG9tYXRpb24gbmV0 d29ya3MuIEl0IGluY2x1ZGVzIHRoZSBmcmFtZSBmb3JtYXQgZm9yIHRyYW5zbWl0dGluZyBJUHY2 IHBhY2tldHMsICBhcyB3ZWxsIGFzIHRoZSBtZXRob2QgZm9yIGZvcm1pbmcgbGluay1sb2NhbCBh bmQgc3RhdGVsZXNzbHkgYXV0by1jb25maWd1cmVkIElQdjYgYWRkcmVzc2VzLg0KDQpJIHdhcyBu b3QgZmFtaWxpYXIgd2l0aCB0aGUgd29yayBwcmlvciB0byByZWFkaW5nIGl0LCBidXQgZm91bmQg dGhlIHRleHQgdG8gYmUgd2VsbC13cml0dGVuIGFuZCBlYXN5IHRvIHJlYWQsIHdpdGggaXQgZm9s bG93aW5nIGEgc2ltaWxhciBzdHJ1Y3R1cmUgdG8gb3RoZXIgSUVURiBJUHY2LW92ZXItZm9vIGRv Y3VtZW50cy4NCg0KU29tZSBzcGVjaWZpYyBwb2ludHMgb2Ygbm90ZSByZWdhcmRzIE1TL1RQIGFy ZSB0aGF0IGl0IGhhcyA4LWJpdCBNQUMgYWRkcmVzc2VzLCBpdCBoYXMgbm8gbXVsdGljYXN0IChz byBtdWx0aWNhc3QgcGFja2V0cyBhcmUgc2VudCB0byB0aGUgOC1iaXQgYnJvYWRjYXN0IGRlc3Rp bmF0aW9uIGFkZHJlc3MgKDI1NSksIGl0IGNhbiBzdXBwb3J0IE1UVXMgb2YgMTI4MC0xNTAwIChh bmQgYWJvdmUpLCBhbmQsIGFzIGEgd2lyZWQgcHJvdG9jb2wsIGl0IHJ1bnMgYXQgYXJvdW5kIDEx NUtiaXQvcyB1cCB0byAxMDAwbS4NCg0KQ29tbWVudHM6DQoNClRoZSBpbnRyb2R1Y3Rpb24gc2F5 cyB0aGF0IHRoZSDigJxnZW5lcmFsIGFwcHJvYWNoIGlzIHRvIGFkYXB0IGVsZW1lbnRzIG9mIHRo ZSA2TG9XUEFOIHNwZWNpZmljYXRpb25zLCBSRkM0OTQ0LCBSRkM2MjgyIGFuZCBSRkM2Nzc14oCd LiAgVGhpcyBpcyB1bmRlcnN0YW5kYWJsZSBnaXZlbiB0aGUgY29uc3RyYWluZWQgbmF0dXJlIG9m IG5vZGVzIGluIGJ1aWxkaW5nIGF1dG9tYXRpb24gc2NlbmFyaW9zLiBUaGVyZSBhcmUgaG93ZXZl ciBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IHdoZXJlIGl04oCZcyBub3QgY2xlYXIgd2hlcmUgc3Bl Y2lmaWNhbGx5IHRoZXNlIHNwZWNpZmljYXRpb25zIGFyZSBiZWluZyBkcmF3biB1cG9uIGFuZCBh cmUgdG8gYmUgdXNlZC4gU29tZSBtb3JlIGV4cGxpY2l0IHBvaW50ZXJzIG1pZ2h0IGJlIGhlbHBm dWwuICBBbiBleGFtcGxlIG9mIHRoaXMgbGllcyBpbiBTZWN0aW9uIDgsIHdoaWNoIHNheXMgdW5p Y2FzdCBhZGRyZXNzIG1hcHBpbmcgZm9sbG93cyBTZWN0aW9uIDcuMiBvZiBSRkM0ODYxLCBidXQg b25lIG1pZ2h0IGV4cGVjdCBSRkM2Nzc1IChvbiBORCBvcHRpbWlzYXRpb24pIHRvIGJlIHVzZWQs IGUuZy4gd3J0IHNvbGljaXRlZCBub2RlIG11bHRpY2FzdC4NCg0KU2VjdGlvbiAyIGhhcyBzb21l IOKAnG11c3Rz4oCdIHRoYXQgbWlnaHQgYmUgTVVTVHMsIGdpdmVuIFJGQzIxMTkgbGFuZ3VhZ2Ug aXMgZGVmaW5lZCBpbiBTZWN0aW9uIDEuMS4NCg0KSW4gU2VjdGlvbiAzIGl0IHNheXMgdGhhdCBh bGwgbXVsdGljYXN0IHBhY2tldHMgU0hPVUxEIGJlIGJyb2FkY2FzdCBhdCB0aGUgTUFDIGxheWVy LiBXaHkgaXMgdGhpcyBhIFNIT1VMRCwgYW5kIG5vdCBhIE1VU1Q/IE9uZSB3b3VsZCBhc3N1bWUg dW5pY2FzdGluZyBtdWx0aWNhc3QgbWVzc2FnZXMgd291bGQgYmUgZXhwZW5zaXZlIGluIHRoaXMg dHlwZSBvZiBjb25zdHJhaW5lZCBuZXR3b3JrIGFuZCBnaXZlbiB0aGUgdG9rZW4gcGFzc2luZyBt ZWNoYW5pc20gd2hlcmUgdGhlIHRva2VuIGlzIHBhc3NlZCBhZnRlciBzZW5kaW5nIHNvIG1hbnkg cGFja2V0cy4NCg0KVGhlIGludHJvZHVjdGlvbiBzYXlzIGhlYWRlciBjb21wcmVzc2lvbiBzdXBw b3J0IGFzIHBlciBSRkM2MjgyIGlzIFJFUVVJUkVELCBidXQgU2VjdGlvbiA1IGRvZXMgbm90IGV4 cGxpY2l0bHkgc2F5IHRoYXQgdGhlIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgdGhl cmUgTVVTVCBiZSBpbXBsZW1lbnRlZC4gSeKAmWQgc3VnZ2VzdCByZXdyaXRpbmcgdGhlIGZpcnN0 IHNlbnRlbmNlIG9mIFNlY3Rpb24gNSB0byBzYXkgc29tZXRoaW5nIGxpa2Ug4oCcRHVlIHRvIHRo ZSByZWxhdGl2ZWx5IGxvdyBkYXRhIHJhdGVzIG9mIE1TL1RQLCB0aGUgaGVhZGVyIGNvbXByZXNz aW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIE1VU1QgYmUgaW1wbGVtZW50 ZWQgb24gYWxsIG5vZGVzLuKAnQ0KDQpQZXJoYXBzIGJlZm9yZSBTZWN0aW9uIDYsIG9yIGF0IHRo ZSBzdGFydCBvZiBpdCwgdGhlcmUgc2hvdWxkIGJlIHRleHQgc3RhdGluZyB3aGljaCBhZGRyZXNz ZXMgYXJlIGZvcm1lZCwgYW5kIHdoaWNoIG11bHRpY2FzdCBncm91cHMgYXJlIGpvaW5lZC4gRnVy dGhlciwgcGVyaGFwcyB3ZSBjYW4gZHJhdyBvbiBkcmFmdC1pZXRmLTZtYW4tZGVmYXVsdC1paWRz LTEzLCB3aGljaCBpcyBub3cgdmVyeSBjbG9zZSB0byBwdWJsaWNhdGlvbiwgYW5kIHJlZmVyIHRv IHRoZSByZWNvbW1lbmRhdGlvbnMgaW4gU2VjdGlvbiAzIHRoZXJlLCBlLmcuIHRoYXQgUkZDNzIx NyBTSE9VTEQgYmUgdXNlZCwgYW5kIHRoYXQgeW91IFNIT1VMRCBOT1QgZW1iZWQgYSBzdGFibGUg bGluay1sYXllciBhZGRyZXNzIGluIHRoZSBJSUQuDQoNCkl0IHNlZW1zIHRoZSB0ZXh0IGlzIHNh eWluZyB0aGF0IFJGQzcyMTcgaXMgbm90IHRvIGJlIHVzZWQgZm9yIGxpbmstbG9jYWwgSUlEczsg cmF0aGVyIHRoZSB0ZXh0IHN1Z2dlc3RzIHVzaW5nIGEgU0xBQUMtc3R5bGUgYWRkcmVzcyAod2l0 aCB0aGUgbGFzdCA4IGJpdHMgYmVpbmcgdGhlIE1BQyBhZGRyZXNzKSB0byBhbGxvdyBmb3IgZWZm aWNpZW50IGhlYWRlciBjb21wcmVzc2lvbi4gUGVyaGFwcyBzb21lIGV4cGxpY2l0IHRleHQgaGVy ZSB3b3VsZCBoZWxwIChpLmUuIFNIT1VMRCB1c2UgUkZDNzIxNyBmb3IgZ2xvYmFsIHNjb3BlIGFk ZHJlc3NlcywgYnV0IFJFQ09NTUVOREVEIHRoYXQgeW91IHVzZSB0aGUgU0xBQUMtYS1saWtlIG1l Y2hhbmlzbSBmb3IgbGluay1sb2NhbCBhZGRyZXNzZXMgZm9yIGhlYWRlciBjb21wcmVzc2lvbiBl ZmZpY2llbmN5KS4NCg0KVGhlIHRleHQgUkVDT01NRU5ESU5HIHVzZSBvZiBhIHByaXZhY3kgSUlE IGRvZXMgbm90IG1lbnRpb24gUkZDNDk0MSwgcHJlc3VtYWJseSBiZWNhdXNlIFJGQzQ5NDEgdGFy Z2V0cyBJSURzIHdpdGggZW1iZWRkZWQgSUVFRSBNQUMgYWRkcmVzc2VzLCBidXQgdGhlIHByaW5j aXBsZSBmb3IgZ2VuZXJhdGluZyB0aGUgcHJpdmFjeSBhZGRyZXNzIGlzIHRoZSBzYW1lLiAgQXMg aXQgc3RhbmRzLCB0aGUgdGV4dCBkb2VzIG5vdCBkZWZpbmUgaG93IGEgNjQtYml0IHByaXZhY3kg YWRkcmVzcyBpcyBnZW5lcmF0ZWQgKEkgdGhpbmsgd2UgYXNzdW1lIGl04oCZcyBhcyBwZXIgUkZD NDk0MSwgYnV0IGJlIHNwZWNpZmljPykuDQoNCk9uZSBhc3N1bWVzIFJGQzY3MjQtYmFzZWQgYWRk cmVzcyBzZWxlY3Rpb24gaXMgZm9sbG93ZWQsIGluIHdoaWNoIGNhc2UgcHJpdmFjeSBhZGRyZXNz ZXMgd291bGQgYmUgcHJlZmVycmVkIG92ZXIgcHVibGljIGFkZHJlc3NlcywgYW5kIHRodXMgZm9y IGFsbCBjb21tdW5pY2F0aW9ucyBpbml0aWF0ZWQgYnkgdGhlIGRldmljZSwgaXQgd291bGQgYmUg dXNpbmcgbm9uLWNvbXByZXNzaW9uIGZyaWVuZGx5IGFkZHJlc3Nlcy4gSXMgdGhpcyBhIGNvbmNl cm4/ICBPciBtaWdodCB5b3UgZXhwbGljaXRseSBzYXkgaGVyZSBvbmx5IHVzZSBwcml2YWN5IGFk ZHJlc3NlcyBmb3IgZ2xvYmFsIHNjb3BlIHByZWZpeGVzLCBhZ2FpbiBmb3IgZWZmaWNpZW5jeS4N Cg0KU2VjdGlvbiA4IHNob3VsZCBjbGFyaWZ5IHdoaWNoIGVsZW1lbnRzIG9mIFJGQzY3NzUgYXJl IHVzZWQuIEFzIGl04oCZcyB3cml0dGVuLCBJIGFzc3VtZSBub25lLCBidXQgdGhhdOKAmXMgYXQg b2RkcyB3aXRoIHRoZSBpbnRyb2R1Y3Rpb24gdGV4dC4NCg0KU2VjdGlvbiAxMiAobGlrZSBTZWN0 aW9uIDYsIG5vdyBJIG5vdGljZSBpdCkgcmVmZXJzIHRvIOKAnGZvcndhcmRhYmxlIGFkZHJlc3Nl c+KAnS4gRG8geW91IG1lYW4gZ2xvYmFsIHNjb3BlIGFkZHJlc3NlcyAod2hpY2ggd291bGQgaW5j bHVkZSBVTEFzLCBpZiB1c2VkKT8gSWYgc28sIEnigJlkIHN1Z2dlc3QgdXNpbmcgdGhhdCB0ZXJt aW5vbG9neS4NCg0KU2Nhbm5pbmcgYXR0YWNrcyB3aGVyZSBlbWJlZGRlZCA4LWJpdCBNQUMgYWRk cmVzc2VzIGFyZSB1c2VkIGZvciB0aGUgbGFzdCA4LWJpdHMgd291bGQgYmUgcXVpdGUgdHJpdmlh bC4gIEkgdGhpbmsgdGhlIHRleHQgaGVyZSB0aGF0IGJhc2ljYWxseSBzYXlzIOKAnHlvdSBTSE9V TEQgdXNlIFJGQzcyMTciIChmb3IgbG9jYWwgc2NvcGUgYWRkcmVzc2VzKSBzaG91bGQgYmUgZW1w aGFzaXNlZCBpbiBTZWN0aW9uIDY7IGl0IGRvZXNu4oCZdCBuZWVkIHRvIGJlIGhlcmUsIG9yIGlm IGl0IGlzIG1lbnRpb25lZCwgcmVmZXIgdG8gU2VjdGlvbiA2LiAgSeKAmW0gbm90IHN1cmUgb2Yg dGhlIHJlbGV2YW5jZSBvZiBESENQdjYgaGVyZSg/KSwgd2hpbGUgQ0dBcyBhbmQgaGFzaC1iYXNl ZCBhZGRyZXNzZXMgYXJlIG5vdCAoSSBiZWxpZXZlKSBpbiBjb21tb24gdXNlLg0KDQpBcmUgc3Vj aCB3aXJlZCBuZXR3b3JrcyBub3QgbGlhYmxlIHRvIGNhc3VhbCBzbm9wcGluZz8gV2hhdCBoYXBw ZW5zIGlmIEkgdW5wbHVnIGEgZGV2aWNlIGFuZCBwbHVnIG15IG93biBpbiwgdXNpbmcgYSBtYXN0 ZXIgbm9kZSBNQUM/IFByZXN1bWFibHkgdGhlIE1TL1RQIHByb3RvY29sIGRlZmluZXMgbWVjaGFu aXNtcyBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IHN1Y2ggYXR0YWNrcywgdGhhdCB5b3UgY291bGQg Y2l0ZT8NCg0KWW91IG1pZ2h0IGFkZCBpbiBTZWN0aW9uIDEyIHRoYXQgVUxBcyBtYXkgYmUgYXBw cm9wcmlhdGUgZm9yIGJ1aWxkaW5nIG1hbmFnZW1lbnQgc3lzdGVtcyB3aGVyZSB0aGUgY29tbXVu aWNhdGlvbnMgYXJlIGFsbCBpbnRyYS1zaXRlLiAgSWYgZXh0ZXJuYWwgY29tbXVuaWNhdGlvbnMg YXJlIG5lZWRlZCwgYW4gYWRkaXRpb25hbCBJU1AtYmFzZWQgcHJlZml4IGNvdWxkIGJlIHVzZWQu IFRob3VnaCBJIGFwcHJlY2lhdGUgVUxBcyBjYW4gYmUgYSBjb250ZW50aW91cyBzdWJqZWN0LCBz byBpZiB5b3Ugd2FudCB0byBwdWJsaXNoIHF1aWNrbHkgeW91IG1pZ2h0IGNob29zZSB0byBub3Qg c2F5IGFueXRoaW5nIG9uIHRoZSBzdWJqZWN0IChidXQgaXQgd2lsbCBjb21lIHVw4oCmIDopDQoN ClRpbQ0KDQoNCg0K --_000_A14FE5692CFB4D7A9ED1D0710C3F2521jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2Vy bmluZzogbm9uZSIgY2xhc3M9IiI+SSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2 aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJp bHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBJbnRlcm5ldCBBcmVhIERpcmVjdG9ycy4gRG9jdW1l bnQgZWRpdG9ycw0KIGFuZCBzaGVwaGVyZHMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1 c3QgbGlrZSB0aGV5IHdvdWxkIHRyZWF0IGNvbW1lbnRzIGZyb20gYW55IG90aGVyIElFVEYgY29u dHJpYnV0b3JzIGFuZCByZXNvbHZlIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxs IGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIHJlY2VpdmVkLiBGb3IgbW9yZSBkZXRhaWxzIG9mIHRo ZSBJTlQgZGlyZWN0b3JhdGUsIHNlZSAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p ZXNnL2RpcmVjdG9yYXRlLmh0bWwiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSItd2Via2l0LWZvbnQt a2VybmluZzogbm9uZTsiIGNsYXNzPSIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3Rv cmF0ZS5odG1sPC9zcGFuPjwvYT4mZ3Q7Ljwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5T dW1tYXJ5PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1r ZXJuaW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPlRoaXMgZG9jdW1lbnQgZGVmaW5l cyB0aGUgbWVjaGFuaXNtcyBmb3IgZGVsaXZlcmluZyBJUHY2IG92ZXIgTWFzdGVyLVNsYXZlL1Rv a2VuIFBhc3NpbmcgKE1TL1RQKSwgd2hpY2ggaXMgYSBNQUMgcHJvdG9jb2wgY29tbW9ubHkgdXNl ZCBpbiBidWlsZGluZyBhdXRvbWF0aW9uDQogbmV0d29ya3MuIEl0IGluY2x1ZGVzIHRoZSBmcmFt ZSBmb3JtYXQgZm9yIHRyYW5zbWl0dGluZyBJUHY2IHBhY2tldHMsJm5ic3A7IGFzIHdlbGwgYXMg dGhlIG1ldGhvZCBmb3IgZm9ybWluZyBsaW5rLWxvY2FsIGFuZCBzdGF0ZWxlc3NseSBhdXRvLWNv bmZpZ3VyZWQgSVB2NiBhZGRyZXNzZXMuPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48 c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPkkg d2FzIG5vdCBmYW1pbGlhciB3aXRoIHRoZSB3b3JrIHByaW9yIHRvIHJlYWRpbmcgaXQsIGJ1dCBm b3VuZCB0aGUgdGV4dCB0byBiZSB3ZWxsLXdyaXR0ZW4gYW5kIGVhc3kgdG8gcmVhZCwgd2l0aCBp dCBmb2xsb3dpbmcgYSBzaW1pbGFyIHN0cnVjdHVyZSB0byBvdGhlciBJRVRGDQogSVB2Ni1vdmVy LWZvbyBkb2N1bWVudHMuPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPlNvbWUgc3BlY2lm aWMgcG9pbnRzIG9mIG5vdGUgcmVnYXJkcyBNUy9UUCBhcmUgdGhhdCBpdCBoYXMgOC1iaXQgTUFD IGFkZHJlc3NlcywgaXQgaGFzIG5vIG11bHRpY2FzdCAoc28gbXVsdGljYXN0IHBhY2tldHMgYXJl IHNlbnQgdG8gdGhlIDgtYml0IGJyb2FkY2FzdCBkZXN0aW5hdGlvbg0KIGFkZHJlc3MgKDI1NSks IGl0IGNhbiBzdXBwb3J0IE1UVXMgb2YgMTI4MC0xNTAwIChhbmQgYWJvdmUpLCBhbmQsIGFzIGEg d2lyZWQgcHJvdG9jb2wsIGl0IHJ1bnMgYXQgYXJvdW5kIDExNUtiaXQvcyB1cCB0byAxMDAwbS48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6 IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+Q29tbWVudHM6PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0 cHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48 L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5v bmUiIGNsYXNzPSIiPlRoZSBpbnRyb2R1Y3Rpb24gc2F5cyB0aGF0IHRoZSDigJxnZW5lcmFsIGFw cHJvYWNoIGlzIHRvIGFkYXB0IGVsZW1lbnRzIG9mIHRoZSA2TG9XUEFOIHNwZWNpZmljYXRpb25z LCBSRkM0OTQ0LCBSRkM2MjgyIGFuZCBSRkM2Nzc14oCdLiZuYnNwOyBUaGlzIGlzIHVuZGVyc3Rh bmRhYmxlIGdpdmVuDQogdGhlIGNvbnN0cmFpbmVkIG5hdHVyZSBvZiBub2RlcyBpbiBidWlsZGlu ZyBhdXRvbWF0aW9uIHNjZW5hcmlvcy4gVGhlcmUgYXJlIGhvd2V2ZXIgcGxhY2VzIGluIHRoZSBk b2N1bWVudCB3aGVyZSBpdOKAmXMgbm90IGNsZWFyIHdoZXJlIHNwZWNpZmljYWxseSB0aGVzZSBz cGVjaWZpY2F0aW9ucyBhcmUgYmVpbmcgZHJhd24gdXBvbiBhbmQgYXJlIHRvIGJlIHVzZWQuIFNv bWUgbW9yZSBleHBsaWNpdCBwb2ludGVycyBtaWdodCBiZSBoZWxwZnVsLiAmbmJzcDs8L3NwYW4+ QW4NCiBleGFtcGxlIG9mIHRoaXMgbGllcyBpbiBTZWN0aW9uIDgsIHdoaWNoIHNheXMgdW5pY2Fz dCBhZGRyZXNzIG1hcHBpbmcgZm9sbG93cyBTZWN0aW9uIDcuMiBvZiBSRkM0ODYxLCBidXQgb25l IG1pZ2h0IGV4cGVjdCBSRkM2Nzc1IChvbiBORCBvcHRpbWlzYXRpb24pIHRvIGJlIHVzZWQsIGUu Zy4gd3J0IHNvbGljaXRlZCBub2RlIG11bHRpY2FzdC48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5T ZWN0aW9uIDIgaGFzIHNvbWUg4oCcbXVzdHPigJ0gdGhhdCBtaWdodCBiZSBNVVNUcywgZ2l2ZW4g UkZDMjExOSBsYW5ndWFnZSBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMS4xLjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0 OiAxNHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9 IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5n OiBub25lIiBjbGFzcz0iIj5JbiBTZWN0aW9uIDMgaXQgc2F5cyB0aGF0IGFsbCBtdWx0aWNhc3Qg cGFja2V0cyBTSE9VTEQgYmUgYnJvYWRjYXN0IGF0IHRoZSBNQUMgbGF5ZXIuJm5ic3A7V2h5IGlz IHRoaXMgYSBTSE9VTEQsIGFuZCBub3QgYSBNVVNUPyBPbmUgd291bGQgYXNzdW1lIHVuaWNhc3Rp bmcgbXVsdGljYXN0DQogbWVzc2FnZXMgd291bGQgYmUgZXhwZW5zaXZlIGluIHRoaXMgdHlwZSBv ZiBjb25zdHJhaW5lZCBuZXR3b3JrIGFuZCBnaXZlbiB0aGUgdG9rZW4gcGFzc2luZyBtZWNoYW5p c20gd2hlcmUgdGhlIHRva2VuIGlzIHBhc3NlZCBhZnRlciBzZW5kaW5nIHNvIG1hbnkgcGFja2V0 cy48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIg Y2xhc3M9IiI+VGhlIGludHJvZHVjdGlvbiBzYXlzIGhlYWRlciBjb21wcmVzc2lvbiBzdXBwb3J0 IGFzIHBlciBSRkM2MjgyIGlzIFJFUVVJUkVELCBidXQgU2VjdGlvbiA1IGRvZXMgbm90IGV4cGxp Y2l0bHkgc2F5IHRoYXQgdGhlIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBkZXNjcmliZWQgdGhlcmUg TVVTVCBiZSBpbXBsZW1lbnRlZC4NCiBJ4oCZZCBzdWdnZXN0IHJld3JpdGluZyB0aGUgZmlyc3Qg c2VudGVuY2Ugb2YgU2VjdGlvbiA1IHRvIHNheSBzb21ldGhpbmcgbGlrZSDigJxEdWUgdG8gdGhl IHJlbGF0aXZlbHkgbG93IGRhdGEgcmF0ZXMgb2YgTVMvVFAsIHRoZSBoZWFkZXIgY29tcHJlc3Np b24gbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24gTVVTVCBiZSBpbXBsZW1lbnRl ZCBvbiBhbGwgbm9kZXMu4oCdJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+UGVyaGFwcyBi ZWZvcmUgU2VjdGlvbiA2LCBvciBhdCB0aGUgc3RhcnQgb2YgaXQsIHRoZXJlIHNob3VsZCBiZSB0 ZXh0IHN0YXRpbmcgd2hpY2ggYWRkcmVzc2VzIGFyZSBmb3JtZWQsIGFuZCB3aGljaCBtdWx0aWNh c3QgZ3JvdXBzIGFyZSBqb2luZWQuIEZ1cnRoZXIsIHBlcmhhcHMNCiB3ZSBjYW4gZHJhdyBvbiA8 L3NwYW4+ZHJhZnQtaWV0Zi02bWFuLWRlZmF1bHQtaWlkcy0xMywgd2hpY2ggaXMgbm93IHZlcnkg Y2xvc2UgdG8gcHVibGljYXRpb24sIGFuZCByZWZlciB0byB0aGUgcmVjb21tZW5kYXRpb25zIGlu IFNlY3Rpb24gMyB0aGVyZSwgZS5nLiB0aGF0IFJGQzcyMTcgU0hPVUxEIGJlIHVzZWQsIGFuZDxz cGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBO ZXVlJzsiIGNsYXNzPSIiPg0KIHRoYXQgeW91IFNIT1VMRCBOT1QgZW1iZWQgYSBzdGFibGUgbGlu ay1sYXllciBhZGRyZXNzIGluIHRoZSBJSUQ8L3NwYW4+LiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBs aW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+SXQgc2VlbXMgdGhlIHRleHQgaXMgc2F5aW5n IHRoYXQgUkZDNzIxNyBpcyBub3QgdG8gYmUgdXNlZCBmb3IgbGluay1sb2NhbCBJSURzOyByYXRo ZXIgdGhlIHRleHQgc3VnZ2VzdHMgdXNpbmcgYSBTTEFBQy1zdHlsZSBhZGRyZXNzICh3aXRoIHRo ZSBsYXN0IDggYml0cyBiZWluZyB0aGUgTUFDIGFkZHJlc3MpIHRvIGFsbG93IGZvciBlZmZpY2ll bnQNCiBoZWFkZXIgY29tcHJlc3Npb24uIFBlcmhhcHMgc29tZSBleHBsaWNpdCB0ZXh0IGhlcmUg d291bGQgaGVscCAoaS5lLiBTSE9VTEQgdXNlIFJGQzcyMTcgZm9yIGdsb2JhbCBzY29wZSBhZGRy ZXNzZXMsIGJ1dCBSRUNPTU1FTkRFRCB0aGF0IHlvdSB1c2UgdGhlIFNMQUFDLWEtbGlrZSBtZWNo YW5pc20gZm9yIGxpbmstbG9jYWwgYWRkcmVzc2VzIGZvciBoZWFkZXIgY29tcHJlc3Npb24gZWZm aWNpZW5jeSkuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFz cz0iIj5UaGUgdGV4dCBSRUNPTU1FTkRJTkcgdXNlIG9mIGEgcHJpdmFjeSBJSUQgZG9lcyBub3Qg bWVudGlvbiBSRkM0OTQxLCBwcmVzdW1hYmx5IGJlY2F1c2UgUkZDNDk0MSB0YXJnZXRzIElJRHMg d2l0aCBlbWJlZGRlZCBJRUVFIE1BQyBhZGRyZXNzZXMsIGJ1dCB0aGUgcHJpbmNpcGxlIGZvciBn ZW5lcmF0aW5nIHRoZSBwcml2YWN5IGFkZHJlc3MgaXMgdGhlDQogc2FtZS4gJm5ic3A7QXMgaXQg c3RhbmRzLCB0aGUgdGV4dCBkb2VzIG5vdCBkZWZpbmUgaG93IGEgNjQtYml0IHByaXZhY3kgYWRk cmVzcyBpcyBnZW5lcmF0ZWQgKEkgdGhpbmsgd2UgYXNzdW1lIGl04oCZcyBhcyBwZXIgUkZDNDk0 MSwgYnV0IGJlIHNwZWNpZmljPykuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IiBjbGFzcz0iIj5PbmUgYXNzdW1lcyBSRkM2NzI0LWJhc2VkIGFkZHJlc3Mgc2VsZWN0 aW9uIGlzIGZvbGxvd2VkLCBpbiB3aGljaCBjYXNlIHByaXZhY3kgYWRkcmVzc2VzIHdvdWxkIGJl IHByZWZlcnJlZCBvdmVyIHB1YmxpYyBhZGRyZXNzZXMsIGFuZCB0aHVzIGZvciBhbGwgY29tbXVu aWNhdGlvbnMgaW5pdGlhdGVkIGJ5IHRoZSBkZXZpY2UsIGl0IHdvdWxkIGJlIHVzaW5nDQogbm9u LWNvbXByZXNzaW9uIGZyaWVuZGx5IGFkZHJlc3Nlcy4gSXMgdGhpcyBhIGNvbmNlcm4/ICZuYnNw O09yIG1pZ2h0IHlvdSBleHBsaWNpdGx5IHNheSBoZXJlIG9ubHkgdXNlIHByaXZhY3kgYWRkcmVz c2VzIGZvciBnbG9iYWwgc2NvcGUgcHJlZml4ZXMsIGFnYWluIGZvciBlZmZpY2llbmN5LjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWln aHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFz cz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPlNlY3Rpb24gOCBzaG91bGQgY2xhcmlmeSB3aGljaCBlbGVtZW50 cyBvZiBSRkM2Nzc1IGFyZSB1c2VkLiBBcyBpdOKAmXMgd3JpdHRlbiwgSSBhc3N1bWUgbm9uZSwg YnV0IHRoYXTigJlzIGF0IG9kZHMgd2l0aCB0aGUgaW50cm9kdWN0aW9uIHRleHQuPC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1o ZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBj bGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtl cm5pbmc6IG5vbmUiIGNsYXNzPSIiPlNlY3Rpb24gMTIgKGxpa2UgU2VjdGlvbiA2LCBub3cgSSBu b3RpY2UgaXQpIHJlZmVycyB0byDigJxmb3J3YXJkYWJsZSBhZGRyZXNzZXPigJ0uIERvIHlvdSBt ZWFuIGdsb2JhbCBzY29wZSBhZGRyZXNzZXMgKHdoaWNoIHdvdWxkIGluY2x1ZGUgVUxBcywgaWYg dXNlZCk/IElmIHNvLA0KIEnigJlkIHN1Z2dlc3QgdXNpbmcgdGhhdCB0ZXJtaW5vbG9neS48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg bWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5v bmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+U2Nhbm5pbmcgYXR0YWNrcyB3aGVyZSBlbWJlZGRl ZCA4LWJpdCBNQUMgYWRkcmVzc2VzIGFyZSB1c2VkIGZvciB0aGUgbGFzdCA4LWJpdHMgd291bGQg YmUgcXVpdGUgdHJpdmlhbC4mbmJzcDsgSSB0aGluayB0aGUgdGV4dCBoZXJlIHRoYXQgYmFzaWNh bGx5IHNheXMg4oCceW91IFNIT1VMRA0KIHVzZSBSRkM3MjE3JnF1b3Q7IChmb3IgbG9jYWwgc2Nv cGUgYWRkcmVzc2VzKSBzaG91bGQgYmUgZW1waGFzaXNlZCBpbiBTZWN0aW9uIDY7IGl0IGRvZXNu 4oCZdCBuZWVkIHRvIGJlIGhlcmUsIG9yIGlmIGl0IGlzIG1lbnRpb25lZCwgcmVmZXIgdG8gU2Vj dGlvbiA2LiZuYnNwOyBJ4oCZbSBub3Qgc3VyZSBvZiB0aGUgcmVsZXZhbmNlIG9mIERIQ1B2NiBo ZXJlKD8pLCB3aGlsZSBDR0FzIGFuZCBoYXNoLWJhc2VkIGFkZHJlc3NlcyBhcmUgbm90IChJIGJl bGlldmUpIGluDQogY29tbW9uIHVzZS4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9 IiI+QXJlIHN1Y2ggd2lyZWQgbmV0d29ya3Mgbm90IGxpYWJsZSB0byBjYXN1YWwgc25vcHBpbmc/ IFdoYXQgaGFwcGVucyBpZiBJIHVucGx1ZyBhIGRldmljZSBhbmQgcGx1ZyBteSBvd24gaW4sIHVz aW5nIGEgbWFzdGVyIG5vZGUgTUFDPyBQcmVzdW1hYmx5IHRoZSBNUy9UUCBwcm90b2NvbA0KIGRl ZmluZXMgbWVjaGFuaXNtcyBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IHN1Y2ggYXR0YWNrcywgdGhh dCB5b3UgY291bGQgY2l0ZT88L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+WW91IG1pZ2h0 IGFkZCBpbiBTZWN0aW9uIDEyIHRoYXQgVUxBcyBtYXkgYmUgYXBwcm9wcmlhdGUgZm9yIGJ1aWxk aW5nIG1hbmFnZW1lbnQgc3lzdGVtcyB3aGVyZSB0aGUgY29tbXVuaWNhdGlvbnMgYXJlIGFsbCBp bnRyYS1zaXRlLiZuYnNwOyBJZiBleHRlcm5hbCBjb21tdW5pY2F0aW9ucw0KIGFyZSBuZWVkZWQs IGFuIGFkZGl0aW9uYWwgSVNQLWJhc2VkIHByZWZpeCBjb3VsZCBiZSB1c2VkLiBUaG91Z2ggSSBh cHByZWNpYXRlIFVMQXMgY2FuIGJlIGEgY29udGVudGlvdXMgc3ViamVjdCwgc28gaWYgeW91IHdh bnQgdG8gcHVibGlzaCBxdWlja2x5IHlvdSBtaWdodCBjaG9vc2UgdG8gbm90IHNheSBhbnl0aGlu ZyBvbiB0aGUgc3ViamVjdCAoYnV0IGl0IHdpbGwgY29tZSB1cOKApiA6KTwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0 OiAxNHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9 IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5n OiBub25lIiBjbGFzcz0iIj5UaW08L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBt aW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9u ZSIgY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A14FE5692CFB4D7A9ED1D0710C3F2521jiscacuk_-- From nobody Thu Aug 18 17:13:19 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD86412D188; Thu, 18 Aug 2016 17:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 61JrbTHmlmdv; Thu, 18 Aug 2016 17:13:16 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 A9CC812D08F; Thu, 18 Aug 2016 17:13:15 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id w38so4463885qtb.0; Thu, 18 Aug 2016 17:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4ykFCSvdbiarYiNYoGnD4G5ftip+cjlf/qrRqIe4P6E=; b=meHUOqGHOcgV7x6tkvMJrUNFtdOgrUAXMNvtVclzj8+BzEXOLED8i1hVFxCi1jCGrC IjuMUtdl6ljImYWdSBcoW55SLSE4urTjGog/SERK7cgXU+glyBoQSD9kcH5y/kiJDAUa wu88JN/TM89k18lr3fgncarP9mbFEy5xWrHnnrG5plJyk9sXbo79Kfz6UCH4gxNtkCrw ZVnL7l/Jtgx3i1QLEewOF50BNHE2eHmqgrHPi7l/w55TMiJMde1nEM6+9QGuDZtHFlGE XfFzClGt//1v59Ic3wDoyloMUK2qqFuz9xsBaTOS7jrnimBHGPkL9/fgMHgavPN0MF3p sybQ== 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; bh=4ykFCSvdbiarYiNYoGnD4G5ftip+cjlf/qrRqIe4P6E=; b=Kqw0uDc4b77EBfSHuWCdJkSPv9i0iktCnCZe2HFLYYeZSETvj7YozFNgrzcNWmt55D 5ILIY7TKZxUiPtNU3HNK9zG/n+rCD+ZLVyvnxFYvNeO+s0XVVBJ8JS6veK7fgXsR6u+0 VinY2PFGct2A745drlj5XmLpihoVdJUZIJnIjI55eroK9PmAAqK3s9wYyPr9vfDAv56K Y0Rz5KqiBpc9TDhccQrgHrw9h+tm5nqmFL1TP9adAUMikA3EaXBINtxJHz7+kNzbMqh2 24jjmpqGkslobKD4v1k7Qzt2eK76WJHPdzGGvNvCnS4mcOYMnkq8n88svqyDI2LWskwM NE3A== X-Gm-Message-State: AEkoouuyge9OG3EETV7Nir6zlR5d4HTW7bC48dK2bu3ixzMUpzsjhnanFxR62hIvZZqCUH36JbzT0mPOLnm36A== X-Received: by 10.200.51.34 with SMTP id t31mr5850478qta.61.1471565594864; Thu, 18 Aug 2016 17:13:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.169.135 with HTTP; Thu, 18 Aug 2016 17:13:14 -0700 (PDT) In-Reply-To: <35cdd8616aac476e999c6fea48fb8eb4@IL-EXCH01.marvell.com> References: <8c1d352d1497485ca097257c44b5fe1e@IL-EXCH01.marvell.com> <35cdd8616aac476e999c6fea48fb8eb4@IL-EXCH01.marvell.com> From: Zhen Cao Date: Fri, 19 Aug 2016 08:13:14 +0800 Message-ID: To: Tal Mizrahi Content-Type: multipart/alternative; boundary=001a1135729e8bb17b053a6190cc Archived-At: Cc: "draft-ietf-tictoc-multi-path-synchronization@tools.ietf.org" , "suresh.krishnan@ericsson.com" , "int-ads@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] INT dir review of draft-ietf-tictoc-multi-path-synchronization-04 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 00:13:19 -0000 --001a1135729e8bb17b053a6190cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Tal, They look good to me. Many thanks, zhen On Thu, Aug 11, 2016 at 9:31 PM, Tal Mizrahi wrote: > Dear Zhen, > > Thanks for the detailed review. > > Please see my responses inline, and please let us know if there are any > further comments. > > Thanks, > Tal. > > > >From: Zhen Cao [mailto:zhencao.ietf@gmail.com] > >Sent: Thursday, August 11, 2016 12:25 PM > >To: int-dir@ietf.org; int-ads@ietf.org > >Cc: draft-ietf-tictoc-multi-path-synchronization@tools.ietf.org > >Subject: INT dir review of draft-ietf-tictoc-multi-path- > synchronization-04 > > > >I am an assigned INT directorate reviewer for this draft. These comments > >were written primarily for the benefit of the Internet Area Directors. > >Document editors and shepherds should treat these comments just like the= y > >would treat comments from any other IETF contributors and resolve them > >along with any other Last Call comments that have been received. For mor= e > >details of the INT directorate, see > >. > > > >Summary > > > >I do not see any strong reason to delay the publication of this document > as it > >is. I do have some questions/comments below for discussion. > > > > > >Comments: > >(I am not experts of NTP/PTP exchanges, but I worked on some MIF (multip= le > >interface, a concluding wg) technology for a while. So the > >comments./questions stem there) > > > >1. What's the impact of NAT on the MP-NTP/PTP exchanges. The packet fro= m > >the client will bear with an IP address that collude with some one else, > how > >does the server handle this solution? If this is relevant, I would like > to see > >some discussion in the document. > > [TM] Point well-taken. > We propose to add the following paragraph to Section 5: > > The use of Network Address Translation (NAT) may significantly reduce the > effectiveness of multi-path synchronization in some cases. For example, i= f > a master uses multiple IP addresses that are translated to a single IP > address, the path diversity is likely to be lower than in a network that > does not use NAT. Thus, path discovery should be used to identify the > possible paths between the master and slave. Path discovery is further > discussed in Section =E2=80=8E5.3. > > > > > > >2. What's the impact of the delay variance of multiple paths on the > combining > >algorithm? Should the server wait for a while before abandoning the > message > >from a certain path? Generally speaking, UDP traffic from multiple pat= hs > >have big variance. > > [TM] Yes, indeed the delay variation is a major factor in the combining > algorithm. > The current document briefly mentions the need for a combining algorithm > in Section 6, with a reference to other documents that discuss possible > combining algorithms. Indeed, these other documents make use of the delay > variation as one of the most important factors in the algorithm. > We believe the current text in Section 6 is sufficient, given that > combining algorithms are not within the scope of this document. > Please let us know if you believe otherwise. > > > > > >3. The default route on the host may block the transmission of traffic > along a > >certain IP address that is not within the default interface. This is > identified by > >RFC 6418. A well-known problem is that a multiple-interface host can on= ly > >send packets through the one with a better route metric. This may have > some > >impact to the operation of MP-NTP/PTP. Some discussion or pointer to th= e > >this problem would help implementer to save their digging time. > > [TM] Right. Thanks for pointing that out. We propose the following > paragraph: > > The concept of using multiple IP addresses or multiple interfaces is a > well-established concept that is being used today by various applications > and protocols, e.g., [MPTCP]. It should be noted that using multiple > interfaces introduces some challenges and issues, which were presented an= d > discussed in [RFC6418]. > > > > > >Thanks, > >Zhen > --001a1135729e8bb17b053a6190cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Tal,

They look good to me.=C2=A0<= /div>

Many thanks,
zhen=C2=A0

On Thu, Aug 11, 2016 at= 9:31 PM, Tal Mizrahi <talmi@marvell.com> wrote:
Dear Zhen,

Thanks for the detailed review.

Please see my responses inline, and please let us know if there are any fur= ther comments.

Thanks,
Tal.


>From: Zhen Cao [mailto:zhenca= o.ietf@gmail.com]
>Sent: Thursday, August 11, 2016 12:25 PM
>To: int-dir@ietf.o= rg; int-ads@ietf.org
>Cc: draft-ietf-tictoc-multi-path-synchronization@tools.ietf.or= g
>Subject: INT dir review of draft-ietf-tictoc-multi-path-syn= chronization-04
>
>I am an assigned INT directorate reviewer for this draft. These comment= s
>were written primarily for the benefit of the Internet Area Directors.<= br> >Document editors and shepherds should treat these comments just like th= ey
>would treat comments from any other IETF contributors and resolve them<= br> >along with any other Last Call comments that have been received. For mo= re
>details of the INT directorate, see
><http://www.ietf.org/iesg/directorate.html&= gt;.
>
>Summary
>
>I do not see any strong reason to delay the publication of this documen= t as it
>is.=C2=A0 I do have some questions/comments below for discussion.
>
>
>Comments:
>(I am not experts of NTP/PTP exchanges, but I worked on some MIF (multi= ple
>interface, a concluding wg) technology for a while. So the
>comments./questions stem there)
>
>1. What's the impact of NAT on the MP-NTP/PTP exchanges.=C2=A0 The = packet from
>the client will bear with an IP address that collude with some one else= , how
>does the server handle this solution?=C2=A0 If this is relevant, I woul= d like to see
>some discussion in the document.

[TM] Point well-taken.
We propose to add the following paragraph to Section 5:

The use of Network Address Translation (NAT) may significantly reduce the e= ffectiveness of multi-path synchronization in some cases. For example, if a= master uses multiple IP addresses that are translated to a single IP addre= ss, the path diversity is likely to be lower than in a network that does no= t use NAT. Thus, path discovery should be used to identify the possible pat= hs between the master and slave. Path discovery is further discussed in Sec= tion =E2=80=8E5.3.



>
>2. What's the impact of the delay variance of multiple paths on the= combining
>algorithm?=C2=A0 Should the server wait for a while before abandoning t= he message
>from a certain path? =C2=A0 Generally speaking, UDP traffic from multip= le paths
>have big variance.

[TM] Yes, indeed the delay variation is a major factor in the combin= ing algorithm.
The current document briefly mentions the need for a combining algorithm in= Section 6, with a reference to other documents that discuss possible combi= ning algorithms. Indeed, these other documents make use of the delay variat= ion as one of the most important factors in the algorithm.
We believe the current text in Section 6 is sufficient, given that combinin= g algorithms are not within the scope of this document.
Please let us know if you believe otherwise.


>
>3. The default route on the host may block the transmission of traffic = along a
>certain IP address that is not within the default interface.=C2=A0 This= is identified by
>RFC=C2=A06418.=C2=A0 A well-known problem is that a multiple-interface = host can only
>send packets through the one with a better route metric.=C2=A0 This may= have some
>impact to the operation of MP-NTP/PTP.=C2=A0 Some discussion or pointer= to the
>this problem would help implementer to save their digging time.

[TM] Right. Thanks for pointing that out. We propose the following p= aragraph:

The concept of using multiple IP addresses or multiple interfaces is a well= -established concept that is being used today by various applications and p= rotocols, e.g., [MPTCP]. It should be noted that using multiple interfaces = introduces some challenges and issues, which were presented and discussed i= n [RFC6418].


>
>Thanks,
>Zhen

--001a1135729e8bb17b053a6190cc-- From nobody Fri Aug 26 22:02:16 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B0B12B04A; Fri, 26 Aug 2016 22:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vKvOz55wPKww; Fri, 26 Aug 2016 22:02:13 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D953212D095; Fri, 26 Aug 2016 22:02:09 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id m60so129560347uam.3; Fri, 26 Aug 2016 22:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=AzCpwRhzc4yPdtwTM+UKAvIF7WsJmyJP1WXYEB4Kwb0=; b=P3s1Mf6lWZC+gHTZn+zR2pMXt/cMVxvryeRro0qLIgenwn209/a+REz8l4+uZYmob2 LUCr7ArkOaBnr1HJwbM/SUQc/VxxUNqIrRdnuJe5xjajORtN3my5xMpjp40QmzNfiN11 DDDZEDnNyF715RVfi79tqZDIDHB9ZZKpSfVIuHawoGb1GP53TJXepJo7Fq3wpolVurvy IUnUqSD7L1egSJXQknrWhoiFscMd7AASSte51oFfuW9zVji+QAmevS0PnCsTYL9ufDl5 1ssrrFr+UAYHy1LDDRhDNMWj2utFfqIEKMvBEpL6jLKvR18QgZoMuPVEabXpiQ+abNoy xd8Q== 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; bh=AzCpwRhzc4yPdtwTM+UKAvIF7WsJmyJP1WXYEB4Kwb0=; b=FLSyJOmDZ7DrlKTfY/1jJpsBwdEpkuOTjV3fysjf5rhX6fQoOft+Irbwcm0CSalmEe 3q7MSYpTmik/F3uutX8547iicFBMpo3DNgq40IulQP5YPavKn+DRxQOTPLRBK4LZfKMZ IxfrxILbdSMvO7X53NWwfkGLsE1mFz4/dWzSQyAZKccfHODQ8WYdT2x6dQdIJNmOyyJG z9O0p3eCYWHboJRw3hLYrdpUlq72TJo5XzPBi4p5Jq8XmJreEkcLZuydRPuQFUAR0Dgn XLdx6ugzX2dG4UFWEswEEbUDjZlmZKCBPb99nU+7Im8uX6kHqpZ+9K32rHM20IUtPZsb cb8Q== X-Gm-Message-State: AE9vXwNgGFTc1+OnsA59CWFlqDscfMa9bEUp6uUUmHB4yggRM9rGBahKaq3YOGXjOVUFs4jyVFTQfQOZQ91zHg== X-Received: by 10.176.3.242 with SMTP id 105mr4619471uau.112.1472274128984; Fri, 26 Aug 2016 22:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.85.21 with HTTP; Fri, 26 Aug 2016 22:01:53 -0700 (PDT) From: Donald Eastlake Date: Sat, 27 Aug 2016 01:01:53 -0400 Message-ID: To: int-dir@ietf.org, int-ads@ietf.org, draft-ietf-6lo-paging-dispatch.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Int-dir] INT area directorate review of draft-ietf-6lo-paging-dispatch X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 05:02:14 -0000 I am an assigned INT directorate reviewer for draft-ietf-6lo-paging-dispatch. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. This short draft is a fairly straightforward extension to the encoding of 6LoWPAN compression that effectively multiplies the code space for "DispatchType Filed" bytes by a bit less than a factor of 16. Due to the space constraints of 802.15.4 frames, 6LoWPAN encoding is into bytes and the draft specifies a block of 16 bytes values which set the context for the parsing of subsequent bytes until the next such context setting. It is backwards compatible as existing encoding is in context zero which is the default. the draft refers to these 16 contexts as Pages in the sense of pages of code values. There are also some special provisions for Page 1. After fixing the nits and possibly tweaking the IANA Considerations as below, I think this document is ready for publication. IANA Considerations: It seems odd to me to say that 15 additional registries should be created for Pages (contexts) 1 through 15 when 14 of those will initially be empty except perhaps that the last 16 values in each registry are the Page switch values.. I would have expanded the existing registry with a "Page" column and added a note about Page zero being the default and applying if no other Page has been set. But perhaps this is jus a matter of taste. Nits: Section 3, first line of last paragraph, "is is" -> "is". The nits checker complains about a few missing form feeds. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed Aug 31 00:50:14 2016 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5911312D958; Wed, 31 Aug 2016 00:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 QVXhBXf8tUVd; Wed, 31 Aug 2016 00:50:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 7A21312D907; Wed, 31 Aug 2016 00:50:11 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-57-57c68c31737e Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by (Symantec Mail Security) with SMTP id 22.7B.02493.03C86C75; Wed, 31 Aug 2016 09:50:09 +0200 (CEST) Received: from [131.160.126.239] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 09:50:07 +0200 To: Jean-Michel Combes , Tom Henderson , Terry Manderson References: <577FDD73.7060207@tomh.org> From: Gonzalo Camarillo Message-ID: <0aa05deb-4a10-5dfd-19bd-5cee4c51a5dd@ericsson.com> Date: Wed, 31 Aug 2016 10:50:07 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7nK5hz7Fwg8s7DSzaLu5jsmjdsYnJ ovHddkaLzwdPM1o8utLNYjGl9SSbRevRm6wWjXf/MFksn6HpwOkx5fdGVo+ds+6yexy+cJ/F Y8mSn0we364DxfZc0/D4cvkzWwB7FJdNSmpOZllqkb5dAlfGvc6rLAWfxCqmtLezNjCuFOhi 5OSQEDCRWDjrCEsXIxeHkMB6Rombe28wQjhrGSWOb9zFDlIlLBAmcfLKS0YQW0SgiVFi8i8x iKKtjBIXZ69hBXGYBW4xSjR0HALrYBOwkNhy6z7QXA4OXgF7iSMtgiBhFgFViU2NS5lBwqIC MRLr+xJAwrwCghInZz5hAbE5BQIlNk+awwpSwiygKbF+lz5ImFlAXmL72znMILaQgLbE8mct LBMYBWYh6Z6F0DELSccCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGRcHDLb6sdjAef Ox5iFOBgVOLhXXDyaLgQa2JZcWXuIUYJDmYlEd7nXcfChXhTEiurUovy44tKc1KLDzFKc7Ao ifP6v1QMFxJITyxJzU5NLUgtgskycXBKNTBGdM6Q67xy5fFF/fLdBwW64gW1TFxWhn3we/5r j1ZDiId40ZamolXOv/mO3Z+y/B//ga7whhlRtQl3JUo0Zx3Kkl8q9ZZzyQsFs1+Wy51dnTon TSvZlC8uvXfOszOHN3uejfibycr74cBJ1atLM2+X7o+Jddjne8VU/9zBi07XOZwkOSy9qjYq sRRnJBpqMRcVJwIAbxoMMIACAAA= Archived-At: Cc: "Bernie Volz \(volz\)" , int-ads@ietf.org, int-dir@ietf.org, "cjbc@it.uc3m.es" , draft-ietf-hip-rfc5206-bis@tools.ietf.org, Brian E Carpenter Subject: Re: [Int-dir] INT area directorate review for draft-ietf-hip-rfc5206-bis-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 07:50:13 -0000 Hi Terry, in his INT area review, Jean Michel asks for a security-area review of the document (see email below). The HIP documents have been reviewed by the security area several times in the past, but if you want them to have a fresh look at them, you should probably ask the security ADs to perform such a review as part of the IESG evaluation process. In any case, please get back to Tom (who is editing this draft) so that he understands who you want to proceed. Thanks, Gonzalo On 11/07/2016 6:07 PM, Jean-Michel Combes wrote: > Hi Tom, > > To clarify, my concern is about: > (1) CBA is still an individual draft > (2) CBA is applied as a "MUST" > > IMHO, only copying text inside the document is a bad idea: using such a > security mechanism for a proposed Standard track document needs deep > security reviews (e.g., Security Area at least). > > Best regards, > > JMC. > > > 2016-07-08 19:05 GMT+02:00 Tom Henderson >: > > On 07/05/2016 12:32 PM, Jean-Michel Combes wrote: > > I am an assigned INT directorate reviewer for > draft-ietf-hip-rfc5206-bis-12. These > comments were written primarily for the benefit of the Internet Area > Directors. Document editors and shepherd(s) should treat these > comments > just like they would treat comments from any other IETF contributors > and resolve them along with any other Last Call comments that > have been > received. For more details on the INT Directorate, see > http://www.ietf.org/iesg/directorate.html > > o Mobile IP(v6) v.s. HIP > At first, I prefer to be frank: I must admit that I am not > pro-HIP ... > HIP, IMHO, looks like Mobile IP(v6) (modulo some parameters) > with many > drawbacks ... > > Now, please, trust me, my review has been done with a _neutral_ > point of > view. > > o HIP Security > I didn't review HIP basis RFCs/drafts, meaning that my review is > based > on the fact that security reviews have already been done. > > o draft-ietf-hip-rfc5206-bis-12 > > My main concern is the use of an Informative RFC to provide > security to > the protocol described inside this document: > Section 5,6, "To prevent redirection-based flooding attacks, the > use of > a Credit-Based Authorization (CBA) approach MUST be used when a host > sends data to an UNVERIFIED locator." > > > Thank you for the review; is your concern that the CBA mechanism is > used altogether, or that the specification relies on an Informative > RFC (in which case it may be remedied by avoiding the normative > reference by copying into this draft)? > > - Tom > >