From nobody Wed Mar 1 17:25:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135C9129435; Wed, 1 Mar 2017 17:25:56 -0800 (PST) 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 Lys5nXfinaRL; Wed, 1 Mar 2017 17:25:55 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 D61221293FD; Wed, 1 Mar 2017 17:25:54 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id 67so661525pfg.2; Wed, 01 Mar 2017 17:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=skOJFG+Pfp/YYnoDX9IxXNWEcVOYJzYEVFP5+9d/7x8=; b=UVvxZuX3en2hGzhmfJ+LxlAIdWNkuzQdAmF/53h8LV9OZE38oq+Vh3Mn5pGF3XRX58 Df6IjIlgofxcedm/RCXhZiPt3qExzPe/vvbZhpJABmPoDK23ZD/vC5qd9apKv3ey5CK0 jGcvqe6pU6ZD6D63gkQpyLg4pLHPFBwMMyhtJ+pRzcGY13mBRVwfRb1ajNyZgsb+Z9yb qW/6m3XzpyR08e3WLsdRUjRrL+1dHurX5N7JHUUkY4s4mbV4dwvfe2EpuI8VDMnAdBjt BerpJGwWNsw7uBajDATukvyWqJ1t2jAuqdnLIofyqBvXa2atNR6V8zjsg+NTkXL+i0Eu X0zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=skOJFG+Pfp/YYnoDX9IxXNWEcVOYJzYEVFP5+9d/7x8=; b=dr8QPVSZCmS5ww4MbvoOvXgcGeEF3yuk3c+nQ2gYYRSrFlmUIoxjqnxaJuiVV9t2N8 f2qdter2a1xn4MXmGEY6KKpVtzz65U7uMfQRAIyU2dsmRC88v9vqu8NkjNzOV6F8S5l1 Kw3IfhnwHOmzTPvD+9lw38W/d01GwzlF2H4AkJ5HeZxCHZmVsdgSGSEYYwhyaJN2IjyR 0RYwqjZnlC8xSJ7aJaqhCtbMETNrQMSEivM2zJlL3i6TCVFAC9NBl2XRZNaz6r0Aem8Z tphrYjNzHDrxAXHR6z8Q6X3b52r6nYzAlcsFaExcFyKjK1/9M3cPg1fQD0NITYEUf37D Ckkg== X-Gm-Message-State: AMke39lGKUQYGeJ/xZZVsUEEWNcZvjF9JwE5qzy3aWawfQXFxHMamm3wm/Fvq/HnEdkP6w== X-Received: by 10.98.100.88 with SMTP id y85mr8492643pfb.112.1488417954281; Wed, 01 Mar 2017 17:25:54 -0800 (PST) Received: from ?IPv6:2406:e007:6663:1:28cc:dc4c:9703:6781? ([2406:e007:6663:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x2sm12848704pfb.49.2017.03.01.17.25.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 17:25:53 -0800 (PST) To: Charles Perkins References: <148701816643.25075.11558262573283847855.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 2 Mar 2017 14:25:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148701816643.25075.11558262573283847855.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, int-dir@ietf.org Subject: Re: [Anima] Review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 01:25:56 -0000 Hi Charlie, While reviewing your comments, I came upon one that I don't understand: > 3.5.6.1. Flooding > ... > A GRASP device with multiple link-layer interfaces (typically a > router) MUST support synchronization flooding on all interfaces. If > it receives a multicast Flood Synchronization message on a given > interface, it MUST relay it by re-issuing a Flood Synchronization > message on its other interfaces. The relayed message MUST have the > same Session ID as the incoming message and MUST be tagged with the > IP address of its original initiator. > > CEP: I am pretty sure this is a mistake. Why, please? Running code says it works fine. Regards Brian From nobody Fri Mar 3 13:07:29 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2631295DC; Fri, 3 Mar 2017 13:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 9hYOieXgacq3; Fri, 3 Mar 2017 13:07:23 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182AF12951B; Fri, 3 Mar 2017 13:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1488575243; bh=qY2ypmrSR8+tM6gHzqvc5+EoGPqdXQQlHLtn bIwO61M=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=ekGpaSR AnH5585fAZv8jAe7fsMh0DHh7gg4xblsNowFViSscexdIDGmhudLln2LG/dekqD5ixv 5oKNeBdTBX3UN61Hf5JhdWxjdgD/Fp8L+t0tODxWgBiCz8K8K72sag2PNOvWQY2H8He oHWE2uBwU5aChFjI2esPfcgHr+e4RBAgLxzn9rsdTm0y4FwFoqQWO4JJvff+6tCoImP natSjJ2uZAbb016qoC8KaJP4W/SLqVp+aUCxqJiaxQWT6CR+rGs2A4Z3eBIoemtVUQ4 3Tie5PZdnQlHTtkbBS3dkFodGd5LqkEZI9OFbluLXS+lcotn6NLzbAamxuurvvHqf9A == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=mB6M8gwjn4iejfwA5k69FSSKXwzFRAu9Hbz9e42MKXtyDkb6xscQx62XwZ19tio837otz6/PQcW4YksvNqNA+ma+1gpqL+WlRF97PcTabOxGzwDx6vUgrGOC0vcEetlHaMnUbpihQKwkrPa21gKSAPhFqhpT8lzeBPi0AueqVfFWlVxmbS+HqRnxnbUb4Upc7/GJGthQW/M2iQ3DsVjpCuaDapjCTfKJvokyYSWPgoir7d4u/csb0xArH/sBE8lMhzc27hGzkrbm5Q74Xtr2QTHlQMpkMq9pRn8OxUIzZd4DzhhV8xnVMiXqr/HrzNIliVhduozUu7JfVLT6GsMIHw==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cjuPx-0002vs-GQ; Fri, 03 Mar 2017 16:07:13 -0500 To: Brian E Carpenter References: <148701816643.25075.11558262573283847855.idtracker@ietfa.amsl.com> From: Charlie Perkins Message-ID: Date: Fri, 3 Mar 2017 13:07:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7feb9c0b582577f6bb7e7eeadd07e44d8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, int-dir@ietf.org Subject: Re: [Anima] Review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:07:24 -0000 Hello Brian, I probably should have said more. I just meant that such nodes ought to be allowed to have some network interfaces that do not participate in GRASP. Please excuse the unclear brevity of my remark. Regards, Charlie P. On 3/1/2017 5:25 PM, Brian E Carpenter wrote: > Hi Charlie, > > While reviewing your comments, I came upon one that I don't understand: > >> 3.5.6.1. Flooding >> ... >> A GRASP device with multiple link-layer interfaces (typically a >> router) MUST support synchronization flooding on all interfaces. If >> it receives a multicast Flood Synchronization message on a given >> interface, it MUST relay it by re-issuing a Flood Synchronization >> message on its other interfaces. The relayed message MUST have the >> same Session ID as the incoming message and MUST be tagged with the >> IP address of its original initiator. >> >> CEP: I am pretty sure this is a mistake. > Why, please? Running code says it works fine. > > Regards > Brian > From nobody Fri Mar 3 13:45:03 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC61812962C; Fri, 3 Mar 2017 13:44:57 -0800 (PST) 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 ElzZrWzcpZar; Fri, 3 Mar 2017 13:44:56 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 BD0CA1295C0; Fri, 3 Mar 2017 13:44:56 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id w189so36884073pfb.0; Fri, 03 Mar 2017 13:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=o2rad9wxOxr0tiwvQclz5GrWwbEQ+jjvhdl9vROEnbo=; b=G/iuSZh+V8pUW4WiZDuq1OlOdZDqTMzuOPQTVEEPMXRSQ7Ykf2+LhYW8bMGHPWdMp2 9+y2dvizCkXlg7oDGtlHyNPADR5iPpwovOxOi+uCAuxNq9J62b6+7Fvx54HUD2Ja+awM gHv+ZmW1DkCwDLVeu0Pep1GHoaYfDpq0xR6NdL2b4XCeeZzO/jtff1673Pv2SsvSptIc uWVEaUg+w/aTE26reX8Fh4o3V19hNEMrOODoBplTmNVTZ/yZeT5zIpef2hMqqC3yQw19 y4aygbunolbjNdPOeaWamc3A457J8liQhq5/th65C+tCgOtelcc86tJ3KvncCdsmyYWx TbxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=o2rad9wxOxr0tiwvQclz5GrWwbEQ+jjvhdl9vROEnbo=; b=uFn7DStttxsc8FcmiHkZjuywdPCoy8cacT58444Ri5AILIyqt5n0oFhA26K1F+pG+F 9vb8MJIvUCSK/5ovoPiHpWCVzkm/x19bLyhIC8bm8V+DNUAmiLtbcBQmC7uWBNH9lnpi zL9Rfz+PCIH3A2qAWJojmcE0GToV7rF48kJq1S1iFUPIILwBLmw+dzVBU39mAL4RVHPZ /lf2/DqzmBLNt3KqwXfLFYUBV0DxrqNZXAxS84ude7qEVIU4652TJ1GyacOsNzrH4YnV zV3KpGRHBff0lhgyfF1CsQhoc+3SdbdtgfROTwrBly6+avC4h1oQAD0bRsbhYol9N8gn w1Cw== X-Gm-Message-State: AMke39khFZ2KpfBqAmF4SFb9uVV46q7KlugKzyV+Jl67TGl+veEe3tQqIqijgQQQsjDbqg== X-Received: by 10.99.154.9 with SMTP id o9mr5972087pge.69.1488577496274; Fri, 03 Mar 2017 13:44:56 -0800 (PST) Received: from ?IPv6:2406:e007:4e9f:1:28cc:dc4c:9703:6781? ([2406:e007:4e9f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o125sm25155445pfb.109.2017.03.03.13.44.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 13:44:55 -0800 (PST) To: Charlie Perkins References: <148701816643.25075.11558262573283847855.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1ea285fd-fff2-373f-eae3-bbe95f56fe9b@gmail.com> Date: Sat, 4 Mar 2017 10:45:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, int-dir@ietf.org Subject: Re: [Anima] Review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:44:58 -0000 On 04/03/2017 10:07, Charlie Perkins wrote: > Hello Brian, > > I probably should have said more. I just meant that such nodes ought to > be allowed to have some network interfaces that do not participate in > GRASP. Please excuse the unclear brevity of my remark. No problem. This was a gap in the document as a whole. Easy to fix, fortunately. Thanks Brian > > Regards, > Charlie P. > > > On 3/1/2017 5:25 PM, Brian E Carpenter wrote: >> Hi Charlie, >> >> While reviewing your comments, I came upon one that I don't understand: >> >>> 3.5.6.1. Flooding >>> ... >>> A GRASP device with multiple link-layer interfaces (typically a >>> router) MUST support synchronization flooding on all interfaces. If >>> it receives a multicast Flood Synchronization message on a given >>> interface, it MUST relay it by re-issuing a Flood Synchronization >>> message on its other interfaces. The relayed message MUST have the >>> same Session ID as the incoming message and MUST be tagged with the >>> IP address of its original initiator. >>> >>> CEP: I am pretty sure this is a mistake. >> Why, please? Running code says it works fine. >> >> Regards >> Brian >> > > From nobody Fri Mar 3 16:02:04 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EBF129A59; Fri, 3 Mar 2017 15:55:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533703.15846.955000877921579753.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:37 -0800 Archived-At: Cc: anima@ietf.org, terry.manderson@icann.org Subject: [Anima] anima - Requested sessions have been scheduled for IETF 98 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:39 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (2:00:00) Monday, Afternoon Session I 1300-1500 Room Name: Zurich A size: 115 --------------------------------------------- anima Session 2 (1:30:00) Friday, Morning Session I 0900-1130 Room Name: Zurich A size: 115 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: homenet netconf dhc 6tisch nmrg Second Priority: 6man softwire roll 6lo supa v6ops Third Priority: cfrg saag intarea opsarea People who must be present: Toerless Eckert Sheng Jiang Terry Manderson Resources Requested: Meetecho support in room Special Requests: Please arrange the first session on Monday/Tuesday and the second session on Thursday. So the WG participatants could work and make progress between the two sessions. --------------------------------------------------------- From nobody Fri Mar 3 16:28:23 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9DC128AB0; Fri, 3 Mar 2017 16:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 xwqLs15Qg1Gu; Fri, 3 Mar 2017 16:28:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314A312706D; Fri, 3 Mar 2017 16:28:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EC80F2009E; Fri, 3 Mar 2017 19:50:42 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C4475636BB; Fri, 3 Mar 2017 19:28:16 -0500 (EST) From: Michael Richardson To: Charlie Perkins In-Reply-To: References: <148701816643.25075.11558262573283847855.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, int-dir@ietf.org Subject: Re: [Anima] Review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:28:19 -0000 --=-=-= Content-Type: text/plain Charlie Perkins wrote: > I probably should have said more. I just meant that such nodes ought to be > allowed to have some network interfaces that do not participate in GRASP. > Please excuse the unclear brevity of my remark. Yes. generally, GRASP will be running over virtual interfaces provided by the ACP. The ACP is basically an overlay mesh using IP (maybe GRE) over IPsec transport mode using RPL to do routing. (IPsec Tunnel mode itself doesn't interact with routing protocols well. I wish I had an acronym for this very common usage...) So, nodes will have physical interfaces on which the ACP runs, and then ACP secured virtual interfaces on which GRASP will run. And then the limited subset GRASP will be used on the physical interfaces to discover new possible adjacencies. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli6ChwACgkQgItw+93Q 3WWDfgf/UBMLcEiKdN4pqqCd65sHX4dZipeETast7R7Kj9+x3ZkgniSyTdu4DTBX 0u1LbIoi0zKwzsb2ttMk9AjUvhGlhRye65kJ4c2hYD5s1q2trbHWPyF3P7OmOuM2 ucYd6DjsOl7PLBas6ecZzmtiysqRS3XKnSgFl6XnEtZ5DFfeX5dkaNSP+mcmXoiw g3VG+Wa+fsygzeiKwWvjY9NG33O81cpDQAkj+3DrAIsWqFs7saky0MTxuBJPtNRd smOLiFxDq3ssVhPKDPO90lUkuAKWKUURFnmjrwonaqHf2/VfJv9h1q90sXFOX9r8 yho4paCnNgB7cLWzFN4V/gBWH4Un9g== =xiE3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 3 16:46:10 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004F4129405; Fri, 3 Mar 2017 16:46:06 -0800 (PST) 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 DXh7Abb0iF4m; Fri, 3 Mar 2017 16:46:05 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 02A96129438; Fri, 3 Mar 2017 16:46:05 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id x66so11170436pfb.1; Fri, 03 Mar 2017 16:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IRSZyynspz5NWbxsKk+fDHJ6NWOU9Ir1aoi7Wl0Vj70=; b=So4YpstvJOC4z1RCGvIHKLGQG06S2QFF6gNaB1kvFBI7f68saFJfc4hHCvspXuK33P slnvjGcpjqHbOVZPobJWXYPBTeEKLk8UXlAL6yzt8RcQWjWCEdwP93nEAmqubuWXpf4A 1o1wne1Sz47Ytutff9rtpkjcJSeV5/h0+Xb2HLiZ3l3nyWczPOVElPkbmymC3KCYauI2 x/qwcDlk4Pu3/Yb5MQIcy0ChxXnjvR9e3OCJDDGWXXPMI4Y14tCC8uw2mZ5yAcjL4Uu4 RjCpn8SU1tou30PCdK1S1gDsbCqSiQSWGaX0pLNnkyD7JxZyZ6nZIxuwaUZUmLnXuSFp 4Kpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IRSZyynspz5NWbxsKk+fDHJ6NWOU9Ir1aoi7Wl0Vj70=; b=mY2AkN7KH4BcXYUjM37idEZ9s4mIwcQcMH526y8wdSXUIiJhqbkPRIWZIr3wdQfH8P B1tAfhLeU4IrKfi15xIGYOR7SZ3GTBSlWuzQRyMDinmeH6iUFB/u0S5mEQ2F9VA/vBvZ hc9KfOBU+57D1YjbqYvRqqH5DLatfbCNgQPrj5bg5jCmnfFBUYP14IajTf2JXqrSFYvn Lwa5c/VwdypHJS2Yb6mJBgvBOCk0kGr9VzpwhMFBHu3QDrMKfHMzz/1l0V4uHQeyybhZ ufXnRZqj8wS0CcCAKz8cOmjZcahmAKl6p1/rQHCtKZ24tnjxVImNPzMkztdkEPYit167 0h3g== X-Gm-Message-State: AMke39mn4Gvi3U0t5fhpzcXW9rCuXRdByGX/Q8rDI6/stFq/1o87Hi1U5G853vy4uPVBdQ== X-Received: by 10.98.201.77 with SMTP id k74mr6906853pfg.74.1488588364563; Fri, 03 Mar 2017 16:46:04 -0800 (PST) Received: from ?IPv6:2406:e007:4e9f:1:28cc:dc4c:9703:6781? ([2406:e007:4e9f:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 129sm25649610pgj.59.2017.03.03.16.46.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 16:46:04 -0800 (PST) To: Michael Richardson , Charlie Perkins References: <148701816643.25075.11558262573283847855.idtracker@ietfa.amsl.com> <12999.1488587296@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 4 Mar 2017 13:46:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <12999.1488587296@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, int-dir@ietf.org Subject: Re: [Anima] Review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:46:06 -0000 On 04/03/2017 13:28, Michael Richardson wrote: > > Charlie Perkins wrote: > > I probably should have said more. I just meant that such nodes ought to be > > allowed to have some network interfaces that do not participate in GRASP. > > Please excuse the unclear brevity of my remark. > > Yes. generally, GRASP will be running over virtual interfaces provided by > the ACP. The ACP is basically an overlay mesh using IP (maybe GRE) over > IPsec transport mode using RPL to do routing. (IPsec Tunnel mode itself > doesn't interact with routing protocols well. I wish I had an acronym for > this very common usage...) > > So, nodes will have physical interfaces on which the ACP runs, and then > ACP secured virtual interfaces on which GRASP will run. And then the limited > subset GRASP will be used on the physical interfaces to discover new possible > adjacencies. Yes. Those details don't really belong in the protocol spec, but we will adjust the wording because Charlie has pointed out that it's currently wrong. Brian From nobody Sat Mar 4 18:51:08 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76256129501 for ; Sat, 4 Mar 2017 18:51:07 -0800 (PST) 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 2VM-OUphpMfw for ; Sat, 4 Mar 2017 18:51:06 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599B21294B5 for ; Sat, 4 Mar 2017 18:51:06 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id v190so9354962pfb.1 for ; Sat, 04 Mar 2017 18:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=irO4U6hKO3fgf3JCfa8OiOfDI0+UMrVOCpiI5vh8IqI=; b=OZB9h5wd2X0smnDMSnqaVCXxXj6xuYVeoyAeFUTy7ESa/JqKwvI39ld/F1jtGkSKlz gjZqlcP5KrAYdB8xJggHxhvDS/yTN8lK/qBxePULMNWn5Dapj0X1Z44Rvt1L5d9FKawJ 3Wz9nSkfzwzrAfF8EvJXYNzAZxdBCpx/lFcvwXdggSArPIbxIIxWVPRQse+SvjUWkd5y J2HHgkIMuyLEJwwYA71gQ07/SuQYDD7rNREJz6HL5Y8PNR2VDtZ9r36LhfnXGlV5dhuA 76N5GKrKsD5rZtR9CbabX5iVM1PMa2mBkOK9NJAZufMzX/JIVjD/xAlGUh7xJy+WPWBh QSGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=irO4U6hKO3fgf3JCfa8OiOfDI0+UMrVOCpiI5vh8IqI=; b=Ny1SQ2xzs0pmlfW146orDYp+pIAmNwzAWEdp4FKWRoSmlYH2vS1WSiS/By4ZbsHGyb u2oXqe7wThAfZ1dCPYeKSY837xHZOccxD20vcxQIaw1KBNTVgzhJAkfbC71Tmvjw73l5 rIbeteVc6kUafQ2fg2+kR7lYdc1NKRXU2hX9hYHiUtmbeC0dacjbkZ5bq/DNcJ6Jvdea gz1YuFw2mgjiXiCh8ZnpV8g9bB16Rqn3a8DL756eFU6i6P/Rbo/B3MWmCGoz8rU78Ksj hYvRKoLwzAWaWxkvnOBC1uPXrz0qrqVD8/flyrMonAsnbkuSlX2LvTVeESdiPZ+fULR/ 4OKw== X-Gm-Message-State: AMke39lT0oqVeYgOfDin1Bi2Fzav/lD74DLMlsqdMuv9/V19swESYa8uqYeLelONGfKvzg== X-Received: by 10.98.63.24 with SMTP id m24mr12821614pfa.143.1488682265784; Sat, 04 Mar 2017 18:51:05 -0800 (PST) Received: from ?IPv6:2406:e007:7204:1:28cc:dc4c:9703:6781? ([2406:e007:7204:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u69sm11362749pfg.121.2017.03.04.18.51.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 18:51:05 -0800 (PST) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <80dbd044-6468-1e08-88a5-80ea0481a5e9@gmail.com> Date: Sun, 5 Mar 2017 15:51:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Questions open after Last Call review of GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 02:51:07 -0000 Hi, We got two excellent reviews of draft-ietf-anima-grasp-09 from Joel Halpern and Charlie Perkins. In fact the WG owes Charlie a big round of applause for the thoroughness of his review. Of course, the authors will fix all the issues that are mistakes, omissions, or lack of clarity. We will get a -10 draft out before the deadline, which we hope people can check before the IETF. There are three larger issues where WG or WG Chair or AD input is needed: 1. Normative dependency on a draft. We use CDDL, which is still far from being a published standards track RFC (draft-greevenbosch-appsawg-cbor-cddl). This could hold up the GRASP RFC indefinitely. Proposed resolution: add an appendix specifying only the subset of CDDL we need. This has already been drafted so is quite feasible to do quickly. - Split the document? [Charlie Perkins] "parts of the document seem more philosophical than prescriptive... It should be considered to break the document into a Requirements document and a more rigorously defined protocol solution document." Proposed resolution: writing a separate requirements document was essentially excluded when the WG was chartered. Unless the WG and AD want to backtrack on that, the proposed resolution is to *not* do this. Of course, all the specific review comments about non-rigorous text will be actioned. - Clarify security [Charlie Perkins] "In some places, ACP seems to be mandated, and in other places that is relaxed to mean "a sufficient security mechanism". It would be better to identify the security requirements, and put them unmistakably in the Security Considerations section, which deserves to have teeth." (and various detailed comments in the text) Of course we will deal with the detailed comments and fix the inconsistencies. The larger issue is whether we should move most of the security discussion to the Security Considerations section. Speaking only for myself, I think it would be a mistake, because at the moment it seems to me that the security issues are mentioned where they most logically fit. Proposed resolution: TBD Brian (as co-editor of the draft) From nobody Mon Mar 6 13:23:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5A5129A29 for ; Mon, 6 Mar 2017 13:23:50 -0800 (PST) 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 eOD_9VCYkT-l for ; Mon, 6 Mar 2017 13:23:49 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B45129A2F for ; Mon, 6 Mar 2017 13:23:47 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id j5so65421210pfb.2 for ; Mon, 06 Mar 2017 13:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=x3pbfQiw9pxX2oERKIFlbq2dHTiaG+nHQYPe4U52y1c=; b=IPT64sgR2BqyfDDtGTxgG5L5OGqT0t7Vj0QxJIKy3iViugn3btfWUReW0gUdbyzoop wvrBGEyebAoIKWP5zKj9yq0EfxHGDCcLgtYmzSPcTRHUdIKQv0H3/IH1+ICYpC5ZxWNp aD6QVd/tuFEr9jHfYjsZ2S68wqxGY+YVkh2kLAsauvr2eVunTPOsiT9T0BL5rAJt30Vd 8I3MUjqCMNnwfTDufeR6PqZKs/FCnZlbN44iljfM+LG+ggxvCAIdN8qrneh+Y9Z4N0Da kQaeCcSQ33/iBpFxn7IbsI6hSvVguH+BNOhkilOdtH9NdOyD9cRtV4FQvUWmGwNohc4f 7NrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=x3pbfQiw9pxX2oERKIFlbq2dHTiaG+nHQYPe4U52y1c=; b=NRsb4xtMDl4sMVqieRsi5L3jHkhmQLIqEON0ijKWc+kwJZND9++pwiHhxZr8ykxOEP 1sSzsH8f1fydlHsTe/2Lr9TaPiOvtPtszzQM7aiV2dG8046CGNDS6onr+kTKRjt4JWWi i5/Rtecx/Hklxk7W+N05OOBaWfhqH4ocJgsQ8WdB7wcVnzB7am+e2f/GXHWAbrMZsJqo Hg4uPPY2651VIk7MyuocGbGL3kobvBa3ltCTslqI4SXDbeYtQhorOh34JEXM8DP4Y2VG tsmscPfa9Nk/MEUW6i+zdZVWXBrEZTUACCv6qgHEYXWLMZDNeGx87e1dl4nQ+iEZ3IXV M6cA== X-Gm-Message-State: AMke39ljRl4OjHC4xoNjYL60rMsrPyg+Rfmvp6DHTsyg+hIEgeANPn/8s5cROhWW4AL4KQ== X-Received: by 10.99.211.21 with SMTP id b21mr23001298pgg.166.1488835426201; Mon, 06 Mar 2017 13:23:46 -0800 (PST) Received: from [130.216.38.63] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.63]) by smtp.gmail.com with ESMTPSA id k184sm41627268pgc.23.2017.03.06.13.23.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 13:23:45 -0800 (PST) To: Anima WG References: <80dbd044-6468-1e08-88a5-80ea0481a5e9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 7 Mar 2017 10:23:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <80dbd044-6468-1e08-88a5-80ea0481a5e9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Questions open after Last Call review of GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 21:23:50 -0000 Replying to myself, I have added a note to the first issue. On 05/03/2017 15:51, Brian E Carpenter wrote: > Hi, > > We got two excellent reviews of draft-ietf-anima-grasp-09 > from Joel Halpern and Charlie Perkins. In fact the WG owes > Charlie a big round of applause for the thoroughness of his > review. > > Of course, the authors will fix all the issues that are > mistakes, omissions, or lack of clarity. We will get > a -10 draft out before the deadline, which we hope people > can check before the IETF. > > There are three larger issues where WG or WG Chair or AD > input is needed: > > 1. Normative dependency on a draft. > > We use CDDL, which is still far from being a published > standards track RFC (draft-greevenbosch-appsawg-cbor-cddl). > This could hold up the GRASP RFC indefinitely. > > Proposed resolution: add an appendix specifying only > the subset of CDDL we need. This has already been drafted > so is quite feasible to do quickly. Note: since we have other normative dependencies on drafts, we could delay this change until later. > > - Split the document? [Charlie Perkins] > > "parts of the document seem more philosophical than > prescriptive... It should be considered to break the document > into a Requirements document and a more rigorously defined > protocol solution document." > > Proposed resolution: writing a separate requirements document > was essentially excluded when the WG was chartered. Unless the > WG and AD want to backtrack on that, the proposed resolution > is to *not* do this. Of course, all the specific review comments > about non-rigorous text will be actioned. > > - Clarify security [Charlie Perkins] > > "In some > places, ACP seems to be mandated, and in other places that is relaxed > to mean "a sufficient security mechanism". It would be better to > identify the security requirements, and put them unmistakably in the > Security Considerations section, which deserves to have teeth." > > (and various detailed comments in the text) > > Of course we will deal with the detailed comments and fix the > inconsistencies. The larger issue is whether we should move most > of the security discussion to the Security Considerations section. > > Speaking only for myself, I think it would be a mistake, because > at the moment it seems to me that the security issues are > mentioned where they most logically fit. > > Proposed resolution: TBD > > Brian (as co-editor of the draft) > From nobody Mon Mar 6 14:00:39 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934B31294CF for ; Mon, 6 Mar 2017 14:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 z7ZFUNp1m-ZU for ; Mon, 6 Mar 2017 14:00:36 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BE71296C0 for ; Mon, 6 Mar 2017 14:00:35 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3095658C54B; Mon, 6 Mar 2017 23:00:31 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 13734B0B930; Mon, 6 Mar 2017 23:00:30 +0100 (CET) Date: Mon, 6 Mar 2017 23:00:30 +0100 From: Toerless Eckert To: Michael Richardson Message-ID: <20170306220030.GB7471@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: anima@ietf.org, Michael.H.Behringer@gmail.com Subject: [Anima] MichaelR: section 5.1.1 question (draft-ietf-anima-autonomic-control-plane-05) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:00:37 -0000 Michael: I remember from Berlin that you wanted to suggest a better format/encoding for the AN domain certificate to indicate a pledge/devices ACP address. I have not seen a followup re. this item (i apologize in case i have overlooked an email re. this). If you still would like to see this improved on, i would appreciate if you could try to do this before the dealine (friday) so we can incooperate it. Cheers Toerless From nobody Tue Mar 7 18:43:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C585120724; Tue, 7 Mar 2017 18:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 853dDnMtxe1j; Tue, 7 Mar 2017 18:43:09 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 96F7412941C; Tue, 7 Mar 2017 18:43:09 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id g138so18819207itb.0; Tue, 07 Mar 2017 18:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xiFsOjdhKt4k/MeXHS5s5yhJ0hGCinPAWX7oUmvCwAY=; b=jp6uix6jFHhApv8P2skmKcBVwWoMHNBv1iVYNYSKQh9H+60osWoL4qkuiK8Qk6nNuo 10UwcYD+XW7EuQtSuBhnmVa/vA7sidWmuRloh9svfo2NVJOc1HxinzhRt3aaYpp7f51h +b2DsmyUf9jT+8zFzrReSzZlpCRF3UaIvCzsQBSLKPyyEcKNJNUJM8thazWAyN/ZGK9P kB2V7pTycaw+MqtCRb95hXqS0jDrxW1Z8x2oZjZKn7+S3dnrZ8yrT69hHSpk/WsPfvH/ L7cuc3U/vfigVVO+BNuIR3sjijzfQXx28aTVdTr1JlwC8Iy2IhuVyixzjQH25kEDEwKc 3o0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=xiFsOjdhKt4k/MeXHS5s5yhJ0hGCinPAWX7oUmvCwAY=; b=QMVhtJRY9nH8fN4OXOk50rN0UwuMxDtgXYu06d4TIB/Fuj/8ZFYWTMoajhVcHJf4gA 04sIyqOnVahFAG6nGFX+MLFJzeG2QtEZPS1pH1xroRZKNb6B4dO816eWD2UcrHcNGf88 tl3piU2iVa16VCpabviVJarN0FWiI6u+US5LSSkn+4mnUYd8W2Qsz0vrBZSrQFFs5h// MZzkUmVAhzJBHzRfwZMp0YpXAIzZRbJcWWfIrT9CqvOriPZcNWzTBnd/pKXf9VUtcQjr b6RSe0H/VajYf4IJnjmBdGys5aMZXHyQOtUL6nWDxdQS/jffimM7EMR75pkpB2L3OH+W I8VA== X-Gm-Message-State: AMke39lfONzUiojAiEkVPeI+xR3SJVOv/AVWrN2P2bzd0aIF985MLYnjIHiZQVYKJNhKXIteFt6QU0SoPwr7qQ== X-Received: by 10.36.98.65 with SMTP id d62mr23499146itc.119.1488940988530; Tue, 07 Mar 2017 18:43:08 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Tue, 7 Mar 2017 18:43:07 -0800 (PST) From: Barry Leiba Date: Tue, 7 Mar 2017 21:43:07 -0500 X-Google-Sender-Auth: c8S4HM-R6DPpkJOORuVjiiHhZOY Message-ID: To: draft-ietf-anima-grasp.all@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IESG , anima@ietf.org, "secdir@ietf.org" Subject: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 02:43:11 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. First, I'm sorry this review is a few days late, and I hope that isn't a problem. Second, the document is "ready with issues". Most of the comments below are minor, and editorial. The three that are substantive are: 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5.2.1. 2. The UTF-8 issues in Section 3.10.1. 3. Guidance for the Designated Expert in Section 7. These should all be easy to resolve. =E2=80=94 Section 1 =E2=80=94 A reference model for autonomic networking on this basis is given in [I-D.ietf-anima-reference-model]. The reader should consult this document to understand how various autonomic components fit together. Even though that document is an informative reference, I find it odd that the draft that helps us understand how this all fits together. . . is an expired draft. It makes me wonder how well baked things are. =E2=80=94 Section 3.1 =E2=80=94 The following additional terms are used throughout this document: o Autonomic Device: identical to Autonomic Node. It=E2=80=99s not a big point, but: Why? Why is it important or useful to specifically define a *new* term in this document that has the same meaning as a similar term that=E2=80=99s already defined? And, actually, now that I check, I see that =E2=80=9Cautonomic devices=E2= =80=9D is used in exactly one place, in the Abstract. I suggest changing the term in the abstract to =E2=80=9Cautonomic nodes=E2=80=9D, and removing thi= s definition. =E2=80=94 Section 3.2 =E2=80=94 Because GRASP needs to work whatever happens, especially during bootstrapping and during fault conditions, it is essential that every implementation is as robust as possible. There seems to be a missing word, or some such; I can=E2=80=99t parse =E2= =80=9CGRASP needs to work whatever happens=E2=80=9D. And picky grammatical nit: subjunctive mood is needed with =E2=80=9Cessential=E2=80=9D, so it should b= e =E2=80=9Cit is essential that every implementation be as robust as possible.=E2=80=9D =E2=80=94 Section 3.3 =E2=80=94 GRASP provides mechanisms to guarantee convergence (or failure) in a small number of steps, i.e. a timeout and a maximum number of iterations. Another nit. This is an outstanding example of why I don=E2=80=99t like to = use =E2=80=9Ci.e.=E2=80=9D: in this case, it leaves me wondering whether that= =E2=80=99s really an exhaustive list, or whether you meant =E2=80=9Ce.g.=E2=80=9D. And, to me, = it reads awkwardly anyway. I suggest one of these alternatives (the sorts that can pretty much always stand in for the overused and unnecessary =E2=80=9Ci.e.=E2=80=9D): NEW-1 GRASP provides two mechanisms to guarantee convergence (or failure) in a small number of steps: a timeout and a maximum number of iterations. NEW-2 GRASP provides a timeout and a maximum number of iterations, which together guarantee convergence (or failure) in a small number of steps. =E2=80=94 Section 3.5.1 =E2=80=94 If there is no ACP, the protocol MUST use another form of strong authentication and SHOULD use a form of strong encryption. See Section 3.5.2.1 for further discussion. Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? Looking ahead to 3.5.2.1, how could it be considered safe to use a network configuration protocol across administrative boundaries without encryption? =E2=80=94 Section 3.5.2.2 =E2=80=94 A responder SHOULD NOT send a Discovery Response message unless it cannot be avoided. Any clue about why it might be possible that it =E2=80=9Ccannot be avoided= =E2=80=9D? =E2=80=94 Section 3.5.2.3 =E2=80=94 o Any type of GRASP message MAY be sent. This doesn=E2=80=99t feel like a =E2=80=9CMAY=E2=80=9D to me. You=E2=80=99= re not saying that there=E2=80=99s a protocol choice here, and how to handle it is optional and up to the implementation. You=E2=80=99re saying that all types of GRASP messages are permitted when you=E2=80=99re using a SONN instance. So maybe, =E2=80=9CAl= l types of GRASP messages are permitted.=E2=80=9D =E2=80=94 Section 3.10.1 =E2=80=94 All objectives are identified by a unique name which is a case- sensitive UTF-8 string. Actually, =E2=80=9Ccase-sensitive=E2=80=9D isn=E2=80=99t a sufficient descr= iptor for UTF-8, as there are issues of canonicalization and normalization, and the fact that languages differ in whether =E2=80=9Ccase=E2=80=9D makes sense at all.= This would be a bigger issue if you wanted case insensitivity, but as it is I think the fix is easy: you should just say that the name is a UTF-8 string that is compared byte by byte. This will have the effect of being case sensitive when that makes sense, and will also eliminate the issues of canonicalization and normalization: different ways of representing characters such as =E2=80=9C=C3=A4=E2=80=9D and =E2=80=9C=C3= =B4=E2=80=9D and =E2=80=9C=C3=A9=E2=80=9D will compare as different, and as these are protocol elements and not user strings, that should be fine. The other question is whether there are any restrictions on what Unicode characters can be represented. You make the colon a special character but give no other restrictions, so an objective name could include space characters (and various related Unicode characters such as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), control characters (FORM FEED, CARRIAGE RETURN, and the like), characters from every character set and language including Cuneiform and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO. If that=E2=80=99s all OK, then that=E2=80=99s fine (and maybe it is, as, again= , this is a protocol element, not a user string). I just want to make sure you thought about it. =E2=80=94 Section 7 =E2=80=94 The creation of the Specification Required registry for the Objective Names Table needs to specify guidance for the Designated Expert (see draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5). It doesn=E2=80=99t have to be a lot, but it needs to be clear for future DEs who might not have been involved with developing this document what they need to consider as they review registration requests. Why might they push back on a registration request? Should they, for example, allow registration requests for two different Objective Names of =E2=80=9Cfrobozz= =E2=80=9D and =E2=80=9CFrobozz=E2=80=9D? What sort of documentation is sufficient fo= r a registration (is =E2=80=9Cenough that you think implementations can be writ= ten from it=E2=80=9D good enough, or are there specific things that the documentation ought to contain)? --=20 Barry From nobody Tue Mar 7 19:44:28 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1013C12948E; Tue, 7 Mar 2017 19:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CNK0IbLTnceM; Tue, 7 Mar 2017 19:44:21 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 41D0A129410; Tue, 7 Mar 2017 19:44:21 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 25so2006636pgy.3; Tue, 07 Mar 2017 19:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=10Qt2TLB3kVT4hwHF99Q42gLVvhvBpiYwCiV+lvtzvk=; b=JAposnM64mgS6D/8q7eLmsEqAm/JWja+0qKHSGCK+GXDBvgavP179kFRsfCwn0xlsG KQuBTO3Uyl6BiWNEJVWawInJQgRkA0uN2avzodO8I+pXVtjMI5BSU0DoIgaWKIwkqffc 5gDy05dT4V7FWRKffHrPpa+j3lndd6+jhfZCiVWpqK0WaHJBZQUrgj53nBq+OIDomWxi 9moW4AC0b1GwRcA+gsQE2iwwZxxGC5OKUqacOLUDBucJmXDAOGDXU0KsgwtYOOLJoGZh 4a0t/IFGIDfPNDk8yruOY/h058od0x19GNs2oobxtivssyZqy3xP1X7BewtKsEfDS8Vs //wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=10Qt2TLB3kVT4hwHF99Q42gLVvhvBpiYwCiV+lvtzvk=; b=gZCZidCYqUpZbNcBcp78UAi2rtPwF4ipgngatRKw2Q0kL8kgDYeVj0TPsGllkjBn4u vzQ874ObFB39GLi0lqZ+XNawkqCuSzzcpls+oe3h5G7MRzAJVQxKfcySy5yA1+Eo+6v8 DUm5F5//SW+zPwFamroPVV+f8jt2rH7UZyiZytwYfqxdJSnmsMS6sGHCT5FjIzEXUGOF EyZXqdQTK2pMjb36I6wI+5ZD3kmcGMvMf0HRCXpQJ1FofrlxkPEDYYValCe+MuEhGS7U UD9kGdwlUBmdlEh9ZZHDc2wFEhFA2W7/cztqVeXzfg9Cf5wdsv8zO3othOA8eUJz/wqU oAdA== X-Gm-Message-State: AMke39lj8EIcBezG8Q5QdoXVqdgEPLdGfh5oBZmL3qeUOyYDqWW2Wzi0URxTGLSFCchDGA== X-Received: by 10.99.233.17 with SMTP id i17mr4502541pgh.76.1488944660565; Tue, 07 Mar 2017 19:44:20 -0800 (PST) Received: from ?IPv6:2406:e007:77b4:1:28cc:dc4c:9703:6781? ([2406:e007:77b4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 185sm2442076pfg.13.2017.03.07.19.44.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 19:44:20 -0800 (PST) To: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> Date: Wed, 8 Mar 2017 16:44:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:44:23 -0000 Thanks Barry. Good comments, but we have to get a new draft out before the deadline, so I'm not sure these will all make it in until the one after. Regards Brian On 08/03/2017 15:43, Barry Leiba wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > First, I'm sorry this review is a few days late, and I hope that isn't > a problem. >=20 > Second, the document is "ready with issues". Most of the comments > below are minor, and editorial. The three that are substantive are: >=20 > 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5.= 2.1. >=20 > 2. The UTF-8 issues in Section 3.10.1. >=20 > 3. Guidance for the Designated Expert in Section 7. >=20 > These should all be easy to resolve. >=20 > =E2=80=94 Section 1 =E2=80=94 >=20 > A reference model > for autonomic networking on this basis is given in > [I-D.ietf-anima-reference-model]. The reader should consult this > document to understand how various autonomic components fit together= =2E >=20 > Even though that document is an informative reference, I find it odd > that the draft that helps us understand how this all fits together. . > . is an expired draft. It makes me wonder how well baked things are. >=20 > =E2=80=94 Section 3.1 =E2=80=94 >=20 > The following additional terms are used throughout this document: >=20 > o Autonomic Device: identical to Autonomic Node. >=20 > It=E2=80=99s not a big point, but: Why? Why is it important or useful = to > specifically define a *new* term in this document that has the same > meaning as a similar term that=E2=80=99s already defined? >=20 > And, actually, now that I check, I see that =E2=80=9Cautonomic devices=E2= =80=9D is > used in exactly one place, in the Abstract. I suggest changing the > term in the abstract to =E2=80=9Cautonomic nodes=E2=80=9D, and removing= this > definition. >=20 > =E2=80=94 Section 3.2 =E2=80=94 >=20 > Because GRASP needs to work whatever happens, especially during > bootstrapping and during fault conditions, it is essential that ever= y > implementation is as robust as possible. >=20 > There seems to be a missing word, or some such; I can=E2=80=99t parse =E2= =80=9CGRASP > needs to work whatever happens=E2=80=9D. And picky grammatical nit: > subjunctive mood is needed with =E2=80=9Cessential=E2=80=9D, so it shou= ld be =E2=80=9Cit is > essential that every implementation be as robust as possible.=E2=80=9D >=20 > =E2=80=94 Section 3.3 =E2=80=94 >=20 > GRASP > provides mechanisms to guarantee convergence (or failure) in a > small number of steps, i.e. a timeout and a maximum number of > iterations. >=20 > Another nit. This is an outstanding example of why I don=E2=80=99t like= to use > =E2=80=9Ci.e.=E2=80=9D: in this case, it leaves me wondering whether th= at=E2=80=99s really an > exhaustive list, or whether you meant =E2=80=9Ce.g.=E2=80=9D. And, to = me, it reads > awkwardly anyway. I suggest one of these alternatives (the sorts that > can pretty much always stand in for the overused and unnecessary > =E2=80=9Ci.e.=E2=80=9D): >=20 > NEW-1 > GRASP > provides two mechanisms to guarantee convergence (or failure) > in a small number of steps: a timeout and a maximum number of > iterations. >=20 > NEW-2 > GRASP > provides a timeout and a maximum number of iterations, > which together guarantee convergence (or failure) in a > small number of steps. >=20 > =E2=80=94 Section 3.5.1 =E2=80=94 >=20 > If there is no ACP, the protocol MUST use another form of strong > authentication and SHOULD use a form of strong encryption. See > Section 3.5.2.1 for further discussion. >=20 > Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? > Looking ahead to 3.5.2.1, how could it be considered safe to use a > network configuration protocol across administrative boundaries > without encryption? >=20 > =E2=80=94 Section 3.5.2.2 =E2=80=94 >=20 > A responder > SHOULD NOT send a Discovery Response message unless it cannot be > avoided. >=20 > Any clue about why it might be possible that it =E2=80=9Ccannot be avoi= ded=E2=80=9D? >=20 > =E2=80=94 Section 3.5.2.3 =E2=80=94 >=20 > o Any type of GRASP message MAY be sent. >=20 > This doesn=E2=80=99t feel like a =E2=80=9CMAY=E2=80=9D to me. You=E2=80= =99re not saying that there=E2=80=99s > a protocol choice here, and how to handle it is optional and up to the > implementation. You=E2=80=99re saying that all types of GRASP messages= are > permitted when you=E2=80=99re using a SONN instance. So maybe, =E2=80=9C= All types of > GRASP messages are permitted.=E2=80=9D >=20 > =E2=80=94 Section 3.10.1 =E2=80=94 >=20 > All objectives are identified by a unique name which is a case- > sensitive UTF-8 string. >=20 > Actually, =E2=80=9Ccase-sensitive=E2=80=9D isn=E2=80=99t a sufficient d= escriptor for UTF-8, as > there are issues of canonicalization and normalization, and the fact > that languages differ in whether =E2=80=9Ccase=E2=80=9D makes sense at = all. This > would be a bigger issue if you wanted case insensitivity, but as it is > I think the fix is easy: you should just say that the name is a UTF-8 > string that is compared byte by byte. This will have the effect of > being case sensitive when that makes sense, and will also eliminate > the issues of canonicalization and normalization: different ways of > representing characters such as =E2=80=9C=C3=A4=E2=80=9D and =E2=80=9C=C3= =B4=E2=80=9D and =E2=80=9C=C3=A9=E2=80=9D will compare as > different, and as these are protocol elements and not user strings, > that should be fine. >=20 > The other question is whether there are any restrictions on what > Unicode characters can be represented. You make the colon a special > character but give no other restrictions, so an objective name could > include space characters (and various related Unicode characters such > as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), > control characters (FORM FEED, CARRIAGE RETURN, and the like), > characters from every character set and language including Cuneiform > and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL > SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO. If > that=E2=80=99s all OK, then that=E2=80=99s fine (and maybe it is, as, a= gain, this is a > protocol element, not a user string). I just want to make sure you > thought about it. >=20 > =E2=80=94 Section 7 =E2=80=94 >=20 > The creation of the Specification Required registry for the Objective > Names Table needs to specify guidance for the Designated Expert (see > draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5). It doesn=E2=80= =99t > have to be a lot, but it needs to be clear for future DEs who might > not have been involved with developing this document what they need to > consider as they review registration requests. Why might they push > back on a registration request? Should they, for example, allow > registration requests for two different Objective Names of =E2=80=9Cfro= bozz=E2=80=9D > and =E2=80=9CFrobozz=E2=80=9D? What sort of documentation is sufficien= t for a > registration (is =E2=80=9Cenough that you think implementations can be = written > from it=E2=80=9D good enough, or are there specific things that the > documentation ought to contain)? >=20 From nobody Tue Mar 7 20:29:25 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3E128BA2; Tue, 7 Mar 2017 20:29:25 -0800 (PST) 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 gRquJqhhWV44; Tue, 7 Mar 2017 20:29:23 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 C7AFE12706D; Tue, 7 Mar 2017 20:29:23 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id j5so2329993pfb.3; Tue, 07 Mar 2017 20:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HqPOzg55qjp4ZzWG208uCxfeqRyjXmy0tNJVWMH4IOk=; b=BKdjQuU8hxJiZvLKFG3RfS1UO9oaFeGRBfag29JNIQlSHhmj3wRj8N41Iwtg+lpfqJ d+MMV4dCFuM26DSbDOjDy0L2cncG1NbbzivdaQxxCcazZx2VEfB3IgKDKB27OZNz1azA oydldAU118sXGK1mt/DICq1euVOIpZtiy8eqQf8HSiH/lwD/GK9nHSxJeYA2Y5mALeSy NKTu8NAzVs0gngrUpcWgOKxnT9w18EcGEePZN5M+ez+5nNLbD6bMR/f2C2YOBCBeu8Hi +QgXR7kF+7yHm2wT4nAVB3jdoHRY11L3XH/1O6ANd9xBgswaJl9CinW59SuaglVkEOpO ezIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=HqPOzg55qjp4ZzWG208uCxfeqRyjXmy0tNJVWMH4IOk=; b=T1AVEmW6Td0rPepvFAhYYhdh4fjx1e7sAIICSR/804kb7c2ng6kygTYWTq1SMTUtth TzpFCV5ifJoSN3RPfEeqWXNIreeiYggE1Nl0jB+P5cZJUYeET/4KKCi0dJR22oUxs2hv BLI0FzaTp1ixniTbCHn9P7N+6DKElF9b7yU2HZfI3ZLrAUVJQ3RSriYQtgDxcMGfrMWq qqVSl8q4gMtoMTaKJzQLIEuzE1ahTMqXdvGZc0T37tXemplTGCox3t8W4kmfTGmNeFd1 QO+Wn5CjOyKOx/7/OWJ6PleN80pEEO6BxIHDfOa1pjYMuZhFwZZ+WlNhCCFTAev6Hpja KweQ== X-Gm-Message-State: AMke39nweQRh6GgYPUC8ab8aPtkJIHlpigWkxUAVjX8Bk0VC7onn0RVxISwgUZljGp8Z0w== X-Received: by 10.99.147.68 with SMTP id w4mr4639730pgm.32.1488947363073; Tue, 07 Mar 2017 20:29:23 -0800 (PST) Received: from ?IPv6:2406:e007:77b4:1:28cc:dc4c:9703:6781? ([2406:e007:77b4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f205sm2622619pfa.35.2017.03.07.20.29.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 20:29:22 -0800 (PST) To: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> Date: Wed, 8 Mar 2017 17:29:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:29:25 -0000 Well, I take that back. I think all these points can be slipped into this week's update of the draft (I plan to submit that on Friday NZ time). Two points for the WG: >=20 > =E2=80=94 Section 3.5.1 =E2=80=94 >=20 > If there is no ACP, the protocol MUST use another form of strong > authentication and SHOULD use a form of strong encryption. See > Section 3.5.2.1 for further discussion. >=20 > Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? > Looking ahead to 3.5.2.1, how could it be considered safe to use a > network configuration protocol across administrative boundaries > without encryption? Input please, or else you will see this as an open issue in Chicago. Personal opinion: encryption should be a MUST. On UTF-8: > The other question is whether there are any restrictions on what > Unicode characters can be represented. You make the colon a special > character but give no other restrictions, so an objective name could > include space characters (and various related Unicode characters such > as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), > control characters (FORM FEED, CARRIAGE RETURN, and the like), Once we specify byte-by-byte comparison, do we need to worry about this in a protocol document? If someone is silly enough to specify an objective called 'example.org:=D0=9D=D0=B5=D0=B4=D0=BE=D1=81=D1= =82=D0=B0=D1=82=D0=BE=D1=87=D0=BD=D0=BE=E6=8F=A1 d=C3=A9j=C3=A0 vu ' do we care, in the protocol design? Personal opinion: we don't need to say anything. Regards Brian On 08/03/2017 16:44, Brian E Carpenter wrote: > Thanks Barry. Good comments, but we have to get a new draft out > before the deadline, so I'm not sure these will all make it in > until the one after. >=20 > Regards > Brian >=20 > On 08/03/2017 15:43, Barry Leiba wrote: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> First, I'm sorry this review is a few days late, and I hope that isn't= >> a problem. >> >> Second, the document is "ready with issues". Most of the comments >> below are minor, and editorial. The three that are substantive are: >> >> 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5= =2E2.1. >> >> 2. The UTF-8 issues in Section 3.10.1. >> >> 3. Guidance for the Designated Expert in Section 7. >> >> These should all be easy to resolve. >> >> =E2=80=94 Section 1 =E2=80=94 >> >> A reference model >> for autonomic networking on this basis is given in >> [I-D.ietf-anima-reference-model]. The reader should consult this >> document to understand how various autonomic components fit togethe= r. >> >> Even though that document is an informative reference, I find it odd >> that the draft that helps us understand how this all fits together. . >> . is an expired draft. It makes me wonder how well baked things are. >> >> =E2=80=94 Section 3.1 =E2=80=94 >> >> The following additional terms are used throughout this document: >> >> o Autonomic Device: identical to Autonomic Node. >> >> It=E2=80=99s not a big point, but: Why? Why is it important or useful= to >> specifically define a *new* term in this document that has the same >> meaning as a similar term that=E2=80=99s already defined? >> >> And, actually, now that I check, I see that =E2=80=9Cautonomic devices= =E2=80=9D is >> used in exactly one place, in the Abstract. I suggest changing the >> term in the abstract to =E2=80=9Cautonomic nodes=E2=80=9D, and removin= g this >> definition. >> >> =E2=80=94 Section 3.2 =E2=80=94 >> >> Because GRASP needs to work whatever happens, especially during >> bootstrapping and during fault conditions, it is essential that eve= ry >> implementation is as robust as possible. >> >> There seems to be a missing word, or some such; I can=E2=80=99t parse = =E2=80=9CGRASP >> needs to work whatever happens=E2=80=9D. And picky grammatical nit: >> subjunctive mood is needed with =E2=80=9Cessential=E2=80=9D, so it sho= uld be =E2=80=9Cit is >> essential that every implementation be as robust as possible.=E2=80=9D= >> >> =E2=80=94 Section 3.3 =E2=80=94 >> >> GRASP >> provides mechanisms to guarantee convergence (or failure) in a >> small number of steps, i.e. a timeout and a maximum number of >> iterations. >> >> Another nit. This is an outstanding example of why I don=E2=80=99t lik= e to use >> =E2=80=9Ci.e.=E2=80=9D: in this case, it leaves me wondering whether t= hat=E2=80=99s really an >> exhaustive list, or whether you meant =E2=80=9Ce.g.=E2=80=9D. And, to= me, it reads >> awkwardly anyway. I suggest one of these alternatives (the sorts that= >> can pretty much always stand in for the overused and unnecessary >> =E2=80=9Ci.e.=E2=80=9D): >> >> NEW-1 >> GRASP >> provides two mechanisms to guarantee convergence (or failure) >> in a small number of steps: a timeout and a maximum number of >> iterations. >> >> NEW-2 >> GRASP >> provides a timeout and a maximum number of iterations, >> which together guarantee convergence (or failure) in a >> small number of steps. >> >> =E2=80=94 Section 3.5.1 =E2=80=94 >> >> If there is no ACP, the protocol MUST use another form of strong >> authentication and SHOULD use a form of strong encryption. See >> Section 3.5.2.1 for further discussion. >> >> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? >> Looking ahead to 3.5.2.1, how could it be considered safe to use a >> network configuration protocol across administrative boundaries >> without encryption? >> >> =E2=80=94 Section 3.5.2.2 =E2=80=94 >> >> A responder >> SHOULD NOT send a Discovery Response message unless it cannot be= >> avoided. >> >> Any clue about why it might be possible that it =E2=80=9Ccannot be avo= ided=E2=80=9D? >> >> =E2=80=94 Section 3.5.2.3 =E2=80=94 >> >> o Any type of GRASP message MAY be sent. >> >> This doesn=E2=80=99t feel like a =E2=80=9CMAY=E2=80=9D to me. You=E2=80= =99re not saying that there=E2=80=99s >> a protocol choice here, and how to handle it is optional and up to the= >> implementation. You=E2=80=99re saying that all types of GRASP message= s are >> permitted when you=E2=80=99re using a SONN instance. So maybe, =E2=80= =9CAll types of >> GRASP messages are permitted.=E2=80=9D >> >> =E2=80=94 Section 3.10.1 =E2=80=94 >> >> All objectives are identified by a unique name which is a case- >> sensitive UTF-8 string. >> >> Actually, =E2=80=9Ccase-sensitive=E2=80=9D isn=E2=80=99t a sufficient = descriptor for UTF-8, as >> there are issues of canonicalization and normalization, and the fact >> that languages differ in whether =E2=80=9Ccase=E2=80=9D makes sense at= all. This >> would be a bigger issue if you wanted case insensitivity, but as it is= >> I think the fix is easy: you should just say that the name is a UTF-8 >> string that is compared byte by byte. This will have the effect of >> being case sensitive when that makes sense, and will also eliminate >> the issues of canonicalization and normalization: different ways of >> representing characters such as =E2=80=9C=C3=A4=E2=80=9D and =E2=80=9C= =C3=B4=E2=80=9D and =E2=80=9C=C3=A9=E2=80=9D will compare as >> different, and as these are protocol elements and not user strings, >> that should be fine. >> >> The other question is whether there are any restrictions on what >> Unicode characters can be represented. You make the colon a special >> character but give no other restrictions, so an objective name could >> include space characters (and various related Unicode characters such >> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), >> control characters (FORM FEED, CARRIAGE RETURN, and the like), >> characters from every character set and language including Cuneiform >> and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL >> SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO. If >> that=E2=80=99s all OK, then that=E2=80=99s fine (and maybe it is, as, = again, this is a >> protocol element, not a user string). I just want to make sure you >> thought about it. >> >> =E2=80=94 Section 7 =E2=80=94 >> >> The creation of the Specification Required registry for the Objective >> Names Table needs to specify guidance for the Designated Expert (see >> draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5). It doesn=E2=80= =99t >> have to be a lot, but it needs to be clear for future DEs who might >> not have been involved with developing this document what they need to= >> consider as they review registration requests. Why might they push >> back on a registration request? Should they, for example, allow >> registration requests for two different Objective Names of =E2=80=9Cfr= obozz=E2=80=9D >> and =E2=80=9CFrobozz=E2=80=9D? What sort of documentation is sufficie= nt for a >> registration (is =E2=80=9Cenough that you think implementations can be= written >> from it=E2=80=9D good enough, or are there specific things that the >> documentation ought to contain)? >> >=20 From nobody Wed Mar 8 11:29:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5B12955C; Wed, 8 Mar 2017 11:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 JLKRSvOb95oX; Wed, 8 Mar 2017 11:29:51 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 471661293FF; Wed, 8 Mar 2017 11:29:51 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id h10so111838066ith.1; Wed, 08 Mar 2017 11:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=+9mcPtruFdzdhcnhmVHhpUu9CsV11dZ3aSJSgdGHTSE=; b=DbLyahh/2INHmT/0peVJwfJ9il70KyNGgn4WUeZ2EUkJT3pPI82ClbNUJBfixKj7Hs CsL2yjk4BbswPysKGNtn6q2c/bojJ+2GvUv2pPEEYUtZYF7Q/YkXfBelTWgngLYM/CTN i1YH/KBD56ozhS+wzzHABOWEWulgP+haSNqCDyJYEWCUM7rBbR2PcrF8cTmeQoilHeIQ A+RL3pLlYKtuadVrq9CdADeGrmTlgJ4eM4V7LT62g6GxylqIoWrINkECKalsmjBKiQQX 1fuhOCtFZjf5DajhhxFpGOWcNCoLTF/TdBbMQSNJtqQcZWSChphaWy1wDYpRDjO60jdi sUVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=+9mcPtruFdzdhcnhmVHhpUu9CsV11dZ3aSJSgdGHTSE=; b=T7d4OCoRncxahPqMdNjFAHf82c+4NTo3ylC4DGbUf04r+H5EE3X9vDBNEYmMPNgTcr WzIe7mg8IOSiGMnbP6AkJqnvjXG5C/8c6i4ninXegAX/wNgrxaEuy4f+GONdoFqTU8kB j+b5Cp/P4buNzklrhM+jmWBGOLsaxToC9jx/0+abKAbNoKCi4SlHAEO/Ljx6OcopGoFk B2pzltq/OwvhCEU9ecXnVAgV8BKtSbjapZOZ+uwalfAYLNS65lm1o6XCpKWFAkSZtY6m /ZROlIsE48FOI+Qt5jeuLPn9oRo0z9ldadxaZsy8kL+bWdqbZMswIV7bM3tYz6gLHTug wY0w== X-Gm-Message-State: AMke39kKEHvWAkZfiKrKtTgQXkDEs7TdhIBU58Y3mU0Y7TOcFN1c9JQsVaVFeSRmROJ2bmAe5WRoPq8uN5f71A== X-Received: by 10.107.46.85 with SMTP id i82mr7391114ioo.85.1489001390626; Wed, 08 Mar 2017 11:29:50 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.35.200 with HTTP; Wed, 8 Mar 2017 11:29:50 -0800 (PST) In-Reply-To: <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> From: Barry Leiba Date: Wed, 8 Mar 2017 14:29:50 -0500 X-Google-Sender-Auth: SuvIRyg6EkpJA3WxKOgEQ2F02vY Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] [secdir] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 19:29:53 -0000 > On UTF-8: > >> The other question is whether there are any restrictions on what >> Unicode characters can be represented. You make the colon a special >> character but give no other restrictions, so an objective name could >> include space characters (and various related Unicode characters such >> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), >> control characters (FORM FEED, CARRIAGE RETURN, and the like), > > Once we specify byte-by-byte comparison, do we need to worry about > this in a protocol document? If someone is silly enough to > specify an objective called 'example.org:=D0=9D=D0=B5=D0=B4=D0=BE=D1=81= =D1=82=D0=B0=D1=82=D0=BE=D1=87=D0=BD=D0=BE=E6=8F=A1 d=C3=A9j=C3=A0 vu > ' do we care, in the protocol design? > > Personal opinion: we don't need to say anything. That's probably correct, and I just wanted to be sure y'all had thought about it -- more whether there'd be an issue with space-related characters or confusibles than about real non-Latin languages or pile-of-poo icons. Thanks for addressing my comments! Barry From nobody Thu Mar 9 06:31:15 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5440312960E for ; Thu, 9 Mar 2017 06:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 8F__0lnHRaut for ; Thu, 9 Mar 2017 06:31:13 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184FD12941E for ; Thu, 9 Mar 2017 06:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1443; q=dns/txt; s=iport; t=1489069873; x=1490279473; h=to:from:subject:message-id:date:mime-version; bh=1TD+0FTFlli8E9gcqkZqa6MK5b+0CnAFwHrjpDN+hU4=; b=ARCQO/oC0SaPYzAkkljG6/ar/eZOTOhdjA5uGXfh8kn/u1casUVx/O8t iAKEXOJRtbDu/q2eNfA2e0MXTjs6DD5Mah+/uug3NyeLTM6O/ckqKdFzh bmZAgJqm21UfNJWqTc6CjucI+sBI2n2rQfkW17L8rS0GbubmUhvJAmQaf o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAQABZsFY/xbLJq1dHAEBBAEBCgEBi?= =?us-ascii?q?RyKDHOmE4IOiRIYAQIBAQEBAQEBayiFP4EzAl8NCAEBiXygSpAGgiaKbwEBCAI?= =?us-ascii?q?BFg+CMYYiikSCXwWJJJMVg3iCCYw3gWMBiGuGUZM/Hzg+RSIVCBcVhxQ/imABA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.36,268,1486425600"; d="asc'?scan'208";a="651321864" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 14:31:11 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v29EVAwc015891 for ; Thu, 9 Mar 2017 14:31:10 GMT To: Anima WG From: Eliot Lear Message-ID: Date: Thu, 9 Mar 2017 15:31:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xjAsPl8enLHrw37kxeIGcKifWLOTbH0x1" Archived-At: Subject: [Anima] CRLs in iDevID manufacturer signing certs? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:31:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xjAsPl8enLHrw37kxeIGcKifWLOTbH0x1 Content-Type: multipart/mixed; boundary="c7MJatWF7doQ0K2IfON4EFWcoRpRLAwdo"; protected-headers="v1" From: Eliot Lear To: Anima WG Message-ID: Subject: CRLs in iDevID manufacturer signing certs? --c7MJatWF7doQ0K2IfON4EFWcoRpRLAwdo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, What is the thinking on including CRL pointer in the manufacturer signing cert? This question came up in industry discussions. Eliot --c7MJatWF7doQ0K2IfON4EFWcoRpRLAwdo-- --xjAsPl8enLHrw37kxeIGcKifWLOTbH0x1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwWctAAoJEIe2a0bZ0noz0bIIAIcYkS5UmQ8/ZBo/O+KK9Tu5 SrPnz/h2C8jJyBzB/B5VgGdp/f6BcOssJrrU1zrNB3t+DeecWiB4fcbETg7srprq 8zx+dlrR8Rlo0WoV2y53e4of0P+jtob0ayGR1tF+n+ImTwye7K3UCQPY8SH08qV/ gcxBAFfvxGmkJM9b364zYKKYUKR85d3D+JGgWqXubm8vycKwnzUtK1Zc3R0e8Cqj 8hDbAU2VNZ/iIgb+lcwtedMmEf2HnqQFesxG6MAwRZFSb1bkjLKSGlCAhM/eRIxc yeoHrScomwYigWcxT629QGjA9tyXfgiQfq9+PNxxiNhft9oslIB6WqvkTMzvSMw= =6O2W -----END PGP SIGNATURE----- --xjAsPl8enLHrw37kxeIGcKifWLOTbH0x1-- From nobody Thu Mar 9 06:49:53 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF06129633; Thu, 9 Mar 2017 06:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZYVCTNxVbrBh; Thu, 9 Mar 2017 06:49:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9575312963B; Thu, 9 Mar 2017 06:49:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 297EE200A3; Thu, 9 Mar 2017 10:12:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9AFA76381A; Thu, 9 Mar 2017 09:49:47 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:49:52 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? >> Looking ahead to 3.5.2.1, how could it be considered safe to use a >> network configuration protocol across administrative boundaries >> without encryption? > Input please, or else you will see this as an open issue in Chicago. > Personal opinion: encryption should be a MUST. I believe that we will have situations where we have a secured ACP into a NOC (to an edge router or VM hypervisor), and then we will have some unencrypted, but secured links to platforms in transition. It will be easy to add the GRASP daemon to answer resource requests to the platform, but hard to add the ACP to that platform without a forklift upgrade. This is why I think it is a SHOULD, as much as I want it to transition to being a MUST. >> The other question is whether there are any restrictions on what >> Unicode characters can be represented. You make the colon a special >> character but give no other restrictions, so an objective name could >> include space characters (and various related Unicode characters such >> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), >> control characters (FORM FEED, CARRIAGE RETURN, and the like), > Once we specify byte-by-byte comparison, do we need to worry about this > in a protocol document? If someone is silly enough to specify an It matters, when humans have to confirm things. I think that objectives will be mostly baked into code. So, I agree with you, but I would rather exclude all that UTF stuff too. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljBa4gACgkQgItw+93Q 3WVaWAgAvOM0lRqF2w2rgVcxbkl+zEhdW3GS6mo7jWJ9b5ERLXH48xWeWoVTXkTf GxlpUUVniMmwmLtPFeU043p7wfMWAWwamD1N6cjvQGRZxgduRYxuRxucvT+OTEvA thX9gF+sCHZbVwr9OQp3X3fOoGMYo1801loDt+KPGgtrNF4pD2KEniCHrgKHhBrB xLZpMRiZ9MQAmnnoVesqpf0ZVPaPaV8wg+oPuwwUd8HJP52IYVV51kzVcIPQlErN eefWDGRX29ZcFyZI6tSeR+GPGQaefqFeKo9Jbkt+Tg2nGXRGELriOQ2QE/JXW1wD Ab+kUbOOXVm2nJzLj4mm6Qh8/bROIQ== =xqB8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 9 08:10:07 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD6F12948B for ; Thu, 9 Mar 2017 08:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 l4EVy-QVDLBw for ; Thu, 9 Mar 2017 08:10:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26D01293FC for ; Thu, 9 Mar 2017 08:10:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6AA4B200A3; Thu, 9 Mar 2017 11:32:47 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A22C66381A; Thu, 9 Mar 2017 11:10:01 -0500 (EST) From: Michael Richardson To: anima In-Reply-To: <58c9a8e6-bd24-7568-82d3-5fbf2d7eaacd@gmail.com> References: <7655.1476892759@obiwan.sandelman.ca> <58c9a8e6-bd24-7568-82d3-5fbf2d7eaacd@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] GRASP vs ASA negotiation (was Re: concerns about selection of session-id in GRASP messages) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:10:05 -0000 --=-=-= Content-Type: text/plain Please excuse time-warp mail: trying to hit zero inbox... [so you'd better not reply! :-)] I think that my point below is not contradicted by any text, I just wanted to close the loop on this thread. At least close it in my mind. Brian E Carpenter wrote: >> 2) the response from a multicast DISCOVERY is a unicast TCP >> connection. (We've discussed this before, and I'm okay with it, but I >> still wonder if it will be well received.) >> >> Is there any reason why the TCP connection for the reply has to be >> from the GRASP "kernel"/"core" daemon? Could the GRASP daemon pass >> the enquiry to the ASA itself, and the ASA could connect to the thing >> that is asking, and reply with the M_RESPONSE itself? > In my opinion, no. ASAs are the apps of an autonomic network and won't > be written by protocol geeks. The actual ASA should simply register > itself with GRASP and indicate that it's available for discovery; it > will be some daemon inside GRASP that handles discovery. I think any > other implementation model is unreasonable: we're hoping there will be > 100s or 1000s of ASAs. (However, some of GRASP will be a user space > library, as Toerless pointed out ages ago and as the API draft > indicates.) I share your view: ASAs need to be the apps of autonomic networking. Quite literally that is a good model to take, and I hope someone takes this view. The whole android model: Java/Dalvik/ART, IDE, very low latency IPC, and isolation between ASA by default. Router Control plane CPUs are probably still underpowered compared to today's smartphones, but are still in the same category. My recent understanding is that the M_RESPONSE is just about where the ASA is. That the thing asking would still need to initiate a TCP GRASP connection to the ASA to do the M_SYN_NEG process. What I was thinking was that if the M_RESPONSE was sent by the responding ASA, then it could continue to use the TCP connection that was already up. It isn't a TCP connection setup that I'm trying to avoid, (that's a really minor saving) but rather it permits load balancing of the ASA function at discovery time, rather than a TCP SYN time. And if the ASA is located in the NOC, it permits the NOC to do outgoing TCP connections, rather than accept incoming ones. In my thinking, the core/kernel GRASP daemon then functions much like inetd did in Unix systems of yore (systemd has tried to replace this). > It would be a protocol change, since there's no way to signal that at > the moment. Is it really useful? (It would probably be a new locator > option, like locator-option /= [O_SAME_LOCATOR]). But it would only > work in compressed implementation where the ASA and GRASP are tightly > integrated. I clearly did not explain this well enough, because you concluded the opposite of what I was thinking. It would be used in the opposite situation where GRASP spawned the ASA, passed it the M_DISCOVERY message to reply to. When I say "spawned", it could be a process, or a complete container, maybe a full VM. It might even have a different IP address, although at that point I consider that really, the GRASP daemon has just relayed the M_DISCOVERY to a very limited GRASP instance running inside the ASA. This might be the best way to think of the architecture that I'm thinking of anyway. That's why I wrote, above, it doesn't really affect the protocol. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljBflUACgkQgItw+93Q 3WWEVgf+Ofcik1cMcFDtxN+xvL0OK8j4/28epAiCCIOlu110Org4VLVt4w8y1KOu ixLym0O+VjRVrh1XCNAu6hVuM/V8fQkmOd9bCN5zlxINqlDIVqzrYzV6RRkfKP3N 6hasoLSRVV7QoPlNaQ/dFIsONVuL5VrkeWVHTn4TujHVw3qbFJRskfp429mm/cdz t8aayzr/waPrTa1DvtOY891TfdW9/QimKhlXNdrb8mMc7H6x/7iVQot9U43UEdyt p0Wsi0ymuQryXWcYzeEl0llPr6ElKeRGpji2mbLzheY6rFXVLc/4jH9k+R/0x+aD dcYkEM8ZjI4XKq7ErhG2cYMQ4RJhwg== =Bwb0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 9 08:54:07 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D0812948B; Thu, 9 Mar 2017 08:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 lr1izkleiMah; Thu, 9 Mar 2017 08:54:00 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 CF009128B44; Thu, 9 Mar 2017 08:54:00 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id h10so132005865ith.1; Thu, 09 Mar 2017 08:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jmE5hykQXucwIEq68YxtokGzM/Sn+zO04u9M+uvmp/o=; b=WSdAF72z7giv6Gw8PnshSLdZtlHkiaCKd8/VcvP3k8KwC90+gaQ+OFgQk3EaHroRGv 0WhpZvMne9UrXGxCHldG8cZtwYB80B4dWMcdUsv5o1oeYXbL/SP2by17UoimZU5FpbtF P3CrW7F4ZMVZ9Q8S6GS95roNAVOcgshvaYHNYbYwZaZb1leyibN64GtdqLL0ZzVOd2g3 ujO3c+dKngLxrx52SPXwdDocXj9Rdc9YKAuC2BAy0So+xWIXUHjGhp0dV5gVxdztBaA+ TfpRn+MdwCQLFsxYGXBjLQTsEYruEKqMdFx7tTqY4PoPSki0QP3D1XWU+C7sx/gak7g5 htAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jmE5hykQXucwIEq68YxtokGzM/Sn+zO04u9M+uvmp/o=; b=U1CSR8VPX2bvhZjV4P9PBqQQJ9+YqZ5nwuKvWQIpzN2EP62BfBxGqInWVvZbcGtLwH PHStCRbCvUlFHAYhsf/8tSvuVzTWI05NziOawMAIWBljTqdQzmlhjmvx5exYedlUUcBc 4YWRgySSCoJ81hEhT9QAxgfbCPfdceBQVPae9k/ZuS8y8I+u2tSx+dMjPOnGFlL/Q9gC aqO7nhGlk/r9cQQ0SLhs85TUXvIbQgk+J28aJfGD+kTf2AJXIcUleQMRQLBkT2+Z/9xx f6S7MZ0lHXIDyORIWKF9l7A8h7xdIUc/qaiUP+9+byYxPWQywbpVcQ4rbYJeYLlNerTr QEmQ== X-Gm-Message-State: AMke39nemigSbhNKpBQgXE+8iy0fe04lCLvfB4v0p697YrOxgwTMVCx8yOgPA9lKp6UemBLj7ZJlRuldMccwRA== X-Received: by 10.36.118.68 with SMTP id z65mr30757954itb.59.1489078440001; Thu, 09 Mar 2017 08:54:00 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Thu, 9 Mar 2017 08:53:59 -0800 (PST) In-Reply-To: <17893.1489070987@obiwan.sandelman.ca> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> From: Barry Leiba Date: Thu, 9 Mar 2017 11:53:59 -0500 X-Google-Sender-Auth: Y6Q64NEITJ3FyiIiTZrryh-JyEM Message-ID: To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:54:02 -0000 > > Personal opinion: encryption should be a MUST. > > I believe that we will have situations where we have a secured ACP into a NOC > (to an edge router or VM hypervisor), and then we will have some unencrypted, > but secured links to platforms in transition. > > It will be easy to add the GRASP daemon to answer resource requests to the > platform, but hard to add the ACP to that platform without a forklift > upgrade. > > This is why I think it is a SHOULD, as much as I want it to transition to > being a MUST. This brings up a common rant that I have: We should be putting into our protocol specs what we want the protocol to be, not some compromise that comes from knowing that not everyone will comply with everything from the start. If the right thing is to say "MUST encrypt", but we know there'll be a transition period during which that's not fully practical, then we should say that. Something like this added to Section 3.5.1: NEW In some cases there will be a transition period, in which it might not be practical to run with strong encryption right away. It's important to keep this period as short as possible, and to upgrade to a fully encrypted setup as soon as possible. END > > Once we specify byte-by-byte comparison, do we need to worry about this > > in a protocol document? If someone is silly enough to specify an > > It matters, when humans have to confirm things. I think that objectives > will be mostly baked into code. So, I agree with you, but I would rather > exclude all that UTF stuff too. That's true: if these really are protocol elements and there's no need to have them Internationalized for human consumption, perhaps limiting them to US-ASCII makes sense and avoids issues with odd character effects (code that breaks if certain characters appear in strings, or humans debugging things and being confused by characters that look the same but are encoded differently). On the other hand, if it really would be handy to be able to define objective names in Chinese, Hindi, or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the possibilities are understood and folks are OK with it. Barry From nobody Thu Mar 9 10:25:23 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFE31296F3 for ; Thu, 9 Mar 2017 10:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 zLULzYgjs3hz for ; Thu, 9 Mar 2017 10:25:20 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0122.outbound.protection.outlook.com [104.47.36.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4FB1295CA for ; Thu, 9 Mar 2017 10:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4InQqagE3MkYCD4HdBiXGsbZeqAah+uPEQCw7FoRE1A=; b=hpmgmBm2yS7pSeOGtk+4xg4XWYjzPkBdlnipZQM3KpRKJJSVDrlby0E31WdtPXE2AwWBL7Z2lDNxX/e8rhJRkxgcvkK46cpiF2u7LueGUMPJZauoLsKQcMm3sqXtnhrtYp15HtypvfwYuu5Hc5C/fXwcHB5dzTqo521khwHJLI0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Thu, 9 Mar 2017 18:25:17 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.018; Thu, 9 Mar 2017 18:25:17 +0000 From: Kent Watsen To: Eliot Lear , Anima WG Thread-Topic: [Anima] CRLs in iDevID manufacturer signing certs? Thread-Index: AQHSmOHRDTAQ+7eHDECCBKhdWzwfsqGMf2mA Date: Thu, 9 Mar 2017 18:25:17 +0000 Message-ID: <4D0FFE5F-52E3-40E9-A1CB-1E791F0A8458@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:TkTUdTLPF9mzA5ce52QenqwB8iG/nGridmUOBvnZPolicQO91X8ADvz1ZG0ZxOWtDFqZleR88hyLBpc4XSinyYMuyOL4r2xclWrcXeMv3Q8EshAAiYEl62A8+atkuIhqhBp/cMJRyDOvMR1byPM18Fs9tTAo4CUEo7zCUSAJcadJoWSaKTiE+dtYED5KDr7aYNIAGI1brm3Mt+hxy8K7YwujuIvEbJGe2piO+RePO1g3XK283GxeKcm1krO8EKau37kdUIvWkkBMtbZQJaSJ7lc0JMPPnHS4NNcsYgpX9ZHfd6bLXUGYvwKoxVwLtmPfYvX0p489UdSmEFNcx4Qn9w== x-ms-office365-filtering-correlation-id: 33323d6c-0d45-4666-28cc-08d46719a2ef x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39850400002)(39410400002)(39450400003)(81166006)(66066001)(33656002)(6116002)(3280700002)(3846002)(106116001)(82746002)(7736002)(38730400002)(2906002)(53936002)(83716003)(6246003)(102836003)(36756003)(86362001)(3660700001)(5660300001)(6436002)(6486002)(8936002)(2900100001)(6512007)(25786008)(8676002)(50986999)(189998001)(229853002)(99286003)(2950100002)(54356999)(4001350100001)(6506006)(77096006)(305945005)(76176999)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 18:25:17.0570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:25:21 -0000 SGkgRWxsaW90LA0KDQoNCj4gV2hhdCBpcyB0aGUgdGhpbmtpbmcgb24gaW5jbHVkaW5nIENSTCBw b2ludGVyIGluIHRoZSBtYW51ZmFjdHVyZXINCj4gc2lnbmluZyBjZXJ0PyAgVGhpcyBxdWVzdGlv biBjYW1lIHVwIGluIGluZHVzdHJ5IGRpc2N1c3Npb25zLg0KDQo4MDIuMUFSIHNheXMgdGhhdCB0 aGUgSURldklEIHNlY3JldHMgbXVzdCBiZSBzdG9yZWQgY29uZmlkZW50aWFsbHkgYW5kIGJlIG5v dCBhdmFpbGFibGUgb3V0c2lkZSB0aGUgbW9kdWxlLiAgSW4gcHJhY3RpY2UsIGEgY3J5cHRvIHBy b2Nlc3NvciB3aXRoIHRhbXBlci1yZXNpc3RhbnQgTlZSQU0gaXMgdXNlZCAoZS5nLiwgVFBNKS4g IEFzIHN1Y2gsIHRoZSBsaWtlbGlob29kIG9mIHRoZSBjcmVkZW50aWFscyBiZWluZyBzdG9sZW4v ZGlzY292ZXJlZCBhcmUgbmVhciB6ZXJvLCBidXQgaXQgaXMgbm90IHplcm8sIGFzIGEgZGV0ZXJt aW5lZCBhZHZlcnNhcnkgd2l0aCBzdWZmaWNpZW50IHJlc291cmNlcyBjYW4gc3RpbGwgaGF2ZSB0 aGVpciB3YXkgd2l0aCBpdC4gIFN0aWxsLCB2ZW5kb3JzIHdpbGwgbGlrZWx5IGNvbmNsdWRlIHRo YXQgcHJvdGVjdGluZyBhZ2FpbnN0IHRoYXQgbGV2ZWwgb2YgYXR0YWNrIGlzbid0IG5lY2Vzc2Fy eS4gIFRoYXQgc2FpZCwgdmVuZG9ycyBmYWNlIGEgbW9yZSBsaWtlbHkgc2NlbmFyaW8sIG9mIGlz c3VlcyBvY2N1cnJpbmcgYnkgY29udHJhY3QgbWFudWZhY3R1cmVycywgd2hldGhlciBpdCBiZSBh Y2NpZGVudGFsIG9yIGludGVudGlvbmFsLiAgQW5kIGFzIHVubGlrZWx5IHRoaXMgc2NlbmFyaW8g bWF5IHNlZW0sIHRoaW5ncyBoYXBwZW4gYW5kIHRoZSB2ZW5kb3Igd291bGQgYmUgd2l0aG91dCBy ZWNvdXJzZSBpZiB1bmFibGUgdG8gaXNzdWUgcmV2b2NhdGlvbnMuICBUbyB0aGlzIGV4dGVudCwg c2V0dGluZyB1cCB0aGUgaW5mcmFzdHJ1Y3R1cmUgdG8gc3VwcG9ydCByZXZvY2F0aW9ucyBjYW4g YmUgY29tcGFyZWQgdG8gaW5zdXJhbmNlIC0gaG9wZWZ1bGx5IHlvdSBuZXZlciBuZWVkIGl0LCBi dXQgd2hlbiB5b3UgZG8sIHlvdSdyZSBnbGFkIHlvdSBoYXZlIGl0Lg0KDQpLZW50DQoNCg0KDQo= From nobody Thu Mar 9 10:29:29 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5769C1296FC for ; Thu, 9 Mar 2017 10:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jOJSna1oAAYi for ; Thu, 9 Mar 2017 10:29:27 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0C51296F9 for ; Thu, 9 Mar 2017 10:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2984; q=dns/txt; s=iport; t=1489084166; x=1490293766; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=2hA9u5C8cipNs+fhQy1VUCFD3jziHgEAOCK30bvA0u4=; b=fN1uhITJhzE0s0AL3Tnv9V4hLasUxZKjHLVI0irXE3wG1t6dbEDGj1bz UJtm13mLZyduN4koFCVoshkbnjl0d+CNchOhifw8cAYa76DIuOGr5JqTI EElGvSURfwm9LUq7lmS9MapqOPOaMuOSCrDBmMfISO1ZOhagYyK+Q0jwY I=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AQCMnsFY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIqYINgigxzkD0flTiCDh8LhXgCgnAYAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?BAQMBASFLGwsOCioCAicwBgEMBgIBAYl8DrERgiaKZgEBAQEBAQEBAgEBAQEBA?= =?us-ascii?q?QEBEQoFgjGGIgiCYodagl8FiSSTFYN4ggmMNwKKTYZRkz8fOIEDIhUIFxU/hFQ?= =?us-ascii?q?dgWQ/NYorAQEB?= X-IronPort-AV: E=Sophos;i="5.36,136,1486425600"; d="asc'?scan'208";a="650305831" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 18:29:02 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v29IT2Ud006584; Thu, 9 Mar 2017 18:29:02 GMT To: Kent Watsen , Anima WG References: <4D0FFE5F-52E3-40E9-A1CB-1E791F0A8458@juniper.net> From: Eliot Lear Message-ID: <04614977-f700-711c-8ccd-47740cffefbd@cisco.com> Date: Thu, 9 Mar 2017 19:29:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4D0FFE5F-52E3-40E9-A1CB-1E791F0A8458@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XFo2lOFUBGWwWe4r0nVgcnhqhJfh9FtQh" Archived-At: Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:29:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XFo2lOFUBGWwWe4r0nVgcnhqhJfh9FtQh Content-Type: multipart/mixed; boundary="v8Bb8jPCNmFTP2F3Q9XdEjHJtSfiINHeD"; protected-headers="v1" From: Eliot Lear To: Kent Watsen , Anima WG Message-ID: <04614977-f700-711c-8ccd-47740cffefbd@cisco.com> Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? References: <4D0FFE5F-52E3-40E9-A1CB-1E791F0A8458@juniper.net> In-Reply-To: <4D0FFE5F-52E3-40E9-A1CB-1E791F0A8458@juniper.net> --v8Bb8jPCNmFTP2F3Q9XdEjHJtSfiINHeD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, Kent. Then it seems to me that we have a MAY floating around for CRL checking on the part of the registrar for BRSKI. Right? Eliot On 3/9/17 7:25 PM, Kent Watsen wrote: > Hi Elliot, > > >> What is the thinking on including CRL pointer in the manufacturer >> signing cert? This question came up in industry discussions. > 802.1AR says that the IDevID secrets must be stored confidentially and = be not available outside the module. In practice, a crypto processor wit= h tamper-resistant NVRAM is used (e.g., TPM). As such, the likelihood of= the credentials being stolen/discovered are near zero, but it is not zer= o, as a determined adversary with sufficient resources can still have the= ir way with it. Still, vendors will likely conclude that protecting agai= nst that level of attack isn't necessary. That said, vendors face a more= likely scenario, of issues occurring by contract manufacturers, whether = it be accidental or intentional. And as unlikely this scenario may seem,= things happen and the vendor would be without recourse if unable to issu= e revocations. To this extent, setting up the infrastructure to support = revocations can be compared to insurance - hopefully you never need it, b= ut when you do, you're glad you have it. > > Kent > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --v8Bb8jPCNmFTP2F3Q9XdEjHJtSfiINHeD-- --XFo2lOFUBGWwWe4r0nVgcnhqhJfh9FtQh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwZ7tAAoJEIe2a0bZ0nozP8YH/2wQYd3CNKTxXIpptjYN+OD2 9uXcBskWPvWjuWpMzCjrboCEROVr1Rkay/2NuPrAVNaZFUFUtBeq6q4nFy01Ect4 q0WrT1noYvc2GVMXAfmftCTvGOMtDBBsiNma1GWfyYqQXSkgc2RvYFKRsr7/cU+k Qha0KMfge0KlJxLw2Su4xTUoFZ6O9q/r/qcZtIRp89yLZWDG8CcPDK1eIPsKCmhQ b/idQNYkFuAZo9hL5WYztOybkCPjIyWFwbqMRw6CtiUi33jsbqpRuQPFC/K6fuMO MIWHRUmJt1p0Jttvj6A/fb6W5UeAph060QFxqQ3k7vll1NsNe+ojZMDI2F/vAo4= =EtKj -----END PGP SIGNATURE----- --XFo2lOFUBGWwWe4r0nVgcnhqhJfh9FtQh-- From nobody Thu Mar 9 11:16:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763C12984C for ; Thu, 9 Mar 2017 11:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 Be3zLCwOsXiJ for ; Thu, 9 Mar 2017 11:16:48 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0111.outbound.protection.outlook.com [104.47.37.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF313128824 for ; Thu, 9 Mar 2017 11:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZPFoQ8PoxuQI7AlrUhcRmHELBRvMDDaG2zL0UGqOk3c=; b=KOJfyhp2rNxcBNwVCg8hH5TwY4H9f6uFpKe5mbu2R3twT6GSmA46n7KJuOvHYG7a6H7ow9aF072hHQe6ec66DqsDwgQvuNl4Jde/LtM/9FYSbhsdjJz9wE/smCPybSYArZeaqxrK9g0M5z6J1d4Tbd4YljArI6TbYqqxtfQum24= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Thu, 9 Mar 2017 19:16:45 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.018; Thu, 9 Mar 2017 19:16:45 +0000 From: Kent Watsen To: Eliot Lear , Anima WG Thread-Topic: [Anima] CRLs in iDevID manufacturer signing certs? Thread-Index: AQHSmOHRDTAQ+7eHDECCBKhdWzwfsqGMf2mAgABU3QD//7mFAA== Date: Thu, 9 Mar 2017 19:16:45 +0000 Message-ID: References: <4D0FFE5F-52E3-40E9-A1CB-1E791F0A8458@juniper.net> <04614977-f700-711c-8ccd-47740cffefbd@cisco.com> In-Reply-To: <04614977-f700-711c-8ccd-47740cffefbd@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:fBYbN02RS4+4ECxo1zIAVHCQMn2vHXxM65MF6raGUteWygLbQytQ6ljAwYxdnw7MCmlQxI4VPcD0q79gY25AsdgDjS13U9VSjLe19iO6t6Ii4ijj+CfFW+wu28Xgg0SiXYzooFvOSxxMo/LBo3HXDjxnPa/SPHhh9vBjdN238GArSt93MrlRd2Smm7JLgITsGlakpc2y0/EJnyT6yubxNsJLr7PR/OXSDJ0KMB+Yaz/g/57Mr3Qy/3WfCKbTywQIRpB4ooNt2HX7itg9pkWStKiuYHr8qAGuojJXJhVPKoAQdSI40oafe3LVDE3Se9uspfkE2brOuaTbYAYTzW0tGA== x-ms-office365-filtering-correlation-id: fb939ee2-7ac9-41d3-190c-08d46720d39f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39850400002)(39860400002)(39410400002)(377454003)(24454002)(102836003)(3846002)(54356999)(50986999)(6116002)(6246003)(66066001)(53546006)(4001350100001)(6306002)(81166006)(8676002)(6436002)(83506001)(6506006)(38730400002)(36756003)(86362001)(99286003)(76176999)(6486002)(6512007)(77096006)(25786008)(8936002)(3660700001)(7736002)(106116001)(2950100002)(2900100001)(305945005)(53936002)(229853002)(2906002)(33656002)(122556002)(3280700002)(5660300001)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <95CA8231A117354590FE100C25A19D59@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 19:16:45.1866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:16:49 -0000 DQpNeSB2aWV3IGlzIHRoYXQsIGlmIHRoZSBJRGV2SUQgaGFzIGEgQ1JML09DU1AgVVJMIGxpc3Rl ZCwgdGhlbiB0aGUNCnZhbGlkYXRvciBTSE9VTEQgZG8gdGhlIGNoZWNraW5nLiAgSWYgdGhlIHZl bmRvciBkaWRuJ3QgYWN0dWFsbHkNCndhbnQgcmV2b2NhdGlvbiBjaGVja2luZyBkb25lLCB0aGVu IHRoZSB2ZW5kb3Igc2hvdWxkJ3ZlIGV4Y2x1ZGVkDQpzdWNoIGluZm9ybWF0aW9uIGZyb20gdGhl aXIgSURldklEIGNlcnRzLg0KDQpGV0lXLCA4MDIuMUFSIHRha2VzIGEgbXVjaCBuZXV0cmFsIHN0 YW5jZSBpbiBTZWN0aW9uIDYuNS4zIChWYWxpZGF0aW9uIG9mIERldklEcyk6DQoNCiAgVGhlIERl dklEIGlzIGFuIFguNTA5IGNyZWRlbnRpYWwgYW5kIGNhbiBiZSB2YWxpZGF0ZWQgdXNpbmcgdGhl DQogIFJGQyA1MjgwIGRlZmluZWQgbWVjaGFuaXNtcy4gSURldklEcyBhcmUgaW50ZW5kZWQgdG8g aGF2ZSB2ZXJ5DQogIGxvbmcgdmFsaWRpdHkgcGVyaW9kcyBldmVuIGV4Y2VlZGluZyB3aGF0IHdv dWxkIG5vcm1hbGx5IGJlDQogIGNyeXB0b2dyYXBoaWNhbGx5IGFjY2VwdGFibGUuIFRoZSBtYW51 ZmFjdHVyZXIgaXMgbm90IHJlcXVpcmVkDQogIHRvIHByb3ZpZGUgYSBDZXJ0aWZpY2F0ZSBSZXZv Y2F0aW9uIExpc3QgKENSTCkgYWx0aG91Z2ggdGhlDQogIHZhbGlkYXRvciBtYXkgZG8gQ1JMIGNo ZWNraW5nIGlmIHRoZSBtYW51ZmFjdHVyZXIgcHJvdmlkZXMgQ1JMcy4NCiAgVGhlIHZhbGlkYXRv ciBtYXkgdmVyaWZ5IENSTHMgZm9yIExEZXZJRHMgYXMgbmVjZXNzYXJ5Lg0KDQpLZW50DQoNCg0K LS0tLS1PUklHSU5BTCBNRVNTQUdFLS0tLS0NCg0KVGhhbmtzLCBLZW50LiAgVGhlbiBpdCBzZWVt cyB0byBtZSB0aGF0IHdlIGhhdmUgYSBNQVkgZmxvYXRpbmcgYXJvdW5kDQpmb3IgQ1JMIGNoZWNr aW5nIG9uIHRoZSBwYXJ0IG9mIHRoZSByZWdpc3RyYXIgZm9yIEJSU0tJLiAgUmlnaHQ/DQoNCkVs aW90DQoNCg0KT24gMy85LzE3IDc6MjUgUE0sIEtlbnQgV2F0c2VuIHdyb3RlOg0KPiBIaSBFbGxp b3QsDQo+DQo+DQo+PiBXaGF0IGlzIHRoZSB0aGlua2luZyBvbiBpbmNsdWRpbmcgQ1JMIHBvaW50 ZXIgaW4gdGhlIG1hbnVmYWN0dXJlcg0KPj4gc2lnbmluZyBjZXJ0PyAgVGhpcyBxdWVzdGlvbiBj YW1lIHVwIGluIGluZHVzdHJ5IGRpc2N1c3Npb25zLg0KPiA4MDIuMUFSIHNheXMgdGhhdCB0aGUg SURldklEIHNlY3JldHMgbXVzdCBiZSBzdG9yZWQgY29uZmlkZW50aWFsbHkgYW5kIGJlIG5vdCBh dmFpbGFibGUgb3V0c2lkZSB0aGUgbW9kdWxlLiAgSW4gcHJhY3RpY2UsIGEgY3J5cHRvIHByb2Nl c3NvciB3aXRoIHRhbXBlci1yZXNpc3RhbnQgTlZSQU0gaXMgdXNlZCAoZS5nLiwgVFBNKS4gIEFz IHN1Y2gsIHRoZSBsaWtlbGlob29kIG9mIHRoZSBjcmVkZW50aWFscyBiZWluZyBzdG9sZW4vZGlz Y292ZXJlZCBhcmUgbmVhciB6ZXJvLCBidXQgaXQgaXMgbm90IHplcm8sIGFzIGEgZGV0ZXJtaW5l ZCBhZHZlcnNhcnkgd2l0aCBzdWZmaWNpZW50IHJlc291cmNlcyBjYW4gc3RpbGwgaGF2ZSB0aGVp ciB3YXkgd2l0aCBpdC4gIFN0aWxsLCB2ZW5kb3JzIHdpbGwgbGlrZWx5IGNvbmNsdWRlIHRoYXQg cHJvdGVjdGluZyBhZ2FpbnN0IHRoYXQgbGV2ZWwgb2YgYXR0YWNrIGlzbid0IG5lY2Vzc2FyeS4g IFRoYXQgc2FpZCwgdmVuZG9ycyBmYWNlIGEgbW9yZSBsaWtlbHkgc2NlbmFyaW8sIG9mIGlzc3Vl cyBvY2N1cnJpbmcgYnkgY29udHJhY3QgbWFudWZhY3R1cmVycywgd2hldGhlciBpdCBiZSBhY2Np ZGVudGFsIG9yIGludGVudGlvbmFsLiAgQW5kIGFzIHVubGlrZWx5IHRoaXMgc2NlbmFyaW8gbWF5 IHNlZW0sIHRoaW5ncyBoYXBwZW4gYW5kIHRoZSB2ZW5kb3Igd291bGQgYmUgd2l0aG91dCByZWNv dXJzZSBpZiB1bmFibGUgdG8gaXNzdWUgcmV2b2NhdGlvbnMuICBUbyB0aGlzIGV4dGVudCwgc2V0 dGluZyB1cCB0aGUgaW5mcmFzdHJ1Y3R1cmUgdG8gc3VwcG9ydCByZXZvY2F0aW9ucyBjYW4gYmUg Y29tcGFyZWQgdG8gaW5zdXJhbmNlIC0gaG9wZWZ1bGx5IHlvdSBuZXZlciBuZWVkIGl0LCBidXQg d2hlbiB5b3UgZG8sIHlvdSdyZSBnbGFkIHlvdSBoYXZlIGl0Lg0KPg0KPiBLZW50DQo+DQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFu aW1hIG1haWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+DQoNCg0KDQoNCg== From nobody Thu Mar 9 11:37:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F9129487; Thu, 9 Mar 2017 11:37:48 -0800 (PST) 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 6V5VotZqdRYU; Thu, 9 Mar 2017 11:37:47 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 958CD129464; Thu, 9 Mar 2017 11:37:47 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id j5so8235455pfb.3; Thu, 09 Mar 2017 11:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cYOum7V3ozoU6HK/r4s1+GdvvgcERKcAnStAvjq9wL4=; b=iXlM1GF5eMtItB7me/w6XWH4t/QzljGH7EOfDriAnTPHzBRadWZl1gptFJmT0aIBs9 bmv4QxmYMotweBh+MaFd+vzFFrYuxEEnoDab/HT8Xht82wpHmYzTmJ3cU9wrHEwtQiEX +7vV3FwA+H+4DQdaUJK/a8DtP3lqmtK6/nVrAW4Lgrj7JPiiW2xTw/3+JUHGXpkBLxTw UqBs+tlkYdCEaL5apsn5YUkEEY2RjcLKSkxOLA16wZjz0Q0Ru+GbC4Sugd8gvlFkukVS Tk/OA9XNx5vWEUSEzaaJLUFH1C8zhKKYfqZ9Xr0OEI//+nstC0W3nRUn4ZxfijC5LPWN 8hLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cYOum7V3ozoU6HK/r4s1+GdvvgcERKcAnStAvjq9wL4=; b=WpeBTwSEhZQiChPmBzMMxGwxzeYCKA76Bn0iXHOSCdZqSPVZjAHG8/HbLRqYnjj3U9 xUQJQ0gUU9grNZFXN8IDtay42u0D3B+KMwplp47C370tlQjRDfR9EEiTpeX2rlHAA6/o ubd7yLx7Mft+k9NR3EuwHXSmTHujTOVT9t8mLBGCBzdOyjDd4tovst9Mm7pj6qcHF1U2 WKlPHrG+a4HBU/jlGug2EaGr3H1Iix+fdqB1ayijnuNjXv6Sx4rf01el15vn7tHG5lgt 3TT486u++r05T6F3ghsgIfJqe2APlCDRYo8dCqLnpcMxa/vYih7SCGoILmdi0/1DBKoN SM5Q== X-Gm-Message-State: AMke39nz3qFAK66e683AAH4KO8Lj1NEOCx465pFdVxa1mrvTQR4b26zJbQL+5lUwUDFfqQ== X-Received: by 10.84.229.137 with SMTP id c9mr19780460plk.41.1489088267161; Thu, 09 Mar 2017 11:37:47 -0800 (PST) Received: from ?IPv6:2406:e007:4e09:1:28cc:dc4c:9703:6781? ([2406:e007:4e09:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 194sm13973771pfx.134.2017.03.09.11.37.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 11:37:46 -0800 (PST) To: Barry Leiba , Michael Richardson References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> Date: Fri, 10 Mar 2017 08:37:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:37:48 -0000 On 10/03/2017 05:53, Barry Leiba wrote: >> > Personal opinion: encryption should be a MUST. >> >> I believe that we will have situations where we have a secured ACP into a NOC >> (to an edge router or VM hypervisor), and then we will have some unencrypted, >> but secured links to platforms in transition. >> >> It will be easy to add the GRASP daemon to answer resource requests to the >> platform, but hard to add the ACP to that platform without a forklift >> upgrade. >> >> This is why I think it is a SHOULD, as much as I want it to transition to >> being a MUST. > > This brings up a common rant that I have: > We should be putting into our protocol specs what we want the protocol > to be, not some compromise that comes from knowing that not everyone > will comply with everything from the start. > > If the right thing is to say "MUST encrypt", but we know there'll be a > transition period during which that's not fully practical, then we > should say that. Something like this added to Section 3.5.1: > > NEW > In some cases there will be a transition period, in which it might not > be practical to run with strong encryption right away. It's important > to keep this period as short as possible, and to upgrade to a fully > encrypted setup as soon as possible. > END or perhaps more precisely: During initialization of nodes there will be a transition period... Whether this is phrased as an exception to the MUST or as the justification for ignoring the SHOULD is a matter of taste, I think. > >> > Once we specify byte-by-byte comparison, do we need to worry about this >> > in a protocol document? If someone is silly enough to specify an >> >> It matters, when humans have to confirm things. I think that objectives >> will be mostly baked into code. So, I agree with you, but I would rather >> exclude all that UTF stuff too. > > That's true: if these really are protocol elements and there's no need > to have them Internationalized for human consumption, perhaps limiting > them to US-ASCII makes sense and avoids issues with odd character > effects (code that breaks if certain characters appear in strings, or > humans debugging things and being confused by characters that look the > same but are encoded differently). On the other hand, if it really > would be handy to be able to define objective names in Chinese, Hindi, > or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the > possibilities are understood and folks are OK with it. My thought was that these names will sometimes be visible to humans so why not allow localized names? If GRASP succeeds it might be used for local applications, not just generic applications. So I'd rather allow it from the start, and if we have to add character-set restrictions later, so be it. Brian From nobody Thu Mar 9 12:00:07 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E687129413; Thu, 9 Mar 2017 12:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 iNMMoQUMKquG; Thu, 9 Mar 2017 12:00:00 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 91F311293E1; Thu, 9 Mar 2017 11:53:48 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id l7so35439382ioe.3; Thu, 09 Mar 2017 11:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DkCF+UmvGJ0tMtALYFtN6asNkMdqkAbikZguw1tQcbI=; b=iob793nxeXmuzsztqtVrfSS1kf7UC8qN6VAc32fSQonTmsiU/quEf2HyTVJdxW9ULJ HrgR3W3MygO8gG2+Byu5baDduVibjzp+q6YgXoh4/a1/yZqdysddTSB8M1qi5t1Lgohj WaqB+SM9gpFTWd2rLcIKtcp9M8IozStm85cnSaY3TEhktHtgecP7kL3q7+dRAcoorrQq bDnuzQlWyMqlGvjWlqyncTibGAuVCmxKGpLu0nx7JuapcYGEPXROGC7U7X5Vp/i8xwbE tgjgyiYPbz9a3SeRmkg+Z93Gv36exJK3DQT97Y0+d1BPaH5RbyP2CIF2sjEFv0IPmsaN NJlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DkCF+UmvGJ0tMtALYFtN6asNkMdqkAbikZguw1tQcbI=; b=nDbnuo2qO7CBycYMDsUp0ehrq36EME/hZ+ELjSbjeowxRmTmhZURfSxhbfdM7nGMiA aUfFa7fj3JBq+JCL4fF+JfCaCOg+rD6eXTlYtZi70si8YeGGOCAdSOWkOlL6RTwquikx u0BfhhvGyMIwSGh9HixSIRYg+YjTrROh2k1QET/92i3vezkvgFOUVletnCHCzoUzqDD9 kKrVa7d4QsG58/zxVz1c9kBNLoIpHjNCM2wy7zgnldNDAs4GTCbWfRRwcXuj+rxtheC0 Xuvfa0CTUWXrjydjP0JaIUeoC950YNJjyaW1FO+vsmkce7gaJRWHH5hf53xY878WgPeJ /5qw== X-Gm-Message-State: AMke39nBpR44BFEAsLUyL2UVS7nt9ko0a+UJoCfT6lidEk8PixZPlrpyfmORIBeQOFL5yaT+K4IIkEdsGCcy4A== X-Received: by 10.107.182.9 with SMTP id g9mr11747515iof.233.1489089227965; Thu, 09 Mar 2017 11:53:47 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Thu, 9 Mar 2017 11:53:47 -0800 (PST) In-Reply-To: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> From: Barry Leiba Date: Thu, 9 Mar 2017 14:53:47 -0500 X-Google-Sender-Auth: 6P0-7rtfBkJQ3IxvciGz9hs6mWo Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michael Richardson , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 20:00:01 -0000 >> This brings up a common rant that I have: >> We should be putting into our protocol specs what we want the protocol >> to be, not some compromise that comes from knowing that not everyone >> will comply with everything from the start. >> >> If the right thing is to say "MUST encrypt", but we know there'll be a >> transition period during which that's not fully practical, then we >> should say that. Something like this added to Section 3.5.1: >> >> NEW >> In some cases there will be a transition period, in which it might not >> be practical to run with strong encryption right away. It's important >> to keep this period as short as possible, and to upgrade to a fully >> encrypted setup as soon as possible. >> END > > or perhaps more precisely: > > During initialization of nodes there will be a transition period... Yep; better. > Whether this is phrased as an exception to the MUST or as the justification > for ignoring the SHOULD is a matter of taste, I think. I don't think it's a question of taste. If there's a long-term reason to run nodes without encryption, then SHOULD might make sense. But if we do expect the stable state to always be encrypted, and avoiding it is a short-term expedient that we want to have go away as soon as possible, then the protocol should say MUST, and the exception is clearly specified as a brief thing that mustn't last. It's a substantive difference, not one of writing style. > My thought was that these names will sometimes be visible to humans so why > not allow localized names? If GRASP succeeds it might be used for local > applications, not just generic applications. So I'd rather allow it > from the start, and if we have to add character-set restrictions later, > so be it. Makes sense to me. Carry on. Barry From nobody Thu Mar 9 18:52:18 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E407A1294DF; Thu, 9 Mar 2017 18:52:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148911433290.5795.7684785232355268412@ietfa.amsl.com> Date: Thu, 09 Mar 2017 18:52:12 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-grasp-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:52:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-10.txt Pages : 77 Date : 2017-03-09 Abstract: This document establishes requirements for a signaling protocol that enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 9 18:54:25 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFA41294EB; Thu, 9 Mar 2017 18:54:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148911446089.5796.6269029296262809928@ietfa.amsl.com> Date: Thu, 09 Mar 2017 18:54:20 -0800 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-prefix-management-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:54:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks Authors : Sheng Jiang Zongpeng Du Brian Carpenter Qiong Sun Filename : draft-ietf-anima-prefix-management-03.txt Pages : 14 Date : 2017-03-09 Abstract: This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-prefix-management-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 9 19:02:13 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF641294DF for ; Thu, 9 Mar 2017 19:02:12 -0800 (PST) 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 TycbT4x1lq0A for ; Thu, 9 Mar 2017 19:02:10 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F5C1294A6 for ; Thu, 9 Mar 2017 19:02:10 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id v190so36206552pfb.1 for ; Thu, 09 Mar 2017 19:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9CRbtboXHqSm7m3Zs62x7hTo/nezwFEkDxsgFRujliY=; b=Z6gbUOuKKlg6BxchkAdyPOtthH22CmlcX9SQ1ahNRfQUkUlq5IrOJpdk+/0E2xW+oR LF6PobrZCJPNF2UAVFj2nJvcIjJ1eKb6UykMqzrqfOVL/9yVzne6lKoZfJ0PWxYXbue/ 2JlKfFh/25TR93seO3RcwYdgEt8c3PSobJLe0oLXPZSgloUxXyMG/eLXoA61QnTHVhkw MuUV5iVe4nrGov9rwK7PqrcApk+Y51UnltDoOREQP/snwbaZOUnEGy5Xh4xKroF32QjU MsfXlWNqCN2U7M2GzV1E+wy/NfjVTGVslxLewKWlAswphwumpdq4dvJ9HeyZeZ0eMiOz KKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9CRbtboXHqSm7m3Zs62x7hTo/nezwFEkDxsgFRujliY=; b=KzbTjhwW/IPyC4CfooRw4VLGOzYBO5o5DU/JOnZfm3LTZJ8MOokRYwq39+fBVpewji aWJ31Ebasia0WMz8YHDxcg3isuXPJQ9FFdh4OHP+NR1Pfn6p0t1hB778PLuKm73GiQn/ NGa+Qus93Ixacus7p3P18F9BC0EcGlYRcoBy/x7btqjTR72NhnXz/yA+n530DQPtAKgl dE0pKqYZEvLhjb9h6Tge8vf/er+3nGQLHJ+9IEscwiQ3PwqUcKha3Xr/8+zs0+SmP9Cb BZ/A0hiRSJ6UdvT3yxe0MFzXYbeiF7W1rtNiCU/IDA+GYL7n7YWbZ43Q3RItSJWrNBtI UPsw== X-Gm-Message-State: AMke39mnN9NSD1RqqAiY0t2cleRdFlshq69K+NcogWwbZcEgVhN4WUfzZ/hi43jUX8VoRQ== X-Received: by 10.84.129.195 with SMTP id b61mr21866481plb.83.1489114929925; Thu, 09 Mar 2017 19:02:09 -0800 (PST) Received: from ?IPv6:2406:e007:4e09:1:28cc:dc4c:9703:6781? ([2406:e007:4e09:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y184sm15032672pgd.45.2017.03.09.19.02.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 19:02:09 -0800 (PST) References: <148911433290.5795.7684785232355268412@ietfa.amsl.com> To: anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <54177aa1-6f81-48fc-7cdc-298ad0bb4e70@gmail.com> Date: Fri, 10 Mar 2017 16:02:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148911433290.5795.7684785232355268412@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-10.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 03:02:12 -0000 Hi, This version tries to address numerous IETF Last Call comments, including a lot of editorial changes including clarifications and minor reorganization. The real technical changes are these: Protocol change: Specify that an objective with no initial value should have its value field set to CBOR 'null'. Protocol change: Specify behavior on receiving unrecognized message type. Noted that UTF-8 objective names are matched byte-for-byte. Added brief guidance for Expert Reviewer of new generic objectives. The open issues that we need to discuss in Chicago are: 63. Should encryption be MUST instead of SHOULD in Section 3.5.1 and Section 3.5.2.1? 64. Should more security text be moved from the main text into the Security Considerations? 65. Do we need to formally restrict Unicode characters allowed in objective names? 66. Split requirements into separate document? 67. Remove normative dependency on draft-greevenbosch-appsawg- cbor-cddl? Brian + co-authors On 10/03/2017 15:52, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-10.txt > Pages : 77 > Date : 2017-03-09 > > Abstract: > This document establishes requirements for a signaling protocol that > enables autonomic nodes and autonomic service agents to dynamically > discover peers, to synchronize state with them, and to negotiate > parameter settings with them. The document then defines a general > protocol for discovery, synchronization and negotiation, while the > technical objectives for specific scenarios are to be described in > separate documents. An Appendix briefly discusses existing protocols > with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu Mar 9 19:06:34 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8988E129543 for ; Thu, 9 Mar 2017 19:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ETuHaHWfl49U for ; Thu, 9 Mar 2017 19:06:21 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E7A12953C for ; Thu, 9 Mar 2017 19:06:21 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id b129so33593102pgc.2 for ; Thu, 09 Mar 2017 19:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BkkIAfeflN/TTB6W3dzdxtOd0v9xbl5iH9RwpGo0QEY=; b=UjZ819z7z52xpTcg55HLSaxuiUuD5lE4VzKU6Lze/8dQzaj8Olj+wd3P0dTu1Z53+r Jpdk5e8G+xI15l3I+vYp4ArRnXSbF+cBkTYa9NaBEAnUsOnKRvTQqqUR0ASEXiwo5XmW SRznZYYPinjOUmvzTSrrEryHwu6ufKO+qOKuve6e1JBXOP2DOV7V2R8SP4yrDDfCpC1J Qe+PuKq19fKOGwTXy9LS//6zUwLNw+B9/0k1mj+0gjoUDG+SseyxYLnbCVkZ2ahEqFTt OWiaSbiuBZ5qMJxiEf2geG3cs+NUh0VhwDLeaHhkaoUMnDwp9aK0740jX+9u6GouNwgg zYnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BkkIAfeflN/TTB6W3dzdxtOd0v9xbl5iH9RwpGo0QEY=; b=IUMiG3x/7lufpDfLujQ51GdZYKoxTlXDzb9ewWdVVd8UVMAG1Aj/wbhyDvUqw1ihhT LZJ2rbJLWZ7O97OZlzrE1WkJz9ilY8iEAUHwzW1hejvZEV7ig7EuF3FmLJADfxpPFOoq QbWJzHAZilGAhD1DC78StppxlWkHgRs7rD8f478D612j9aOS5ADPH/qjJOzhBrkadsHo Yd4GW4FMi5BWCQJ+Egh6njweIYevf0Ew0jKpOIbijJSOcQnge+d53gzWnUS07+8KkkvB xP5PGdktvVrPcixen+iLfk8ngqJocqJH4vOkEdHwv3UNCD9zMp1u48LOj/f+Wewy9kJv 9r/g== X-Gm-Message-State: AMke39lx7JL/oBp3AMjPJaoZ/O4oXzmHcxWhnQ4fJluPMSVRt3MUED72uOEL/8GhHBswGw== X-Received: by 10.99.98.2 with SMTP id w2mr17596579pgb.103.1489115180552; Thu, 09 Mar 2017 19:06:20 -0800 (PST) Received: from ?IPv6:2406:e007:4e09:1:28cc:dc4c:9703:6781? ([2406:e007:4e09:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r4sm15029759pgr.53.2017.03.09.19.06.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 19:06:20 -0800 (PST) References: <148911446089.5796.6269029296262809928@ietfa.amsl.com> To: anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <74955a6c-4692-d2a6-205b-96b6f0e2bf7d@gmail.com> Date: Fri, 10 Mar 2017 16:06:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148911446089.5796.6269029296262809928@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-prefix-management-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 03:06:26 -0000 Hi, We have made a few small updates to make the text more precise. We believe this should be ready for WG Last Call as Informational. Regards Brian + co-authors On 10/03/2017 15:54, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : Autonomic IPv6 Edge Prefix Management in Large-scale Networks > Authors : Sheng Jiang > Zongpeng Du > Brian Carpenter > Qiong Sun > Filename : draft-ietf-anima-prefix-management-03.txt > Pages : 14 > Date : 2017-03-09 > > Abstract: > This document describes an autonomic solution for IPv6 prefix > management at the edge of large-scale ISP networks. An important > purpose of the document is to use it for validation of the design of > various components of the autonomic networking infrastructure. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-prefix-management/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-prefix-management-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-prefix-management-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Mar 10 01:39:17 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7851294BB for ; Fri, 10 Mar 2017 01:39:16 -0800 (PST) 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 alDyrDnlN2pF for ; Fri, 10 Mar 2017 01:39:15 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71B31294B5 for ; Fri, 10 Mar 2017 01:39:14 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id n11so6263537wma.1 for ; Fri, 10 Mar 2017 01:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=hB6v/FzfZT7tPXLJ+CuBF0f7fMfJiTJ4BoRr4WgM1hg=; b=VPsMmJhMWz+vbBrq2FXpvoGPhfW2LPK4/LN59/wAsBPmTZ82hGGa5IGvV1ZbJa6qJT rX/ZojNDuMhOKP/2TIMC4H7pc1CDmEIAdSAUqMNdW7lGQnGBADxVQsXzC/7szMJhjyMq O2Uc6Duc3YjYzRlPNuonYYjIy9CdozY422y1oTBVJ02aepoYOv3M3wjYtwI3nz18YdxM 2hUUCoq9+5znobtQe6ZXbTHtwvnNXXdJYJLsYultysTeN1GojUOGozgMgfIKhVBot6aa xTeXPN8lrGiYiJlNcQJYQXirZKCKjOqGE3kw24wFaVMraxVWARUNiaPnda5LQyhLj3hB CDMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hB6v/FzfZT7tPXLJ+CuBF0f7fMfJiTJ4BoRr4WgM1hg=; b=eHpJQDxqOAUAfXvb7jmeEmdIeAbv3MZXxQcthUpF0aOBDrKXwikhfmtbwJJIh0ioHj 9toKdtRP0uxT0MK3LYc1xatnHamB2Jo1Z7lSGejHHFywrIo8VMcVOkpRFGAysqX7+ksM 8IdlJ+WLsLA7kSVVs5el6CDy6o1CVVzNkk+hiiSi1Xxk1wz+nRRSRTsK4+fJ5sMhbVt+ 0XvlqKWD0NDUzgk1Z90D/ANu+xnjQPHYfe9ZXEsLwGgoAUKlIyhvIpfKlnarrtrbtO1F u/aAUX3AhGAk9NTcNzHcBrgEFl1QR0ht01nEBXhsYrBn/0KLDSDHtjy2kd2+eL8KIThI DZ1w== X-Gm-Message-State: AFeK/H0G/QjjTqcUMzr1HrOSS083XavStlNMx4y6J59JfkMm1GVlptlLrQrjQ1Ne7JpEBQ== X-Received: by 10.28.199.206 with SMTP id x197mr1503291wmf.5.1489138752990; Fri, 10 Mar 2017 01:39:12 -0800 (PST) Received: from [192.168.1.58] (ANice-652-1-365-58.w83-201.abo.wanadoo.fr. [83.201.200.58]) by smtp.gmail.com with ESMTPSA id 63sm2467918wmg.22.2017.03.10.01.39.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 01:39:12 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: anima@ietf.org References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> Message-ID: <3e20bb52-395a-567e-01fe-081b74f660d1@gmail.com> Date: Fri, 10 Mar 2017 10:39:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 09:39:16 -0000 On 09/03/2017 20:37, Brian E Carpenter wrote: > On 10/03/2017 05:53, Barry Leiba wrote: >>> > Personal opinion: encryption should be a MUST. >>> >>> I believe that we will have situations where we have a secured ACP into a NOC >>> (to an edge router or VM hypervisor), and then we will have some unencrypted, >>> but secured links to platforms in transition. >>> >>> It will be easy to add the GRASP daemon to answer resource requests to the >>> platform, but hard to add the ACP to that platform without a forklift >>> upgrade. >>> >>> This is why I think it is a SHOULD, as much as I want it to transition to >>> being a MUST. >> This brings up a common rant that I have: >> We should be putting into our protocol specs what we want the protocol >> to be, not some compromise that comes from knowing that not everyone >> will comply with everything from the start. >> >> If the right thing is to say "MUST encrypt", but we know there'll be a >> transition period during which that's not fully practical, then we >> should say that. Something like this added to Section 3.5.1: >> >> NEW >> In some cases there will be a transition period, in which it might not >> be practical to run with strong encryption right away. It's important >> to keep this period as short as possible, and to upgrade to a fully >> encrypted setup as soon as possible. >> END > or perhaps more precisely: > > During initialization of nodes there will be a transition period... > > Whether this is phrased as an exception to the MUST or as the justification > for ignoring the SHOULD is a matter of taste, I think. Confused about this last comment. MichaelR pointed out the case of a legacy network management platform, where you can easily add GRASP, but not ACP support. I concur with this view: We saw this a lot in customer deployment discussions. When you say "during initialization of nodes", Brian, do you mean of management stations or of nodes out there in the network? In my understanding I would have written something like "until network management systems can be upgraded to full ACP support ..." What am I missing? Michael From nobody Fri Mar 10 02:45:10 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F064C1294BA for ; Fri, 10 Mar 2017 02:45:08 -0800 (PST) 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 51pvzuUG8OCd for ; Fri, 10 Mar 2017 02:45:07 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 96D7312711D for ; Fri, 10 Mar 2017 02:45:07 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id v203so2423849wmg.0 for ; Fri, 10 Mar 2017 02:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Ib6NAHbifEVIvkAIhbqMz+wzKCipI1Xr2dXl2caXOIk=; b=KL4WQcaJJCvgYthOQss7XBND4zgag0LbPq0xBSqPPFBlAWskToRqAP/UkgsSQxHVYu btqNM4Z8Fph6KuxjvyW0zOi1oSptbjoIOf74IY1heRFKDCoqDdRPgxA0iva0MuPLbkUV wOv+Efcwcv0gsJPrJ/Rdhsjk1b7C19+W0cbiEB/WHCJGm9YMORhk7PmMJZkLg8A5uB2t fess53ibEoEv2cvibVDsY4wKgWNuPp6M8opqXRdpf8t5JvGgOkxZwUx1pcAksSIk0dO1 9NkgWc2oOoiKHSYjRWeUVGD5SXDPwQhCC+ToaQkqQksYqEIjJWuOuz8iyZhm68XKM2pn mSwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Ib6NAHbifEVIvkAIhbqMz+wzKCipI1Xr2dXl2caXOIk=; b=XbNNMlkRM1u9HHwmt15gjJ+RB5+VFLseL40OEVkbvSaT3ZZ7EXjADhCFFdakIr1GXA EV8Ph10VEpV/MgKDNBN3hWEeUY9FWDDlvnZbyehiu5RDuLrYxoJtLkhtVo3kUL0s5wSM 2CIa6buUws3KJ/J9dkyrneM8Z0zGVAAxlcN5oIQYiqFskM6mtQxdG6CiVFZ+6Wnji4u/ pLntqAsgWsQiopTHgNyCGn8zZVDu7NZzjbnwNX1q/9TtRBfV0M+WKE1Un15v6lZg/ElM MJz2eL2bpz7AN+iQT3Y+FHfD0nqwGnep2dpi4KL9mLq7qhF4517KZ+NElhX+CL/F6iaX As4A== X-Gm-Message-State: AFeK/H0i+mCAdOjXx1X1K0/kPD+kIBz7Ddww32sXt7Ghgy+JFwofXcXRuP6JVfCFFHc8qA== X-Received: by 10.28.195.197 with SMTP id t188mr1950982wmf.61.1489142706004; Fri, 10 Mar 2017 02:45:06 -0800 (PST) Received: from [192.168.1.58] (ANice-652-1-365-58.w83-201.abo.wanadoo.fr. [83.201.200.58]) by smtp.gmail.com with ESMTPSA id y4sm2737002wmy.5.2017.03.10.02.45.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 02:45:04 -0800 (PST) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: "anima@ietf.org" Message-ID: Date: Fri, 10 Mar 2017 11:45:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 10:45:09 -0000 There was a discussion about the term factory reset, and what it means. Specifically, whether the LDevID (domain certificate) is deleted. The notes I have taken (from someone's mail) indicate: type 1: erase all but LDevID - Device doesn’t need to re-enrol type 2: erase all, including LDevID While trying to work this into the reference draft, I'm getting less and less comfortable with the sentiment of "two types of factory re-set". Here my thinking: - Factory reset brings a device back to the state it had when it left the factory. This is very unambiguous, and clear. The device will keep its IDevID and the LDevID will be deleted. (may be worth noting in the reference draft though, to be sure). - A process where the LDevID remains on the device in my view of the world is therefore NOT a factory reset. I would call this "erase device configuration except the LDevID". I therefore suggest to use / define the term "factory reset" as per first bullet above. And NOT define two types of factory reset. It just feels wrong to me. What am I missing? Why did we even need a term for the second? Can we not just say "delete config, but leave LDevID"? Michael From nobody Fri Mar 10 04:05:48 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A81129891 for ; Fri, 10 Mar 2017 04:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=osram.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 Xv_5hJnYbOfr for ; Fri, 10 Mar 2017 04:05:45 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0078.outbound.protection.outlook.com [104.47.2.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6769912954A for ; Fri, 10 Mar 2017 04:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osram.onmicrosoft.com; s=selector1-osram-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zJIhHthgthTDbHShB7Jpad5iCXF0p0e4OAqpcF6HpTk=; b=TOPr0JBYODO/1herau3EscOH5SjbF817dHehpesDvgXReXxONxzeTgQ6+5b0mNhRe8K5J9O2bV5oBokWBWi2Enywarky+Tedei4SJPqTF++lC1khZdVJruLS0b3uw9Be9QKOF4vyp8ird1RMkmqWi53A5zD6jp2u+DC6DzZqTL4= Received: from HE1PR07MB1657.eurprd07.prod.outlook.com (10.166.124.135) by HE1PR07MB1658.eurprd07.prod.outlook.com (10.166.124.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Fri, 10 Mar 2017 12:05:42 +0000 Received: from HE1PR07MB1657.eurprd07.prod.outlook.com ([10.166.124.135]) by HE1PR07MB1657.eurprd07.prod.outlook.com ([10.166.124.135]) with mapi id 15.01.0961.018; Fri, 10 Mar 2017 12:05:42 +0000 From: "Beck, Stefan" To: "Michael H. Behringer" , "anima@ietf.org" Thread-Topic: [Anima] Factory reset: Do we need two types? Thread-Index: AQHSmYtl6eVzf41AcE2wm2yt9DbZWqGN9fwQ Date: Fri, 10 Mar 2017 12:05:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=osram.com; x-originating-ip: [32.66.115.43] x-microsoft-exchange-diagnostics: 1; HE1PR07MB1658; 7:3Gy1sqH6+6lM8rFEv3fXWitzKpeDfSD6SdVcjBHO5p1LTok0j8C/EcBY+MVSx8Z0oakgywWmC4rS845FxqTGq5XbsY0GizYS9gvP+R+mwz5Cv9V44K8o6Q9ftys1Hw2wOuk03iojZ11QCgkk9k0KbUi22T+njA7mtfM13f9AbDGhuVoCwmHYkiI2ko1wKcrtjO8XHFOP5c+omGkegFw7TW8CrP6oelbq2P3SDxRc+BinWthTOV01jEeAEG0nsghhnkFVqoiLF+zy+6L1wgi3fOavTMxYtxxLe/oM/weJydAU7PsuLHL5tc2iJSuAKY0KPPEF9u9yj8PvDwkEmQpwJQ== x-ms-office365-filtering-correlation-id: e81f1643-b3d5-493c-fcd7-08d467adc686 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR07MB1658; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:HE1PR07MB1658; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1658; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39840400002)(39450400003)(39410400002)(57704003)(13464003)(377454003)(50986999)(54356999)(76176999)(25786008)(106116001)(33656002)(86362001)(53546006)(39060400002)(66066001)(55016002)(6506006)(305945005)(74316002)(7736002)(6436002)(6306002)(99286003)(9686003)(5660300001)(7696004)(229853002)(77096006)(8936002)(81166006)(2501003)(8676002)(68736007)(122556002)(6246003)(3660700001)(53936002)(3280700002)(6116002)(38730400002)(2950100002)(189998001)(2900100001)(102836003)(3846002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1658; H:HE1PR07MB1657.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 12:05:41.6074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1658 Archived-At: Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:05:48 -0000 SSBhZ3JlZSB3aXRoIE1pY2hhZWwgLSBvbmx5ICJ0eXBlIDIiIHNob3VsZCBiZSB0ZXJtZWQgYXMg ImZhY3RvcnkgcmVzZXQiLg0KDQoidHlwZSAxIiByZWFkcyB0byBtZSBhczogIlJlc2V0IGEgZGV2 aWNlIHRvIGl0cyBkZWZhdWx0IHNldHRpbmdzLCBidXQga2VlcCBpdCBpbiB0aGUgZG9tYWluIGl0 IHdhcyBlbnJvbGxlZCB0byIuDQpUaGlzIGluY2x1ZGVzIGtlZXBpbmcgdGhlIExEZXZJRCwgYnV0 IGFsc28gb3RoZXIgZGF0YSBzdWNoIGFzIHRoZSB0cnVzdCBhbmNob3IocykuDQoNClN0ZXZpZQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5pbWEgW21haWx0bzphbmltYS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWljaGFlbCBILiBCZWhyaW5nZXINClNlbnQ6 IEZyaWRheSwgTWFyY2ggMTAsIDIwMTcgMTE6NDUgQU0NClRvOiBhbmltYUBpZXRmLm9yZw0KU3Vi amVjdDogW0FuaW1hXSBGYWN0b3J5IHJlc2V0OiBEbyB3ZSBuZWVkIHR3byB0eXBlcz8NCg0KVGhl cmUgd2FzIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgdGVybSBmYWN0b3J5IHJlc2V0LCBhbmQgd2hh dCBpdCBtZWFucy4gDQpTcGVjaWZpY2FsbHksIHdoZXRoZXIgdGhlIExEZXZJRCAoZG9tYWluIGNl cnRpZmljYXRlKSBpcyBkZWxldGVkLg0KDQpUaGUgbm90ZXMgSSBoYXZlIHRha2VuIChmcm9tIHNv bWVvbmUncyBtYWlsKSBpbmRpY2F0ZToNCiAgIHR5cGUgMTogZXJhc2UgYWxsIGJ1dCBMRGV2SUQg LSBEZXZpY2UgZG9lc27igJl0IG5lZWQgdG8gcmUtZW5yb2wNCiAgIHR5cGUgMjogZXJhc2UgYWxs LCBpbmNsdWRpbmcgTERldklEDQoNCldoaWxlIHRyeWluZyB0byB3b3JrIHRoaXMgaW50byB0aGUg cmVmZXJlbmNlIGRyYWZ0LCBJJ20gZ2V0dGluZyBsZXNzIGFuZCBsZXNzIGNvbWZvcnRhYmxlIHdp dGggdGhlIHNlbnRpbWVudCBvZiAidHdvIHR5cGVzIG9mIGZhY3RvcnkgcmUtc2V0Ii4NCg0KSGVy ZSBteSB0aGlua2luZzoNCi0gRmFjdG9yeSByZXNldCBicmluZ3MgYSBkZXZpY2UgYmFjayB0byB0 aGUgc3RhdGUgaXQgaGFkIHdoZW4gaXQgbGVmdCB0aGUgZmFjdG9yeS4gVGhpcyBpcyB2ZXJ5IHVu YW1iaWd1b3VzLCBhbmQgY2xlYXIuIFRoZSBkZXZpY2Ugd2lsbCBrZWVwIGl0cyBJRGV2SUQgYW5k IHRoZSBMRGV2SUQgd2lsbCBiZSBkZWxldGVkLiAobWF5IGJlIHdvcnRoIG5vdGluZyBpbiB0aGUg cmVmZXJlbmNlIGRyYWZ0IHRob3VnaCwgdG8gYmUgc3VyZSkuDQotIEEgcHJvY2VzcyB3aGVyZSB0 aGUgTERldklEIHJlbWFpbnMgb24gdGhlIGRldmljZSBpbiBteSB2aWV3IG9mIHRoZSB3b3JsZCBp cyB0aGVyZWZvcmUgTk9UIGEgZmFjdG9yeSByZXNldC4gSSB3b3VsZCBjYWxsIHRoaXMgImVyYXNl IGRldmljZSBjb25maWd1cmF0aW9uIGV4Y2VwdCB0aGUgTERldklEIi4NCg0KSSB0aGVyZWZvcmUg c3VnZ2VzdCB0byB1c2UgLyBkZWZpbmUgdGhlIHRlcm0gImZhY3RvcnkgcmVzZXQiIGFzIHBlciBm aXJzdCBidWxsZXQgYWJvdmUuIEFuZCBOT1QgZGVmaW5lIHR3byB0eXBlcyBvZiBmYWN0b3J5IHJl c2V0LiBJdCBqdXN0IGZlZWxzIHdyb25nIHRvIG1lLg0KDQpXaGF0IGFtIEkgbWlzc2luZz8gV2h5 IGRpZCB3ZSBldmVuIG5lZWQgYSB0ZXJtIGZvciB0aGUgc2Vjb25kPyBDYW4gd2Ugbm90IGp1c3Qg c2F5ICJkZWxldGUgY29uZmlnLCBidXQgbGVhdmUgTERldklEIj8NCg0KTWljaGFlbA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGlu ZyBsaXN0DQpBbmltYUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hbmltYQ0K From nobody Fri Mar 10 08:06:56 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56881129664 for ; Fri, 10 Mar 2017 08:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 qlMz7vHM81Ij for ; Fri, 10 Mar 2017 08:06:52 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0128.outbound.protection.outlook.com [104.47.38.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE14129661 for ; Fri, 10 Mar 2017 08:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dAY1uk9zXjjt2zDGaO0cEhqIP/wPbX+Ao7r6E5CkThk=; b=WCldut0Gl+lE7zXQ2useb0gIBJiaDKU8AOnZPR3y/gloOt07QN7l2w5r1eQbpaAKlEWwRu0e/wHeRzSLcceNKbJYl8AvTomlF7uQ347MRW9DfbibYO10kmkZ3wT6X7eCzDu2mecDrn3ohV6dXCxh3RUUiLQKvo6H7y4EyDG2WGo= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Fri, 10 Mar 2017 16:06:50 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0961.018; Fri, 10 Mar 2017 16:06:50 +0000 From: Kent Watsen To: "Beck, Stefan" , "Michael H. Behringer" , "anima@ietf.org" Thread-Topic: [Anima] Factory reset: Do we need two types? Thread-Index: AQHSmYtl3FxYxQlALUGphCBIBrmmuKGN+i+A///vjoA= Date: Fri, 10 Mar 2017 16:06:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: osram.com; dkim=none (message not signed) header.d=none;osram.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:GiiWK0SrnpkggBtRxp4tyEmCvKZg+FsLVfzyzawern4ALa9o/cOZrnXnRdQzV9ItRok6H0gROk9WHUfNCGEAgMyc4KGutRd8C7ghYNXDSUsDlXDozeWGU8y4cVGn0dEKGLJPxrq7n4iF5gNZSTxve7+Z3/2dxqOt/Q/BNdZr5CFj0mtTf8fF3Vjxzi3hbshe86caOaGak2cdPVfo8TtR036+pAW3Yr6cJBi+oy0HPPv9Baag+qRGNHCUzm7xiibsKeLcQ8Nhz/y5f0lnm7TXjb6JjwWNAZbaFZReqD7uvZTAmEgXCXHhtkAPiqr5Z2oRpxmRZtaZyhTtKmBsn7pLWA== x-ms-office365-filtering-correlation-id: a1c282f5-26b7-4ac2-2b8e-08d467cf7659 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39840400002)(39410400002)(39850400002)(377454003)(13464003)(57704003)(229853002)(36756003)(77096006)(6486002)(66066001)(83716003)(106116001)(6506006)(122556002)(6436002)(189998001)(305945005)(7736002)(2900100001)(25786008)(39060400002)(2906002)(2501003)(86362001)(8936002)(2950100002)(8676002)(33656002)(81166006)(5660300001)(53936002)(3280700002)(6512007)(3660700001)(54356999)(53546006)(76176999)(3846002)(102836003)(99286003)(6246003)(82746002)(50986999)(6306002)(38730400002)(83506001)(4001350100001)(6116002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2DB8EB3553D5724D975804FB45F43929@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 16:06:50.5185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:06:54 -0000 QWxzbyBhZ3JlZSwgZmFjdG9yeSByZXNldCBvbmx5IG1lYW5zIG9uZSB0aGluZy4NCg0KSy4NCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQoNCkkgYWdyZWUgd2l0aCBNaWNoYWVsIC0g b25seSAidHlwZSAyIiBzaG91bGQgYmUgdGVybWVkIGFzICJmYWN0b3J5IHJlc2V0Ii4NCg0KInR5 cGUgMSIgcmVhZHMgdG8gbWUgYXM6ICJSZXNldCBhIGRldmljZSB0byBpdHMgZGVmYXVsdCBzZXR0 aW5ncywgYnV0IGtlZXAgaXQgaW4gdGhlIGRvbWFpbiBpdCB3YXMgZW5yb2xsZWQgdG8iLg0KVGhp cyBpbmNsdWRlcyBrZWVwaW5nIHRoZSBMRGV2SUQsIGJ1dCBhbHNvIG90aGVyIGRhdGEgc3VjaCBh cyB0aGUgdHJ1c3QgYW5jaG9yKHMpLg0KDQpTdGV2aWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE1pY2hhZWwgSC4gQmVocmluZ2VyDQpTZW50OiBGcmlkYXksIE1hcmNoIDEwLCAyMDE3 IDExOjQ1IEFNDQpUbzogYW5pbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFtBbmltYV0gRmFjdG9yeSBy ZXNldDogRG8gd2UgbmVlZCB0d28gdHlwZXM/DQoNClRoZXJlIHdhcyBhIGRpc2N1c3Npb24gYWJv dXQgdGhlIHRlcm0gZmFjdG9yeSByZXNldCwgYW5kIHdoYXQgaXQgbWVhbnMuIA0KU3BlY2lmaWNh bGx5LCB3aGV0aGVyIHRoZSBMRGV2SUQgKGRvbWFpbiBjZXJ0aWZpY2F0ZSkgaXMgZGVsZXRlZC4N Cg0KVGhlIG5vdGVzIEkgaGF2ZSB0YWtlbiAoZnJvbSBzb21lb25lJ3MgbWFpbCkgaW5kaWNhdGU6 DQogICB0eXBlIDE6IGVyYXNlIGFsbCBidXQgTERldklEIC0gRGV2aWNlIGRvZXNu4oCZdCBuZWVk IHRvIHJlLWVucm9sDQogICB0eXBlIDI6IGVyYXNlIGFsbCwgaW5jbHVkaW5nIExEZXZJRA0KDQpX aGlsZSB0cnlpbmcgdG8gd29yayB0aGlzIGludG8gdGhlIHJlZmVyZW5jZSBkcmFmdCwgSSdtIGdl dHRpbmcgbGVzcyBhbmQgbGVzcyBjb21mb3J0YWJsZSB3aXRoIHRoZSBzZW50aW1lbnQgb2YgInR3 byB0eXBlcyBvZiBmYWN0b3J5IHJlLXNldCIuDQoNCkhlcmUgbXkgdGhpbmtpbmc6DQotIEZhY3Rv cnkgcmVzZXQgYnJpbmdzIGEgZGV2aWNlIGJhY2sgdG8gdGhlIHN0YXRlIGl0IGhhZCB3aGVuIGl0 IGxlZnQgdGhlIGZhY3RvcnkuIFRoaXMgaXMgdmVyeSB1bmFtYmlndW91cywgYW5kIGNsZWFyLiBU aGUgZGV2aWNlIHdpbGwga2VlcCBpdHMgSURldklEIGFuZCB0aGUgTERldklEIHdpbGwgYmUgZGVs ZXRlZC4gKG1heSBiZSB3b3J0aCBub3RpbmcgaW4gdGhlIHJlZmVyZW5jZSBkcmFmdCB0aG91Z2gs IHRvIGJlIHN1cmUpLg0KLSBBIHByb2Nlc3Mgd2hlcmUgdGhlIExEZXZJRCByZW1haW5zIG9uIHRo ZSBkZXZpY2UgaW4gbXkgdmlldyBvZiB0aGUgd29ybGQgaXMgdGhlcmVmb3JlIE5PVCBhIGZhY3Rv cnkgcmVzZXQuIEkgd291bGQgY2FsbCB0aGlzICJlcmFzZSBkZXZpY2UgY29uZmlndXJhdGlvbiBl eGNlcHQgdGhlIExEZXZJRCIuDQoNCkkgdGhlcmVmb3JlIHN1Z2dlc3QgdG8gdXNlIC8gZGVmaW5l IHRoZSB0ZXJtICJmYWN0b3J5IHJlc2V0IiBhcyBwZXIgZmlyc3QgYnVsbGV0IGFib3ZlLiBBbmQg Tk9UIGRlZmluZSB0d28gdHlwZXMgb2YgZmFjdG9yeSByZXNldC4gSXQganVzdCBmZWVscyB3cm9u ZyB0byBtZS4NCg0KV2hhdCBhbSBJIG1pc3Npbmc/IFdoeSBkaWQgd2UgZXZlbiBuZWVkIGEgdGVy bSBmb3IgdGhlIHNlY29uZD8gQ2FuIHdlIG5vdCBqdXN0IHNheSAiZGVsZXRlIGNvbmZpZywgYnV0 IGxlYXZlIExEZXZJRCI/DQoNCk1pY2hhZWwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkFuaW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWlsaW5nIGxpc3QN CkFuaW1hQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Fu aW1hDQoNCg0K From nobody Fri Mar 10 08:45:53 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA81295FD; Fri, 10 Mar 2017 08:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 pgg1Tw7BUijR; Fri, 10 Mar 2017 08:45:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E991F12949E; Fri, 10 Mar 2017 08:45:45 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 78A82E20F; Fri, 10 Mar 2017 12:08:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2573F6381A; Fri, 10 Mar 2017 11:45:44 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:45:47 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> NEW In some cases there will be a transition period, in which it might >> not be practical to run with strong encryption right away. It's >> important to keep this period as short as possible, and to upgrade to >> a fully encrypted setup as soon as possible. END > or perhaps more precisely: > During initialization of nodes there will be a transition period... Brian, by "initialization", do you mean bootstrapping? > Whether this is phrased as an exception to the MUST or as the > justification for ignoring the SHOULD is a matter of taste, I think. I am saying that there will be a period where legacy NOC elements will be placed into a kind of "ACP container" --- the ACP encryption will not extended into the "operating system" where the NOC element is, but likely terminated "in the stack" or "in the wire". (cf: Bump in the Stack, Bump in the Wire https://tools.ietf.org/html/rfc4301#section-3.3 ) >> or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the >> possibilities are understood and folks are OK with it. > My thought was that these names will sometimes be visible to humans so > why not allow localized names? If GRASP succeeds it might be used for > local applications, not just generic applications. So I'd rather allow > it from the start, and if we have to add character-set restrictions > later, so be it. Barry, is there a way to say, "UTF-8 without all the confusing parts"? Is that what IDNxxxx is all about? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljC2DcACgkQgItw+93Q 3WW0owgAksTbPRz7ZbphxU7q48/gfrLs6QTUhc5fA0nScKCYQYYhM20LQ3ZPEeOS bAKmZg4Zoi/nDEw+nvzGmMijaAlz3TjOG50RfVWPfSmrU3RDNHgvV4E3zj3ZsymH kT6KhI7goxWZOCZEtfqV+THMtoiAm27nnMv/+Py6owlf2+iOVgZOkFcBMr0hRC+1 b56BTHLvIO/aXnzeuxtXslfF+h4LwaaK2xaOHeCfoY49BYTW8x9eRfSLyl+5tUMM r/bNKKCUaGNQrpR8GsGx86aSKaGzuolRZCh1RGq1sqN2iaHSpG3YgW93k7evaq9T UR3bS8MxTMPN+W6zO3DmFTEYsVxZgQ== =0lFs -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 10 08:47:40 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF25129669 for ; Fri, 10 Mar 2017 08:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=osram.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 hp25BrfL1efi for ; Fri, 10 Mar 2017 08:47:34 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0084.outbound.protection.outlook.com [104.47.1.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B615812940A for ; Fri, 10 Mar 2017 08:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osram.onmicrosoft.com; s=selector1-osram-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=96EVtoAVNMkINPtUdKsaUtjS6KcFqhuAkUKsxq49QFE=; b=CfQAUTkJY3ocbu2tzbTgLXCEhpaWWMmQT+1PHqyJwsW58UDQ5h5i1yrYk2HxnyW8Y9VEJrItAW8fJT8K9wLfqIdPQQBt84dw/+N8YMBuWW/XhziSBPEwyks8Ccu07KpnNdNd+O5rCqyjmIYoxIck4Zldl1ZzAA0676GIitY3EwY= Received: from HE1PR07MB1657.eurprd07.prod.outlook.com (10.166.124.135) by HE1PR07MB1657.eurprd07.prod.outlook.com (10.166.124.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Fri, 10 Mar 2017 16:47:30 +0000 Received: from HE1PR07MB1657.eurprd07.prod.outlook.com ([10.166.124.135]) by HE1PR07MB1657.eurprd07.prod.outlook.com ([10.166.124.135]) with mapi id 15.01.0961.018; Fri, 10 Mar 2017 16:47:30 +0000 From: "Beck, Stefan" To: Kent Watsen , Eliot Lear , Anima WG Thread-Topic: [Anima] CRLs in iDevID manufacturer signing certs? Thread-Index: AQHSmOHhMGc8KNzI0U+IWJ9zRs58PqGM0z2AgAABCQCAAA1YgIABOjBA Date: Fri, 10 Mar 2017 16:47:29 +0000 Message-ID: References: <4D0FFE5F-52E3-40E9-A1CB-1E791F0A8458@juniper.net> <04614977-f700-711c-8ccd-47740cffefbd@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=osram.com; x-originating-ip: [32.66.115.43] x-microsoft-exchange-diagnostics: 1; HE1PR07MB1657; 7:GcWjS5UWK0OIoVNvQKC7aDWYBdgV10E/tTyWc6tVpT5Z9Edyn/GGHHwrOubFtkpbUkaNSSC3nbHEvkN+SuLz8vLAth1MOw2dBa/EBGRsHO1uWUppMx9Fdig/CF+CpRdz/0GWO7iSKEGf+/VTnnWdFGROObgq41DnHut8E2TbOkfN6YiNvbSjPTaj3B20b39NSnng/BdTfKRS3IgAtF57DxiMwBlsL7nnI9320d0frthJFlfePG+7qvf0LA7keKocWHbAT2FicIoT3JmviJH8RigZ9oFh9ieGr1nqcchSr7w5ZhifDrnCVtibxWoncFUSj4fA9kWGJoyzlNbJNGAuJw== x-ms-office365-filtering-correlation-id: 830524ab-58b2-41da-a14c-08d467d52446 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR07MB1657; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:HE1PR07MB1657; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1657; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(13464003)(24454002)(377454003)(305945005)(86362001)(7736002)(122556002)(2906002)(66066001)(81166006)(189998001)(55016002)(8936002)(9686003)(99286003)(93886004)(8676002)(8666007)(6306002)(3846002)(1941001)(74316002)(6246003)(50986999)(76176999)(102836003)(2950100002)(99936001)(53546006)(6436002)(3280700002)(54356999)(5660300001)(6116002)(53936002)(38730400002)(25786008)(2900100001)(7696004)(33656002)(6506006)(106116001)(77096006)(229853002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1657; H:HE1PR07MB1657.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01D299C6.62518650" MIME-Version: 1.0 X-OriginatorOrg: Osram.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 16:47:29.8014 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ec1ca250-c234-4d56-a76b-7dfb9eee0c46 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1657 Archived-At: Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:47:36 -0000 ------=_NextPart_000_0055_01D299C6.62518650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Kent Watsen wrote: > My view is that, if the IDevID has a CRL/OCSP URL listed, then the > validator SHOULD do the checking. > If the vendor didn't actually want revocation checking done, then the > vendor should've excluded such information from their IDevID certs. I agree, it should say SHOULD. > the likelihood of the credentials being stolen/discovered are near zero, > but it is not zero, as a determined adversary with sufficient resources > can still have their way with it. Also, if some general or implementation vulnerabilities are discovered in the used crypto processors/ Tamper-resistant NVRAM, the likelihood may become significantly higher than "near zero". > vendors face a more likely scenario, of issues occurring by contract > manufacturers, whether it be accidental or intentional. I agree. As there may be more & diverse such scenarios one can also think of mapping those issues to well-defined revocation reasons (keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn, and aACompromise). This would allow for more detailed decisions during enrollment (or re-enrollment after factory reset) in the local domain. Stevie -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Thursday, March 09, 2017 8:17 PM To: Eliot Lear ; Anima WG Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? My view is that, if the IDevID has a CRL/OCSP URL listed, then the validator SHOULD do the checking. If the vendor didn't actually want revocation checking done, then the vendor should've excluded such information from their IDevID certs. FWIW, 802.1AR takes a much neutral stance in Section 6.5.3 (Validation of DevIDs): The DevID is an X.509 credential and can be validated using the RFC 5280 defined mechanisms. IDevIDs are intended to have very long validity periods even exceeding what would normally be cryptographically acceptable. The manufacturer is not required to provide a Certificate Revocation List (CRL) although the validator may do CRL checking if the manufacturer provides CRLs. The validator may verify CRLs for LDevIDs as necessary. Kent -----ORIGINAL MESSAGE----- Thanks, Kent. Then it seems to me that we have a MAY floating around for CRL checking on the part of the registrar for BRSKI. Right? Eliot On 3/9/17 7:25 PM, Kent Watsen wrote: > Hi Elliot, > > >> What is the thinking on including CRL pointer in the manufacturer >> signing cert? This question came up in industry discussions. > 802.1AR says that the IDevID secrets must be stored confidentially and be not available outside the module. In practice, a crypto processor with tamper-resistant NVRAM is used (e.g., TPM). As such, the likelihood of the credentials being stolen/discovered are near zero, but it is not zero, as a determined adversary with sufficient resources can still have their way with it. Still, vendors will likely conclude that protecting against that level of attack isn't necessary. That said, vendors face a more likely scenario, of issues occurring by contract manufacturers, whether it be accidental or intentional. And as unlikely this scenario may seem, things happen and the vendor would be without recourse if unable to issue revocations. To this extent, setting up the infrastructure to support revocations can be compared to insurance - hopefully you never need it, but when you do, you're glad you have it. > > Kent > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ------=_NextPart_000_0055_01D299C6.62518650 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITQDCCBZcw ggN/oAMCAQICEH2N5rAAeSCGTQvIxSt6cDswDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT8ixk ARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50 MRswGQYDVQQDDBJPU1JBTSBSb290IENBIDIwMTUwHhcNMTUwOTE3MDk0NzMyWhcNNDAwOTE3MDk1 NzI2WjBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQx EzARBgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPOLdsM1I8Fll2DJ5A01Y53Cbq88OH6/ZocCMhm+9Ro Ce4RHnIB+WKi8+4fTUYU3DjwgXiI3tH6YG9j9o3ahkepcaRx1arkNJCfGs8UKbHQnxVM9n5Sv3lp Qm/OyE+qwl8sA77nVvrmAiYDIXdlJajITmqMBiSS5TfS7YO7knMLOv5bzd4ihUizsNGgVIvPyowz NpsA/yYzIJJhSYCdSc9Aji5MDF4fscYaffpdaM3VoZ4gdZiVgcYrnUVR4oFsNkoja6MV3Vk9o5py 8I6ff5Dhc6ZStrjYG1Q9iIIawvvi4e4A6ISRmxw3QBUZtlvBiC8Z2g/XVJnwz91RKIT1lQPbb2Cw 88E1nRVfF1txiVbQXw+TjNnyIVcxZS/p34yHXS9/gmPVXBUx3SYqAMI9vk/mqvkDGPAkIrpILTQT XcxkJVwQukR7mSpRw4bx0bg4mxH1x6tr4HqZe5hFtQTs+VckNiXLF5xFbOjFuck5UBRbW8J3ENCA ohtR/OdOAKFrS7Y5uPLA5ENMt+Ee2LeaEmwUIIioYZuToXngaimCg6m9aIGv9ytMUgnF3+9CRsKr drVw6Er2eKnGOXyBaMOkR14loeFISsA9UL85Ib80MHLZd8t0rkIpThZSKMMS/eKpGyZMv9HLYrVZ 1TssyD8pvu4yzrHGtrtehXu2JfRm+gzdAgMBAAGjRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgECMB0GA1UdDgQWBBRBffSxSuh0TnMOw0EPaZQm3UsWYTANBgkqhkiG9w0BAQsF AAOCAgEAoHwKO+Sh72eofY0BSZ+h+ajR9K7PJnwrLV557s4Id1EIvfMU8geELns5FsKOcAg9ipnv PPt0EVFFGulfyKRa0OPLvz7ofpEF0Bs8LVdAbqtImf9YGAmFtf7zIEdKmtDhGdKNabwt0QbVKOEs IzbQCeKXdFQ6/s0c+aSO/I1wLOekihbY1PY0IzNzDBfIbzDdFgcQfVc+kSlV2sSKjrqpG9qGvvwL VCWSCGFC/nAkb4g4PXhmOEIfo04vaibNHYFyl4ltZiWph/mism4MM1bAvPtZM8fFc1J6Sgkir7vD XQOCpQrxFYAKTqOIhAGn0hY/AY7198X5Jeh/tCUjatDz7AHuhdBTPC+XeGMyzvj7fkVwTv3TazEo u6jpmn6b2QY+0GdVytR4R0KFFIjGvxmOH4gg7pfOwplpjzE3K11CHGsEXQwAZNPnhj/EXEqSdx3g dUX77plIcnE8TwXxoY+aa9p1JfAmKVLT3vZbT8YDm83RkN7vcyGW/NBDq2OyihORutQxuy9PpYaM Txnzp9M620XFwKJbU3D0vYvHOgYFKQy71hgn/AX3KnQ+MXgiRCy5phiSTOTc8SZzuijBV2X30hX+ NAd3M4dQq4/VnK/Zop0LYornrFK79re2RLDqm1NP/k9yAOCc0WR7lQOhFW3R0JgFSmRSMsR4PWGg afjpMSgwggZ1MIIEXaADAgECAhMYAADE1BvnBAMoNJsjAAAAAMTUMA0GCSqGSIb3DQEBCwUAMGcx EzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/IsZAEZFgtvc3JhbS1saWdodDETMBEGCgmS JomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNzdWluZyBDQSAyMDE1MB4XDTE2MTEwMzE1 NTYxMVoXDTIxMTEwMjE1NTYxMVowcjELMAkGA1UEBhMCREUxDjAMBgNVBAoMBU9TUkFNMRwwGgYD VQQLDBNPU1JBTSBHbWJILCBHZXJtYW55MRQwEgYDVQQDDAtTdGVmYW4gQmVjazEfMB0GCSqGSIb3 DQEJARYQUy5CZWNrQG9zcmFtLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKht x104jKLZgCEyi4IKs7QjFm+csCMA3g4nYkhYmv5yK4Jtw6pixicOV4KUypkejZhbWmU+vyD3iY/0 aZ+uvwyNl90CA8fWmKdC1sF7xs7MtYvaQOycf47BTkqAdlOep9iTKxKpEW9B9LchU2iBUdhdQUsy jYrvq3MzPGw5ERW9dSwsXf4M5l3pDmlfPgCAYmEdRop4eUshqh87cr8AfzTm4XEcR7pG6lOgTkFa kZAltl6U3+VHQ2PQj6pw5VRHuaqPunZVFJL8e8kNErDgPkRnY2t12qNIbvxiSri3gSDHlOJJ/kND HHzI2+yOEA70nFfFG0tY6DcXwm8qWmT6uMECAwEAAaOCAg0wggIJMAsGA1UdDwQEAwIF4DA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiCuLoUhdG3QIS5iTOG7K5ahOeweYENxscDgoHuRQIBZAIB CDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4D AgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFKLokmPgby7PzMPWwS913WLd8w7yMB8GA1UdIwQYMBaA FAd1EUQRun6PdD2R16jhaq0s694uMF8GA1UdHwRYMFYwVKBSoFCGTmh0dHA6Ly9wa2kub3NyYW0t bGlnaHQuY29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DUkwvT1NSQU0tSVNTVUlORy1DQS0yMDE1 LmNybDBrBggrBgEFBQcBAQRfMF0wWwYIKwYBBQUHMAKGT2h0dHA6Ly9wa2kub3NyYW0tbGlnaHQu Y29tL09TUkFNLUlTU1VJTkctQ0EtMjAxNS9DZXJ0L09TUkFNLUlTU1VJTkctQ0EtMjAxNS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMBsGA1UdEQQUMBKBEFMuQmVja0Bvc3JhbS5jb20wDQYJKoZIhvcN AQELBQADggIBAAeoZQyM9u1NEpKRRDYMydLJ1wa1Y1m7rDfp5CPp0uni4qS5iXReWgIEzkhNCV5E oC0DosSOqnh2BkAkX+khNPuhLjjM/ApbFIqnnY+RD+xz3fxjx584TFmBugWHvKycYyD5NWhtD6Ej mWv6tUsxjYCv652LruxCdGJDbsaaEKP28te5dwMLD9wqSrBVU6ftbuzb9rL7IatpcBPCDkuCXSSQ lnAefbP2Y73wm1/+tbP/FxgyQjZUFR5qbXl2fMyynsrqLr3c6K7VxZs8+psbd+PiOlQnXcfGGCWR cZxr0cUZP/O861rFlE8s1OpxN5XI2pQIAzJx2toIsmHdk6hOY7t/2lYaMtqQLl2+cd2RoUMijM+1 Yi+v2WwuErdZzmgjTKht8rinng7GAuiSIQB489J4FgOEBWYne8zrl7jyuU9RYcYN9Nc5IZhK2Nfg 0xDh4tWeMWIuCg8f9ubeHOekdrg01cazDavxjaftQ25+2J5EwAWxc4ZPivOD9bkiYknSfg2iih2Y iRxUXqVq0q+qCfVDeys+MSFcu/WetN2ibvouzr+q4Aw+71j6M7FaWWpRz5FFKz40O/wAzoR2WB7u gGuT4RlAb7Yr8zM8TRpHKmrOSi19o/5qbGrPOX3u/B9UjK3LvR0n7TO6J9q0qxKveWlu6cofPQRd 2UVQoaNLB90mMIIHKDCCBRCgAwIBAgITWAAAAAXTK7hm1i4tGAAAAAAABTANBgkqhkiG9w0BAQsF ADBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzAR BgoJkiaJk/IsZAEZFgNpbnQxGzAZBgNVBAMMEk9TUkFNIFJvb3QgQ0EgMjAxNTAeFw0xNTA5MzAx MjM2MTdaFw0yNzA5MzAxMjQ2MTdaMGcxEzARBgoJkiaJk/IsZAEZFgNjb20xGzAZBgoJkiaJk/Is ZAEZFgtvc3JhbS1saWdodDETMBEGCgmSJomT8ixkARkWA2ludDEeMBwGA1UEAwwVT1NSQU0gSXNz dWluZyBDQSAyMDE1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvbRnffh0KvDggawO /LfHMVmHl1fTbjzZQRjbbdUG6aKwTGeIpg7M4RXUIObssQ7sbSxuu77Vz2OFdSf5vk1fVZn8DFD8 dVB2AsYKPWZmBO+CYOvb2NCNqyLnt2/Mlk74gwTXdBgJsNjDbxs6yIfwn+rdGNt3gDwPeTiX+0Rn Ccj1NclFef00nW4kKFr2kkf+tVXMQx3pS7BQAjyuL+coQmOD5vIM+qU4dGy9ndYExTMTOPbDQaAO lx/vPXUSS1FvMJtKz//ODt/yew5RL55ZKuh6Mi7TvGTYcSH989NlXjYIYGQ0/5zfukj6CcscjInX 9W4U6NFvZL8YoVR6RLQkOTtfYa36t/iw16diSlBVeM7wq471fRXpytuGjLVtOl+oGGA7uM1QJ2OH OaXKzb6S28h8/W2urmHWMnSsBioznyio28I1PzyiwQeSe1NuMRobL0wSOTL/wljsxEkapvn4u3oW +SQCNyvXyigIYh+OaKNWFj62GclxPzoWkeT6FD6a6GS6geNyAF04N8fA/P1G/sSSCUcNdLodeEQz 17uSvIxKIFb0t7TgM40vgfwW929cv8hSoEfYQykeuPWPRc8nYkb9y6FSqpWxkXCFZRcVr826I7HY 3c2cfjFytMx4eyE5NzLV8n8jbEG0oM8c1SO1ojT4eQUgJgR2dE0OM6iJi6cCAwEAAaOCAc4wggHK MAsGA1UdDwQEAwIBhjAdBgNVHQ4EFgQUB3URRBG6fo90PZHXqOFqrSzr3i4wgaQGA1UdIASBnDCB mTCBlgYdKwYBBAGCNxUIgri6FIXRt0CEuYkzhuyuWoTnsHkwdTA8BggrBgEFBQcCAjAwHi4ATABl AGcAYQBsACAAcABvAGwAaQBjAHkAIABzAHQAYQB0AGUAbQBlAG4AdAAuMDUGCCsGAQUFBwIBFilo dHRwOi8vcGtpLm9zcmFtLWxpZ2h0LmNvbS9DUFMvaW5kZXguaHRtADASBgNVHRMBAf8ECDAGAQH/ AgEBMB8GA1UdIwQYMBaAFEF99LFK6HROcw7DQQ9plCbdSxZhMFkGA1UdHwRSMFAwTqBMoEqGSGh0 dHA6Ly9wa2kub3NyYW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DUkwvT1NSQU0tUm9v dC1DQS0yMDE1LmNybDBlBggrBgEFBQcBAQRZMFcwVQYIKwYBBQUHMAKGSWh0dHA6Ly9wa2kub3Ny YW0tbGlnaHQuY29tL09TUkFNLVJvb3QtQ0EtMjAxNS9DZXJ0L09TUkFNLVJvb3QtQ0EtMjAxNS5j cnQwDQYJKoZIhvcNAQELBQADggIBACnQrysmPX41U+j/Q33kIHIGxFU0aYS0qrBmzGGGGNamqD8H 2SGy8LdCVcGeecE3XlKzZe+AnTTa1ejhHvhMJc8tHCgMLyvdSxKjJ69Rp75AaknxX15AwuFMkqLQ O+itE0PV6f3QHVdYevo2asZ3UgaQGOBFEo782qiNBDHawzuuXpXUTo4gWntTieXICIXWEenOgin1 901aoM0qzHTd8CXHdN8W7UNOE/6eCH02LofORiL2OzOAaz6aduK76KIEn3Fb2fbFAwKVIgTbvflA 9AWliukXYOSTGg9NXOyUVAE+ti4s720bYAJNrHTSbxbVpkDaWyZOhL/MsDAl3Q5/tMBbykhIy1pA 0zg5Q0QVr7B57x2Yo62nbduruNAnA0t+Q6DOrIRudaboAEeIXsQzVuUKd11o9mDOcVuetRxoS7lN 33zC3IHQajDFs8UHt4z6Cjj3EGttiS+ApUyDztgThD8bq7JSiAcFuXXD7zKmWN4TR6hKqTr9YGqA qhx/Dh7yYGUIOGAQi/EM0X1Ak73R45BopSyUm6oVj9i+w3SVvW66GxHbSUHqj8hA5Mokb9/ZC4Hn r/8CTC6MyfFJgksnMLEnhQOpCCaOzKtJ7UMnSeJHYHQUiDksIY5d3Y2T7QWDww7U95fMtGfPhqbA cF1qh4o9RYzuFWS6puXo7eRS2O1lMYIDwDCCA7wCAQEwfjBnMRMwEQYKCZImiZPyLGQBGRYDY29t MRswGQYKCZImiZPyLGQBGRYLb3NyYW0tbGlnaHQxEzARBgoJkiaJk/IsZAEZFgNpbnQxHjAcBgNV BAMMFU9TUkFNIElzc3VpbmcgQ0EgMjAxNQITGAAAxNQb5wQDKDSbIwAAAADE1DAJBgUrDgMCGgUA oIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAzMTAxNjQ3 MjdaMCMGCSqGSIb3DQEJBDEWBBQYqq/5BvDyYK3oKk9VT/1ViC0pfjCBjgYJKwYBBAGCNxAEMYGA MH4wZzETMBEGCgmSJomT8ixkARkWA2NvbTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMw EQYKCZImiZPyLGQBGRYDaW50MR4wHAYDVQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTU G+cEAyg0myMAAAAAxNQwgZAGCyqGSIb3DQEJEAILMYGAoH4wZzETMBEGCgmSJomT8ixkARkWA2Nv bTEbMBkGCgmSJomT8ixkARkWC29zcmFtLWxpZ2h0MRMwEQYKCZImiZPyLGQBGRYDaW50MR4wHAYD VQQDDBVPU1JBTSBJc3N1aW5nIENBIDIwMTUCExgAAMTUG+cEAyg0myMAAAAAxNQwgZMGCSqGSIb3 DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAID MAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAHThedTVNIxs2gZjm bQvjD61mQ8+Z3yxCY6sgbnSujfa5vZS8cQ4XjQW9WxJx8rlzFdvHta2OZoSNarNFIgzuaqb7TVEm fEgsrpw6AqF23A9nv9pwKri8bG4LFVxeNX/E7EA6016YAXHn4Y3zkgb+ULnkVVvCd350wuHFxaUE +tg+AVB9x0BtUVzIRjkSxnBN2L/I07dSBQqL1B6UhTvZuGgrcduiGdvOD7d+BdxkETzDIX6X4yKF FUY3qjoJ0hOmzMQLC9Ja5XdKuDhi0Ov/yEgbrXtVypO/4ME/XIGYRgo3qih6AOiWsWiM/fiMnoqz zLV84znif0IkCkV6VwnxUgAAAAAAAA== ------=_NextPart_000_0055_01D299C6.62518650-- From nobody Fri Mar 10 10:02:31 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AB51294BE; Fri, 10 Mar 2017 10:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 gkNDRey3UF5Z; Fri, 10 Mar 2017 10:02:18 -0800 (PST) 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 97A941294DD; Fri, 10 Mar 2017 10:02:18 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id w124so495563itb.0; Fri, 10 Mar 2017 10:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yNzzC1AEBBuRX3HEkcYyfVn2YHEgXZxCmVZDk/0RJVA=; b=U2or3/4g8eirCeAtSvMJm8xy8Cqmj3oOs8lBRlFrnpIVSQuSI0vAfUcNrmL7Q6zeIp Y5nnciOAsF3it2WnvTyvHGyM7L5lK/nhUx6UaqgnSBOOVzksmGSsvSBewL6aF3SNaNX0 dNW/qQY2PRHi6q7S944V9tYCfXrN5SYqlXn8+tnsrVAKZ4bCoVfhMzYab2LGcLSa4TJQ S0HdCKGGFFrBgNrJtC3yT01s30/Wdp7/tZzAYOBjGnznxhmADupmsrSUKcAG8smuBys+ tkOYVx9NyEh0JlQLECP0796mGSgUGTCNe8Tmz9plkKfuIK7Fy+kb+qIr/p3fvXVferYg rIRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yNzzC1AEBBuRX3HEkcYyfVn2YHEgXZxCmVZDk/0RJVA=; b=YAOC/IFwqClDQvq+wKxcOzl+/aLgrovTBaiSpOshAZQamz/kAXzhy6lP2vH+9wR1Ds rjFXkvQIq0bG2ovp45L0hFvKEH+dKr/fQPvJkN9Hq8Wk9GScdJbhvlvdzOU8gnPRtvZU gM6Bq0Wb1AvRGZM/+NBA+2j5pKnvGFsixL7JpHFF3m57vFHqt7sTT4IVCAy+oqHtD+A6 8CqfNkB0htUrFUT8RMzpRVSm38Uswh0lqJyPmlIO4oW4CR+irxBOS74AVwnd5KHCrCb5 7jSZ0PN2ML0z923iTLiDzZbh2FjWHmk6RzsK0x+cHonDMIaAdr2Ko28K7vXBxw+wY80x TAkg== X-Gm-Message-State: AFeK/H16fIBL/gcblRTxbxiyQ9VtiC11o3xXF0T5pT6twqVsNzkmlKqCeQWCj9Cle2VqELUENX1TwUZC4bVPgw== X-Received: by 10.36.159.195 with SMTP id c186mr280301ite.32.1489168937970; Fri, 10 Mar 2017 10:02:17 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Fri, 10 Mar 2017 10:02:17 -0800 (PST) In-Reply-To: <31318.1489164344@obiwan.sandelman.ca> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> <31318.1489164344@obiwan.sandelman.ca> From: Barry Leiba Date: Fri, 10 Mar 2017 13:02:17 -0500 X-Google-Sender-Auth: Cx8GmuFN5e78J0IDmvfxd3e23_I Message-ID: To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:02:21 -0000 > Barry, is there a way to say, "UTF-8 without all the confusing parts"? > Is that what IDNxxxx is all about? Kinda-sorta, but it won't quite work for this. The high-order answer is to reference IDNA 2008 (RFC 5892 will do) and say that characters that are PVALID are acceptable here. The trouble with that is that it limits you to lower case characters: all the upper case characters are DISALLOWED. It could work to say "PVALID characters and their upper case versions." But, really, I think Brian's right that we don't need to worry, especially because there's the designated expert in the middle, who can say, "PILE OF POO"? Really? Why do you want to use that character? Barry From nobody Fri Mar 10 11:39:58 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BF11296F2 for ; Fri, 10 Mar 2017 11:39:57 -0800 (PST) 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 iYjZi-AyIlwb for ; Fri, 10 Mar 2017 11:39:55 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 4DFB11295B7 for ; Fri, 10 Mar 2017 11:39:55 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id 67so11803116pfg.2 for ; Fri, 10 Mar 2017 11:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wTSqESMktUiVX44+/NJitFaOBAgSbDE8mPM7NGASlxM=; b=e0JLc1APd9KDY5AQ7fx2DoLtRFo47uiFKM8eKCGdqcrVixIQw9N7AjVkQsIjr7Hr/b Rf3hkRvAChDc1qZic1KydDKw6i56G0YjJaShVMj0vib2COG73oXYpG/obIJF6odaKR/d Ts4y56Q7+z+BYNCRmL/TpRiwA4VUNZJ5QX4Vaf0/AjxKZ/rPeQsEjUMAsRRR4IOAvDde 3d7wMv/hbANEHKllz2N8RJjdf70ohzA47k/ITK7PtTbMHL4Ls4u/pxwapiIH6CDa7NPP TP0gBs5m735p63w1wT2zdsa4xNAA/NXZIrVUMdY1QDebgoxUfHJJHcGauD8JsTgzzKsn SzLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wTSqESMktUiVX44+/NJitFaOBAgSbDE8mPM7NGASlxM=; b=ZObchiWLIfbKbQdLQ/9FRcvWD/jRuP1ZSBuhM0KB+HQBXYIbN5z9JTKP5dBhTltc5y VH/hnhTmeb+4HLrMISMB6/9cDAvN1GS8kUGdFlhCa36lRmbyaZjSP2sh2tRAgUj9nIAY QThjVqj7fuovCw1tT3042qkEbQxksu21BbN27jX5xG2wyYMODU4cnSP5EP/1ikgcmj0a TmkUoF6CQtsX8+DHI3UjZ/yQe3+L+jDAZpmHOd/n4hqlUFQtmpNM3WIrciF5Vu7FYHhh CLChcVIJvnSE8eUyti7dHBMNd3G/kO5ed63be/Ii8BMZeMMQtyzcckChG6g4nOLysexJ l8wg== X-Gm-Message-State: AMke39kyNrZLvA3a1xINqQkcHVDtNREMvxwlhGn46RP+a9RL26oX/FYmg/1epnuAS4rLhw== X-Received: by 10.99.56.85 with SMTP id h21mr22262975pgn.108.1489174794811; Fri, 10 Mar 2017 11:39:54 -0800 (PST) Received: from [192.168.178.26] ([118.149.108.74]) by smtp.gmail.com with ESMTPSA id v86sm20143836pfa.58.2017.03.10.11.39.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 11:39:54 -0800 (PST) To: "Michael H. Behringer" References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> <3e20bb52-395a-567e-01fe-081b74f660d1@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 11 Mar 2017 08:40:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3e20bb52-395a-567e-01fe-081b74f660d1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Barry Leiba , anima@ietf.org Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:39:57 -0000 On 10/03/2017 22:39, Michael H. Behringer wrote: > On 09/03/2017 20:37, Brian E Carpenter wrote: >> On 10/03/2017 05:53, Barry Leiba wrote: >>>> > Personal opinion: encryption should be a MUST. >>>> >>>> I believe that we will have situations where we have a secured ACP into a NOC >>>> (to an edge router or VM hypervisor), and then we will have some unencrypted, >>>> but secured links to platforms in transition. >>>> >>>> It will be easy to add the GRASP daemon to answer resource requests to the >>>> platform, but hard to add the ACP to that platform without a forklift >>>> upgrade. >>>> >>>> This is why I think it is a SHOULD, as much as I want it to transition to >>>> being a MUST. >>> This brings up a common rant that I have: >>> We should be putting into our protocol specs what we want the protocol >>> to be, not some compromise that comes from knowing that not everyone >>> will comply with everything from the start. >>> >>> If the right thing is to say "MUST encrypt", but we know there'll be a >>> transition period during which that's not fully practical, then we >>> should say that. Something like this added to Section 3.5.1: >>> >>> NEW >>> In some cases there will be a transition period, in which it might not >>> be practical to run with strong encryption right away. It's important >>> to keep this period as short as possible, and to upgrade to a fully >>> encrypted setup as soon as possible. >>> END >> or perhaps more precisely: >> >> During initialization of nodes there will be a transition period... >> >> Whether this is phrased as an exception to the MUST or as the justification >> for ignoring the SHOULD is a matter of taste, I think. > > Confused about this last comment. MichaelR pointed out the case of a > legacy network management platform, where you can easily add GRASP, but > not ACP support. I concur with this view: We saw this a lot in customer > deployment discussions. > > When you say "during initialization of nodes", Brian, do you mean of > management stations or of nodes out there in the network? It's supposed to mean *before* the node has a valid certificate, i.e. no kind of security can be made to work. So we're talking about milliseconds to seconds of exposure, I hope, while BRSKI does its job. > In my understanding I would have written something like "until network > management systems can be upgraded to full ACP support ..." Right, that's a different type of transition... but there wouldn't we want to insist on (D)TLS or something like that? (Which again assumes certificates are available.) We can further clarify the text, for sure. Brian > > What am I missing? > Michael > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Mar 10 12:20:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1627A12945F for ; Fri, 10 Mar 2017 12:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FPFlPWGea5Ae for ; Fri, 10 Mar 2017 12:20:43 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFB2129424 for ; Fri, 10 Mar 2017 12:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3662; q=dns/txt; s=iport; t=1489177243; x=1490386843; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J1ZmOdP481tbyvezar+raaBdPyAqVj0dFGHYjeNuAhA=; b=Uv7yNZfj6uHvqu+8q8DQfRJkZbPhwlI8t/HMalKz1+q3N04gcNyU6cqU Roh8Zd7o3skXM+h3o0FU7SHWUfZ+RPnwE6kZOXdvW1t0bIp76yfzvS5/7 J8JC1IQTy0yMmSNN2QKezIxqCRW81suvNQ+p1QK/1KebvITPri6WBCSW6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAQAPCsNY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDpFQlTiCDh8LhXgCGoInPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQEhEToLBQcEAgEIDgMEAQEBAgIjAwICAiULFAEICAIEDgWGFINkC?= =?us-ascii?q?A6xaoImimcBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELh0iCaoQ3AQEbF4JvLoI?= =?us-ascii?q?xBZw8AZI3kSSTPwEfOIEDVxU/EQGEQx2BY3WHXQ8XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,142,1486425600"; d="scan'208";a="395432765" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 20:20:42 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2AKKg7s023545 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2017 20:20:42 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Mar 2017 14:20:35 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Fri, 10 Mar 2017 14:20:35 -0600 From: "Max Pritikin (pritikin)" To: Kent Watsen Thread-Topic: [Anima] Factory reset: Do we need two types? Thread-Index: AQHSmYtnpTk0vlOTJEqnexaNa8s4l6GOXsSAgABDYQCAAEblgA== Date: Fri, 10 Mar 2017 20:20:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.4] Content-Type: text/plain; charset="utf-8" Content-ID: <3A7D4793FF3F1C4CBFC98379A7B80337@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Beck, Stefan" , "anima@ietf.org" , "Michael H. Behringer" Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 20:20:45 -0000 KzIgKGdyaW4pDQoNCkZhY3RvcnkgcmVzZXQgbWVhbnM6IGJhY2sgdG8gd2hhdCB0aGUgZmFjdG9y eSBzaGlwcGVkLiBObyBpbnRlcm1lZGlhdGUgc3RhdGVzLg0KDQooSWYgdGhlcmUgaXMgYWN0dWFs bHkgYSByZXF1aXJlbWVudCBmb3IgYW4gaW50ZXJtZWRpYXRlIHN0YXRlIGl0IGNhbiBiZSBkZXZl bG9wZWQgYXMgcGFydCBvZiBvdGhlci9hZGRpdGlvbmFsIHdvcmsuIFN1Y2ggd291bGQgbm90IGJl IGNhbGxlZCDigJxmYWN0b3J5IHJlc2V04oCdIGl0IHdvdWxkIGJlIHNvbWV0aGluZyBlbHNlKS4g DQoNCi0gbWF4DQoNCj4gT24gTWFyIDEwLCAyMDE3LCBhdCA5OjA2IEFNLCBLZW50IFdhdHNlbiA8 a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0KPiBBbHNvIGFncmVlLCBmYWN0b3J5IHJl c2V0IG9ubHkgbWVhbnMgb25lIHRoaW5nLg0KPiANCj4gSy4NCj4gDQo+IA0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gDQo+IEkgYWdyZWUgd2l0aCBNaWNoYWVsIC0gb25seSAi dHlwZSAyIiBzaG91bGQgYmUgdGVybWVkIGFzICJmYWN0b3J5IHJlc2V0Ii4NCj4gDQo+ICJ0eXBl IDEiIHJlYWRzIHRvIG1lIGFzOiAiUmVzZXQgYSBkZXZpY2UgdG8gaXRzIGRlZmF1bHQgc2V0dGlu Z3MsIGJ1dCBrZWVwIGl0IGluIHRoZSBkb21haW4gaXQgd2FzIGVucm9sbGVkIHRvIi4NCj4gVGhp cyBpbmNsdWRlcyBrZWVwaW5nIHRoZSBMRGV2SUQsIGJ1dCBhbHNvIG90aGVyIGRhdGEgc3VjaCBh cyB0aGUgdHJ1c3QgYW5jaG9yKHMpLg0KPiANCj4gU3RldmllDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsIEguIEJlaHJpbmdlcg0KPiBTZW50OiBGcmlkYXksIE1h cmNoIDEwLCAyMDE3IDExOjQ1IEFNDQo+IFRvOiBhbmltYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBb QW5pbWFdIEZhY3RvcnkgcmVzZXQ6IERvIHdlIG5lZWQgdHdvIHR5cGVzPw0KPiANCj4gVGhlcmUg d2FzIGEgZGlzY3Vzc2lvbiBhYm91dCB0aGUgdGVybSBmYWN0b3J5IHJlc2V0LCBhbmQgd2hhdCBp dCBtZWFucy4gDQo+IFNwZWNpZmljYWxseSwgd2hldGhlciB0aGUgTERldklEIChkb21haW4gY2Vy dGlmaWNhdGUpIGlzIGRlbGV0ZWQuDQo+IA0KPiBUaGUgbm90ZXMgSSBoYXZlIHRha2VuIChmcm9t IHNvbWVvbmUncyBtYWlsKSBpbmRpY2F0ZToNCj4gICB0eXBlIDE6IGVyYXNlIGFsbCBidXQgTERl dklEIC0gRGV2aWNlIGRvZXNu4oCZdCBuZWVkIHRvIHJlLWVucm9sDQo+ICAgdHlwZSAyOiBlcmFz ZSBhbGwsIGluY2x1ZGluZyBMRGV2SUQNCj4gDQo+IFdoaWxlIHRyeWluZyB0byB3b3JrIHRoaXMg aW50byB0aGUgcmVmZXJlbmNlIGRyYWZ0LCBJJ20gZ2V0dGluZyBsZXNzIGFuZCBsZXNzIGNvbWZv cnRhYmxlIHdpdGggdGhlIHNlbnRpbWVudCBvZiAidHdvIHR5cGVzIG9mIGZhY3RvcnkgcmUtc2V0 Ii4NCj4gDQo+IEhlcmUgbXkgdGhpbmtpbmc6DQo+IC0gRmFjdG9yeSByZXNldCBicmluZ3MgYSBk ZXZpY2UgYmFjayB0byB0aGUgc3RhdGUgaXQgaGFkIHdoZW4gaXQgbGVmdCB0aGUgZmFjdG9yeS4g VGhpcyBpcyB2ZXJ5IHVuYW1iaWd1b3VzLCBhbmQgY2xlYXIuIFRoZSBkZXZpY2Ugd2lsbCBrZWVw IGl0cyBJRGV2SUQgYW5kIHRoZSBMRGV2SUQgd2lsbCBiZSBkZWxldGVkLiAobWF5IGJlIHdvcnRo IG5vdGluZyBpbiB0aGUgcmVmZXJlbmNlIGRyYWZ0IHRob3VnaCwgdG8gYmUgc3VyZSkuDQo+IC0g QSBwcm9jZXNzIHdoZXJlIHRoZSBMRGV2SUQgcmVtYWlucyBvbiB0aGUgZGV2aWNlIGluIG15IHZp ZXcgb2YgdGhlIHdvcmxkIGlzIHRoZXJlZm9yZSBOT1QgYSBmYWN0b3J5IHJlc2V0LiBJIHdvdWxk IGNhbGwgdGhpcyAiZXJhc2UgZGV2aWNlIGNvbmZpZ3VyYXRpb24gZXhjZXB0IHRoZSBMRGV2SUQi Lg0KPiANCj4gSSB0aGVyZWZvcmUgc3VnZ2VzdCB0byB1c2UgLyBkZWZpbmUgdGhlIHRlcm0gImZh Y3RvcnkgcmVzZXQiIGFzIHBlciBmaXJzdCBidWxsZXQgYWJvdmUuIEFuZCBOT1QgZGVmaW5lIHR3 byB0eXBlcyBvZiBmYWN0b3J5IHJlc2V0LiBJdCBqdXN0IGZlZWxzIHdyb25nIHRvIG1lLg0KPiAN Cj4gV2hhdCBhbSBJIG1pc3Npbmc/IFdoeSBkaWQgd2UgZXZlbiBuZWVkIGEgdGVybSBmb3IgdGhl IHNlY29uZD8gQ2FuIHdlIG5vdCBqdXN0IHNheSAiZGVsZXRlIGNvbmZpZywgYnV0IGxlYXZlIExE ZXZJRCI/DQo+IA0KPiBNaWNoYWVsDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWls aW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hbmltYQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg== From nobody Fri Mar 10 13:46:42 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1901294AD for ; Fri, 10 Mar 2017 13:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 vYih3WcgYCN9 for ; Fri, 10 Mar 2017 13:46:40 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC2F129452 for ; Fri, 10 Mar 2017 13:46:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C10B5E199; Fri, 10 Mar 2017 17:09:28 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B21C76381A; Fri, 10 Mar 2017 16:46:38 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> <3e20bb52-395a-567e-01fe-081b74f660d1@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Barry Leiba , anima@ietf.org, "Michael H. Behringer" Subject: Re: [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 21:46:42 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Confused about this last comment. MichaelR pointed out the case of a >> legacy network management platform, where you can easily add GRASP, >> but not ACP support. I concur with this view: We saw this a lot in >> customer deployment discussions. >> >> When you say "during initialization of nodes", Brian, do you mean of >> management stations or of nodes out there in the network? > It's supposed to mean *before* the node has a valid certificate, > i.e. no kind of security can be made to work. So we're talking about > milliseconds to seconds of exposure, I hope, while BRSKI does its job. This is not at all what I'm talking about. >> In my understanding I would have written something like "until network >> management systems can be upgraded to full ACP support ..." > Right, that's a different type of transition... but there wouldn't we > want to insist on (D)TLS or something like that? (Which again assumes > certificates are available.) That's what I'm talking about. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljDHr4ACgkQgItw+93Q 3WXjpwgAjuthAIGYsI0+tQwyq5GHN6Q2UXdRTH9m7QCB4+VWSHNPXNxhNE7FXMtN qslbmNEhl7jj3Z0gkhFOYkwiHdZ7POI2p2GvgLxCBeTkEqIJi17LrKgD6AS0y+8Y JLNEFK24007h6tb9uspyD8F02F4SMbp+afyNlIH8bafE6S1RLTCODhxfYqpbSCgJ t7OjivQ/n5yaF7Bdb2mccLV5tKNPFzO6NZq0V66zuLEkXyanqNAnbonfXopVcep6 KYszVbsyd3TYFunlJIdR0923czrrYf3gGE7v2zTZ2w9QSgcIWphKwiWQ9x1LFiYo ljCFcTPoj5IfqD1aC68zRMxTfypAIw== =RXHf -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 11 11:08:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B99D129561 for ; Sat, 11 Mar 2017 11:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ic1x6mk0G5Ky for ; Sat, 11 Mar 2017 11:08:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA6A129564 for ; Sat, 11 Mar 2017 11:08:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AF7702009E for ; Sat, 11 Mar 2017 14:31:44 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8BACB6381A for ; Sat, 11 Mar 2017 14:08:51 -0500 (EST) From: Michael Richardson To: anima X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] privacy in discovery X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 19:08:56 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain I haven't read the document yet, just the abstract. I am not suggesting it, just relaying that this privacy issue seems to be something others have recognized as a concern. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=678 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by obiwan.sandelman.ca with IMAP (fetchmail-6.3.26) for (single-drop); Fri, 10 Mar 2017 16:22:10 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus v2.4.16-Debian-2.4.16-4+deb7u2) with LMTPA; Fri, 10 Mar 2017 16:20:14 -0500 X-Sieve: CMU Sieve 2.4 Received: from colo19.roaringpenguin.com (unknown [IPv6:2604:1f80:1:478::19]) by tuna.sandelman.ca (Postfix) with ESMTPS id 666EEE232; Fri, 10 Mar 2017 16:20:13 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by colo19.roaringpenguin.com (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v2AKvMmE003605 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Mar 2017 15:57:23 -0500 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 200EF1295F4; Fri, 10 Mar 2017 12:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1489179442; bh=b4qXjFiZksnvWsDJyaENleirfwS+SI3F44uIQ3Fu+iU=; h=From:To:Date:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=vKZP0ODiCDjbFN9qJQXPDIL0Jq3doRtxrB3jr8UpiFc5TETXAV/yqyvIlyIwDeJdS eNQOieMWlmjcKqzPfhqjGqqRNW8+8RdAfYoiCXHOyuogOSJ/ouxAQZ0BwlCiIvHJ2j VN/2OAem0VTCky7WAVTv7yO0YPBks0R5B7jC0OrE= X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 294DD1295F4; Fri, 10 Mar 2017 12:57:20 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148917944013.3045.12928775040243531631@ietfa.amsl.com> Date: Fri, 10 Mar 2017 12:57:20 -0800 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dnssd-bounces@ietf.org Sender: "dnssd" X-Bayes-Prob: 0.0001 (Score 0, tokens from: mcr, @@RPTN) X-Spam-Score: 0.00 () [Hold at 5.10] SPF(pass:0),DKIM(pass:0) X-CanIt-Geo: ip=4.31.198.44; country=US; latitude=37.7510; longitude=-97.8220; http://maps.google.com/maps?q=37.7510,-97.8220&z=6 X-CanItPRO-Stream: sandelman-ca:mcr (inherits from sandelman-ca:default,rp-01:default,base:default) X-Canit-Stats-ID: 0gSSkVn4i - c0527a811d25 - 20170310 X-Antispam-Training-Forget: https://antispam.roaringpenguin.com/canit/b.php?c=f&i=0gSSkVn4i&m=c0527a811d25&rlm=sandelman-ca&t=20170310 X-Antispam-Training-Nonspam: https://antispam.roaringpenguin.com/canit/b.php?c=n&i=0gSSkVn4i&m=c0527a811d25&rlm=sandelman-ca&t=20170310 X-Antispam-Training-Phish: https://antispam.roaringpenguin.com/canit/b.php?c=p&i=0gSSkVn4i&m=c0527a811d25&rlm=sandelman-ca&t=20170310 X-Antispam-Training-Spam: https://antispam.roaringpenguin.com/canit/b.php?c=s&i=0gSSkVn4i&m=c0527a811d25&rlm=sandelman-ca&t=20170310 X-CanIt-Archive-Cluster: irqpXI7aJGyo4Ewta7qVH399FOg Received-SPF: pass (colo19.roaringpenguin.com: domain of dnssd-bounces@ietf.org designates 4.31.198.44 as permitted sender) receiver=colo19.roaringpenguin.com; client-ip=4.31.198.44; envelope-from=; helo=mail.ietf.org; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery of the IETF. Title : Privacy Extensions for DNS-SD Authors : Christian Huitema Daniel Kaiser Filename : draft-ietf-dnssd-privacy-01.txt Pages : 23 Date : 2017-03-10 Abstract: DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. We propose to solve this problem by a two-stage approach. In the first stage, hosts discover Private Discovery Service Instances via DNS-SD using special formats to protect their privacy. These service instances correspond to Private Discovery Servers running on peers. In the second stage, hosts directly query these Private Discovery Servers via DNS-SD over TLS. A pairwise shared secret necessary to establish these connections is only known to hosts authorized by a pairing system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-privacy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-privacy-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd --=-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljES0AACgkQgItw+93Q 3WV4sgf/anohZqx+GEa8Me+KUeiPhcbRe2AngFtu+7N/Fyen7BgoBL5dAxcfvlHY fZi1CihHMo8KfFDl4MWorUwiKPUDK/w7PrLx0Sa2yKUAgxSjrirhdSiTAaHlBEEk 4QSoHwd8GdMyXA0GmV0ojXiGFRudkXbmen8SIonCh98BZwS50SJqzzrLKYVjIrvk MdyWpoAl5adAj1bs5fBpUO0RWMd3PK+fGIH02mDNJ2kaZYPndzhAHVvd0rZdOxrd F9UOSa4p2USu64ps6cudV3Ag2P9FeAIk8B88q7NtjAuDNRi7mtfcASoOFKzQkn2z XUA4vyoZu4g5uQ8k+Vqd/7McuGeuTw== =mI3P -----END PGP SIGNATURE----- --==-=-=-- From nobody Sat Mar 11 11:20:41 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA3D129575 for ; Sat, 11 Mar 2017 11:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9B5nl0YaBOn8 for ; Sat, 11 Mar 2017 11:20:39 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 2A461129564 for ; Sat, 11 Mar 2017 11:20:39 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id b129so50162048pgc.2 for ; Sat, 11 Mar 2017 11:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=F8pcF3T6qbJIE8m9xusNRguQPsyRX64XX/Bz4ne+l1w=; b=CH7Xfzr7Q0tfz8uKbEP69TCKCEdJ2pxZ/CDErL71Skuavu31ZZPB0nAarvh5DJBkal Axl2my+JhdrdVr+2osRUy88ilYSEOM6S4vCyfzHDqrZlxUa3CrqJrQjqpWlZgmt2FQ4m 6Qg2QixxQvpwURLe2SHTb6Z/9TsNfsHe8WWgZe04IsAb/mz03zAs/bLjhoipF1GnLISD 2J9QzmvasKTu4gy+dKZmiqqpNGC2GRloMwjbN5AELbX3NPELfqLawbpC+5hXKV7FPrNc uEJrE0B6xH57Top1/1wLqao5Cur7rQLAg7YxmpUH2EkjdYS+KwzfxStvEhSF9yIWwaAA ZFWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=F8pcF3T6qbJIE8m9xusNRguQPsyRX64XX/Bz4ne+l1w=; b=AbHcrah9mENR4lwhyF8ThD86vI4jEdsHKNPH0F1o2zG8cGk8QON4tK8UTkvzWmJhD2 kqqg9HWRpjQP+z0bj5g37czC9XwsLvIsQrQ2nBkWbTnFs3Lm8ck2x+SSf4KIiiIOSJhX YDUXfMBpPKSzCNot9clOj2FDjqAMvu1aZiSPXJBnZW3ccfKV5FGA/4erz+LzXEY+Lgr9 eEYHefp1X+3LdIp1Lpl3YdBuKJKl5mRG24OAE1d1ClNlwLM1pS3rlX0p4SQErTEvPia/ v7kRakr30zzzZKZFkbOmNAti3/Nt7ZkhY04I7EpA3E0v2PkABtT1+jfR+j0tWlp0Euz9 Csjw== X-Gm-Message-State: AMke39mKtB7JbFG8qlR3uiIgTGTd+s+kipBu6ONPqqFLDd2Dn7phx+oe4FsSyo3OWZ2aaw== X-Received: by 10.84.198.164 with SMTP id p33mr35566284pld.127.1489260038525; Sat, 11 Mar 2017 11:20:38 -0800 (PST) Received: from [192.168.178.26] ([118.148.126.194]) by smtp.gmail.com with ESMTPSA id w14sm25609572pgo.37.2017.03.11.11.20.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Mar 2017 11:20:37 -0800 (PST) To: anima@ietf.org References: <18565.1489259331@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 12 Mar 2017 08:20:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <18565.1489259331@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] privacy in discovery X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 19:20:40 -0000 On 12/03/2017 08:08, Michael Richardson wrote: > > I haven't read the document yet, just the abstract. > > I am not suggesting it, just relaying that this privacy issue seems to be > something others have recognized as a concern. Do you see it as a concern inside the ACP? I would have thought not. We have intentionally punted on ASA authorization for now, but it seems to me that an authorization system for ASAs (is ASA X allowed to access objective Y?) would cover the issue. The GRASP spec has a few words starting: "Generally speaking, no personal information is expected to be involved in the signaling protocol, so there should be no direct impact on personal privacy..." Brian > Subject: [dnssd] I-D Action: draft-ietf-dnssd-privacy-01.txt ... From nobody Sat Mar 11 11:35:44 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05727129574 for ; Sat, 11 Mar 2017 11:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 u5mlF7Ji64a5 for ; Sat, 11 Mar 2017 11:35:41 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 DB45C12957C for ; Sat, 11 Mar 2017 11:35:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C764C466FCE; Sat, 11 Mar 2017 11:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1489260937; bh=jKA9GeEH9pcX9CWJhc+/bZJXHGdELGAozOcf8vBbZBI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=oojAeyYl1UaUbKdbfYtZpmnjilVr3WRfVupYWRbn5UdVqaQiazxAYUy5hKrerpueZ haqb6vKuFkbZxXfFLjx/C2P4SdxDAkeikbni4sOwfODChZAOGx32Y/OQeeRWs3wnXd x1kF9lFjgQV0Prqu6opzHQyI6JPDqd6DmKTceZhY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5D4A21C03B7; Sat, 11 Mar 2017 11:35:37 -0800 (PST) To: Brian E Carpenter , anima@ietf.org References: <18565.1489259331@obiwan.sandelman.ca> From: "Joel M. Halpern" Message-ID: Date: Sat, 11 Mar 2017 14:35:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] privacy in discovery X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 19:35:43 -0000 The question that occurs to me is whether the pre-ACP discovery phase needs privacy protection. The answer is not obvious, since the scope is limited (where DNS queries can go arbitrary distances across the net.) Yours, Joel On 3/11/17 2:20 PM, Brian E Carpenter wrote: > On 12/03/2017 08:08, Michael Richardson wrote: >> >> I haven't read the document yet, just the abstract. >> >> I am not suggesting it, just relaying that this privacy issue seems to be >> something others have recognized as a concern. > > Do you see it as a concern inside the ACP? I would have thought not. > > We have intentionally punted on ASA authorization for now, but it seems to > me that an authorization system for ASAs (is ASA X allowed to access > objective Y?) would cover the issue. > > The GRASP spec has a few words starting: > "Generally speaking, no personal information is expected to be > involved in the signaling protocol, so there should be no direct > impact on personal privacy..." > > Brian > >> Subject: [dnssd] I-D Action: draft-ietf-dnssd-privacy-01.txt > ... > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sat Mar 11 12:00:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBAE1295E3 for ; Sat, 11 Mar 2017 12:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qJ22sGdFfcjk for ; Sat, 11 Mar 2017 12:00:35 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F99412960A for ; Sat, 11 Mar 2017 12:00:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BA9AE215; Sat, 11 Mar 2017 15:23:22 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 23A636381A; Sat, 11 Mar 2017 15:00:29 -0500 (EST) From: Michael Richardson To: "Michael H. Behringer" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 20:00:37 -0000 --=-=-= Content-Type: text/plain Michael H. Behringer wrote: > worth noting in the reference draft though, to be sure). - A process > where the LDevID remains on the device in my view of the world is > therefore NOT a factory reset. I would call this "erase device > configuration except the LDevID". "Reset to default configuration" > I therefore suggest to use / define the term "factory reset" as per > first bullet above. And NOT define two types of factory reset. It just > feels wrong to me. I agree. > What am I missing? Why did we even need a term for the second? Can we > not just say "delete config, but leave LDevID"? I think that this is the activity that one usually wants when some button is held down. Deleting the LDevID is probably more than most operators expect. Deleting the LDevID brings the device back to "unowned" state. Some devices should support such a thing, and some simply should not. Some should require a screwdriver/jumper/etc. In particular, being able to reset to default configuration may be something that should be easy to do for a untrusted operator (i.e. CPE in residential setting), but which shouldn't change the onwership. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljEV1sACgkQgItw+93Q 3WVHQQf/WovCcFyeNNgnDJ9hpHY2UY7pJ3dp4rPxU8KD9MFllxHpOp2smD1DelSd tWAJ43RC3Fsf3aTHpp1zPk7zOKshRNqkn7mwrGVThQoK1141rz/9CaK/Gzx2fXG8 BSA8woF8EAC+TuNcwGHYydiIO2YtNlJWSKqTqaXzyrauhniyvy72yz+bDQBoMFM0 PUHWiJwGwe1IprEXt1znQQ42UV2MstafG2qufUaf9+HHMB9fVxuUxMINCzjy+BGE ms2DdEgQb6LkjBCbusgAHg3+fwdYhzVkYSTfhJ6jEX2V/pkMpkAMMCw8YTqCI3jr OGD16nwd1eQGJA3PpKPiQU0Dcs/uzw== =po9g -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 11 12:58:59 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06B129487 for ; Sat, 11 Mar 2017 12:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WWxUSTy8YWcs for ; Sat, 11 Mar 2017 12:58:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47B2129415 for ; Sat, 11 Mar 2017 12:58:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A433E216; Sat, 11 Mar 2017 16:21:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CCA176381A; Sat, 11 Mar 2017 15:58:54 -0500 (EST) From: Michael Richardson To: Anima WG In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Eliot Lear Subject: Re: [Anima] CRLs in iDevID manufacturer signing certs? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 20:58:58 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: > What is the thinking on including CRL pointer in the manufacturer > signing cert? This question came up in industry discussions. Kent Watsen wrote: > 802.1AR says that the IDevID secrets must be stored confidentially and > be not available outside the module. In practice, a crypto processor > with tamper-resistant NVRAM is used (e.g., TPM). As such, the > likelihood of the credentials being stolen/discovered are near zero, > but it is not zero, as a determined adversary with sufficient resources While 802.1AR would like this, I think that the BRSKI mechanism we are describing (and re-interpreting for constrained environments in 6tisch) are very unlikely to have serious tamper-resistant mechanisms for the IDevID that are seperate from the system in general. Revoking the IDevID would be useful, but it might be that the MASA can effect the same thing by refusing to issue an ownership voucher. This only works if ownership vouchers are to be issued online, or they can be revoked. This doesn't solve the same problem, but it may have the same result. I am also concerned about how many bytes a CRL pointer requires. I'm guessing it's on the order of 50 bytes for the URL and container. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljEZQoACgkQgItw+93Q 3WUt9Af8CQ2w7VXQ7F8YkoCHblJGzfKTWjw6Djim7E2m/yl1Gu/Y8PCQh8LBd8n7 IwhINRTWPZpZ/Vn35DfvJyxRCpD4BBc8mEzI/jrMZWEKvrDAzdOKGfjTB3AkJdRS 87nypQRqwNkVvgfg9suOimqmUhTpcJbjf+5l+V26lfnIJ1tAOxjDx6SU7gxvq8jt SrHKKaUnN/dbBoKF5Y+GFYRibMBJ64RFwkU5dI8aU2B4VB7x6HnNRFtPeNkO070s +wDDrHk71FlwbUFl6agMBRlPJ3a+Hc2IcCNe3iPciX6K33Dgz5q5+BgOEfOGMsv8 edH43p9pceqOgAOSBn+jbsOZKhyaqw== =2ujt -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 13 00:48:52 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC2E129545 for ; Mon, 13 Mar 2017 00:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nuoSs3uNchnn for ; Mon, 13 Mar 2017 00:48:49 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 7DF28129502 for ; Mon, 13 Mar 2017 00:48:49 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id u48so19004494wrc.1 for ; Mon, 13 Mar 2017 00:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+KPA6vOBUqbWmg42IQAIUzG3ili3ICRromtLTWEw4hE=; b=sNt0wZKrX+gTeqaKfLPp1jHp4vR1JpB9yh6iBGWOSTI1kglZtemVLHghrOGiufhVOe g8J9kfEgxWUm+82QxksQq2pkkyy97iJwdJtVerWpGK7HzkDg2BkFp1RWinJexmxialUS CbDubVatujl0icxyCj0i1uBL/OEpLx6YrMZEGC+iG6N2pjcLBBo6XIwJzMuI/cW8swqE iztBlp0Em7mE53i9LQl6zgX7pBVYyzfBJjO2Ep/gvOdR7HVfkWcm0w2DJycW0xL77M8L UJVVZcwAZzEZy/6gxDAX955wVtJ3AznIwrGGo2pe5kcAsu6AOLuPTFyTeRWbk8QdpmwB JdMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+KPA6vOBUqbWmg42IQAIUzG3ili3ICRromtLTWEw4hE=; b=nHK1cdf/0gB+pSTrg0vUqYUGvY+Hf9SYhBr49dRE4LZHKRRHuqaaSBCOAGAyT39aGI rAqrH4wi3Clt2uEdCe7TvbVMhGIxFrK3N+qFoCgZBSLAtPKR4fO+r59JEA+w9e+G9Vov ZE1scMr9f5pc+1bhodJCNQECrU9+Rp6NBLjtzK6ErQUb12d36AQ6EMIXGzqtDJLwrEG1 EbiJGHGEbOOVeTeH8KZMcb1XEqtzdAiZlgY68qcxO3zJs1T3dK+izDWuaIWxeTr0yvXO vug9XHxay+YPPjb45iizQufhz7RW5UULNOs+Zbz7ZouIJ9H7kzQKwKEFBWAGSYgjBr6W XB+Q== X-Gm-Message-State: AMke39nNjhZef+XvrkUP0DP0ZXSDIcbrvFEvXiwCoXxgHgwJjFNlkX1btKX0P32zl1OaBA== X-Received: by 10.223.169.161 with SMTP id b30mr27289878wrd.196.1489391327921; Mon, 13 Mar 2017 00:48:47 -0700 (PDT) Received: from [192.168.1.58] (ANice-652-1-354-117.w83-201.abo.wanadoo.fr. [83.201.77.117]) by smtp.gmail.com with ESMTPSA id q75sm10203010wmd.27.2017.03.13.00.48.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 00:48:47 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Michael Richardson References: <29636.1489262429@obiwan.sandelman.ca> Message-ID: <3b65ce83-b241-b3c2-3ec4-edd8eab7d637@gmail.com> Date: Mon, 13 Mar 2017 08:48:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <29636.1489262429@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 07:48:51 -0000 Thanks, Michael, I think we're in sync. I'll take on board your "reset to default configuration". Now I wonder where this idea of the "two types of factory reset" actually came from? Never mind... We're all aligned, that's the key. Michael On 11/03/2017 21:00, Michael Richardson wrote: > Michael H. Behringer wrote: > > worth noting in the reference draft though, to be sure). - A process > > where the LDevID remains on the device in my view of the world is > > therefore NOT a factory reset. I would call this "erase device > > configuration except the LDevID". > > "Reset to default configuration" > > > I therefore suggest to use / define the term "factory reset" as per > > first bullet above. And NOT define two types of factory reset. It just > > feels wrong to me. > > I agree. > > > What am I missing? Why did we even need a term for the second? Can we > > not just say "delete config, but leave LDevID"? > > I think that this is the activity that one usually wants when some > button is held down. Deleting the LDevID is probably more than most > operators expect. > > Deleting the LDevID brings the device back to "unowned" state. > Some devices should support such a thing, and some simply should not. > Some should require a screwdriver/jumper/etc. > > In particular, being able to reset to default configuration may be > something that should be easy to do for a untrusted operator > (i.e. CPE in residential setting), but which shouldn't change the onwership. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Mar 13 03:40:34 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DE5129561 for ; Mon, 13 Mar 2017 03:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dToDifLaoFMP for ; Mon, 13 Mar 2017 03:40:31 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (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 8D962126D73 for ; Mon, 13 Mar 2017 03:40:31 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id g10so19509397wrg.0 for ; Mon, 13 Mar 2017 03:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rKuBiiTZd4sWBa0VO7L7sVmykAsVvm6IQ6IGZ4gWQjI=; b=us7ebQ6/ob36wgAee8UNS2xUtJfg6cWo9x0VdviVUkadrIr3dbgl8+Hojo9UooYToL OXWmkcl/zy2tNGS86bK2kQyb/vt7yTaKbf7WCI/OCpNvqvFS1C84ptu5dks8RFJkF4QY wK8Ai55XSTkGzDPB1D32sxEociMVLchcFGGtL7GAPL8FCDu3OwBpoNM4XcDsqQVos+9T MksnWlcmSH89ZZyoTyFSiPca0mFCE0yDKTFzrrA/3mC04+R/XHIEDoE3XrfpZ8yULCwN XvhbOaqhMXissOJEk1D5vIgeqNroEJtRlu1YMwauLFwqcsSOJ3kAQQl2g+SaCOm2MgwX Y1og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rKuBiiTZd4sWBa0VO7L7sVmykAsVvm6IQ6IGZ4gWQjI=; b=oxj1HXtHxA9iTBehoLSvnx/ftyAvA2KCI387zZidHLr50JUnGxD+a+MosyIp3jB52t pEx3DYA7J374UKGzcJTJ+3U4Qhh8TM9L71QbJps4fhtCscoIVx1Yb0zRDdoNU7RZiwm7 xcEfEn1N1miwN4U7corK1ToLHYU24LsJoKz4zIhZ4b9c5QheM0hwnm2+hnZC2IXfV60m uG6/KotAlEDZ/yY3doF0LviLTIT6Bddd7hMjQiofTx6vjY/KNY707ddCckUTuWbHg5gh egPKdyUUJZo6HMXxoGOjlJ9C6ibKekYfW8aeVQpKcVz6fu0/5sbb7PkklxTr1UQ5U9LC hJBg== X-Gm-Message-State: AMke39mh0UcME54aMRY7AqcubS3hEEda9TPr0RfOYSGAo2djh4pRqElpjslCdetkhlDE5A== X-Received: by 10.223.173.53 with SMTP id p50mr29477346wrc.112.1489401629926; Mon, 13 Mar 2017 03:40:29 -0700 (PDT) Received: from [192.168.1.58] (ANice-652-1-354-117.w83-201.abo.wanadoo.fr. [83.201.77.117]) by smtp.gmail.com with ESMTPSA id x23sm24571792wrb.49.2017.03.13.03.40.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 03:40:28 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Michael Richardson References: <29636.1489262429@obiwan.sandelman.ca> Message-ID: Date: Mon, 13 Mar 2017 11:40:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <29636.1489262429@obiwan.sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:40:33 -0000 Formulating the state machine in the reference draft, I come to the conclusion that we should actually *not* mention that "reset to default configuration" in it, because it actually has nothing to do with AN at all. From an AN perspective it´s important to show what happens when: - we delete the LDevID. A factory reset does that. - a device loses all ACP tunnels. The configuration of the device is outside scope, I think! If a config change removes the last ACP tunnel (for example), then it's that removal that changes the state in the AN machine. The important thing to mention (and so far missing) is IMO that *only* a factory re-set can remove the LDevID, otherwise we may end up with stale state at enrollment time. I added that point in my new section. Please shout if you think I'm missing something. Michael On 11/03/2017 21:00, Michael Richardson wrote: > Michael H. Behringer wrote: > > worth noting in the reference draft though, to be sure). - A process > > where the LDevID remains on the device in my view of the world is > > therefore NOT a factory reset. I would call this "erase device > > configuration except the LDevID". > > "Reset to default configuration" > > > I therefore suggest to use / define the term "factory reset" as per > > first bullet above. And NOT define two types of factory reset. It just > > feels wrong to me. > > I agree. > > > What am I missing? Why did we even need a term for the second? Can we > > not just say "delete config, but leave LDevID"? > > I think that this is the activity that one usually wants when some > button is held down. Deleting the LDevID is probably more than most > operators expect. > > Deleting the LDevID brings the device back to "unowned" state. > Some devices should support such a thing, and some simply should not. > Some should require a screwdriver/jumper/etc. > > In particular, being able to reset to default configuration may be > something that should be easy to do for a untrusted operator > (i.e. CPE in residential setting), but which shouldn't change the onwership. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Mar 13 09:58:19 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A1212963D; Mon, 13 Mar 2017 09:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942429514.17043.1229796975628259782@ietfa.amsl.com> Date: Mon, 13 Mar 2017 09:58:15 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-reference-model-03.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:58:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Reference Model for Autonomic Networking Authors : Michael H. Behringer Brian Carpenter Toerless Eckert Laurent Ciavaglia Peloso Pierre Bing Liu Jeferson Campos Nobre John Strassner Filename : draft-ietf-anima-reference-model-03.txt Pages : 28 Date : 2017-03-13 Abstract: This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-reference-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-reference-model-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-reference-model-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 10:03:19 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B055F12986D for ; Mon, 13 Mar 2017 10:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 L_FON_hDiO6q for ; Mon, 13 Mar 2017 10:03:17 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 1F3F1129850 for ; Mon, 13 Mar 2017 10:03:17 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id u48so108043008wrc.0 for ; Mon, 13 Mar 2017 10:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=9mprVr3txyqHA6ZhRg1gztLSJVFvgNx1ESNJ8e72+Yk=; b=HduwVdxoHAm8Jg3ADu9EoVLoJDrjVSZmZYz2qaf9HYoP2uxtTHG++AGgJoGpdPnIGf Q8iP+uAHBwzgt9t14RWohCDBxttiDNSnLWBKH8tvnKO1lkXESyg83nFo9KjIVJlLOJNA CRII0tiHxf8lONgi4VG5SBdBoOhfKaOsBxeYQjWM0lNKfezO4cXpgH8mXY/H6gtMBWFL NQK2PoBQ82fIgeHJIYjpgqjy8MHkP2S7xfJflpkwCE8Xni9y50jBO4eK/PjuvXZ2nEpo RIj1WlhONJqbGQZM2X7QvkLirwS7tg6Y5nwRBxiZZ219QQuumGDVKqTdbJvpgBokPIlI gteA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=9mprVr3txyqHA6ZhRg1gztLSJVFvgNx1ESNJ8e72+Yk=; b=etuMptv6iA4SnDVeHaK7p98JJic7rAkwlJRONb0o6714IiAHni5G+eLb4R5yiDxGQC q4etuDfYcV2uzx29HVGoQWpUiG4HL/nGwfkkCsP9ayCcqTKgx6damCxJWZGoIo9MQheX UxmM1aXSNmWEelaLRRTn5LjKYX0344M3wMAogGsMQa4/0QGraLG1VSJGiUKEJCe0NXAd NKdZuPlaaigJ5r40dijgACu0u9U4DxD4ZPteVOrVSEdxakCNb590U0p1xvTPbTY+A/rJ U8uvOL2DwEhG5FW2eWLnXxENthbHZrcsJwmK7OpTmqWuGd60vlY95U3FMcVMHIUpYDMj akKg== X-Gm-Message-State: AMke39nJXpXHTr1eo7xKzPU4ciTMpkAM+d/oeOvQG0rjKDMqJaK1ukqLW9HNv1nlK8KcaA== X-Received: by 10.223.153.225 with SMTP id y88mr27825137wrb.81.1489424595294; Mon, 13 Mar 2017 10:03:15 -0700 (PDT) Received: from ?IPv6:2001:420:c0c0:1004::151? ([2001:420:c0c0:1004::151]) by smtp.gmail.com with ESMTPSA id u198sm12060861wmf.9.2017.03.13.10.03.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 10:03:14 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: "anima@ietf.org" Message-ID: <38298198-d000-fda5-6152-249a3e8154f9@gmail.com> Date: Mon, 13 Mar 2017 18:03:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] New version of draft-ietf-anima-reference-model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:03:18 -0000 ANIMA WG, I just uploaded a new version of the reference model, https://tools.ietf.org/html/draft-ietf-anima-reference-model-03. Below the change log; I believe to have addressed all open issues. Feedback please! Michael on behalf of the co-authors. -- * Added the state machine, as discussed in the last IETF. * Re-ordered things a bit: Now the state machine, as well as the description of the adjacency table (old section 5) are part of section 3, which has become more important, but I think we now have all elements concerning an autonomic node in one section, which looks a lot better to me. Also, I dropped the old section 5 "Behavior of an autonomic node", that never really fit well. So now it looks like this: 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 4 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The Adjacency Table . . . . . . . . . . . . . . . . . . . 6 3.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. State 1: Factory Default . . . . . . . . . . . . . . 8 3.3.2. State 2: Enrolled . . . . . . . . . . . . . . . . . . 8 3.3.3. State 3: In ACP . . . . . . . . . . . . . . . . . . . 9 * Intent distribution: The previous version of the draft only referred to intent to be distributed; following our discussions the distribution protocol may also transport other "information" (which is the term I use now in the draft), which I have now brought out more explicitly in some places. * There was some discussion on whether we should be more explicit in how information (e.g., Intent) is flooded. I think we settled on GRASP synchronising which node has which version of "information", and where to find it (URI). Then another protocol pulls that information block if needed. However, looking at the reference draft right now, I think we should NOT enter this level of detail here; this should be dealt with in draft-liu-anima-grasp-distribution. I think we're better off if the reference draft stays on a high level here. In any case, it's formally out of scope in ANIMA right now. * Dealing with out-of-scope topics: I think we agreed that we must include some topics in the draft that are formally out of scope, to provide the context for certain decisions. So far I think we universally agree. We went back-and-forth a few times whether to mark topics with (*) inline, or whether to group them in an appendix. Neither way is perfect. My personal preference is to leave them inline, in the sections they belong to, because if we group them in an appendix we lose context. I think all such topics are clearly marked with a (*) and in each such section I wrote explicitly "outside scope for now". I also re-ordered some sections such that the (*) topics are always last in each section (e.g., I re-ordered 4.6 and 4.7). If anyone has a problem with that, please shout! * Made some changes to (old) section 5, "Behaviour of an autonomic node": ** changed the sequence: First, node joins ACP, THEN it starts bootstrap proxy ** added Registrar discovery as a separate step. ** explained that bootstrap proxy is an ASA (as discussed in the ASA section) ** condition for the latter is 1) part of ACP, and 2) having discovered at least one Registrar. * some editorial changes; changed a "MAY" to a "may". * Changed "The Proxy ASA" to "The Join Assistant ASA", and "The Registrar" is now "The Join Registrar". From nobody Mon Mar 13 12:26:25 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3D12949E for ; Mon, 13 Mar 2017 12:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FsaD_A_KPT4Y for ; Mon, 13 Mar 2017 12:26:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278BE129481 for ; Mon, 13 Mar 2017 12:26:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 10070E234; Mon, 13 Mar 2017 15:49:21 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F170A6381A; Mon, 13 Mar 2017 15:26:20 -0400 (EDT) From: Michael Richardson To: "Michael H. Behringer" In-Reply-To: References: <29636.1489262429@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:26:24 -0000 --=-=-= Content-Type: text/plain Michael H. Behringer wrote: > The configuration of the device is outside scope, I think! If a config > change removes the last ACP tunnel (for example), then it's that > removal that changes the state in the AN machine. I like this way of writing it. As long as we have working ACP tunnels, then we can fix the configuration. What happens when the last ACP tunnel dies? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljG8lwACgkQgItw+93Q 3WV4gAf/ZDQJ1+B2Da0J5eNoTjKwMXIeT3YTyPF5YCysVcPUFGQHlFKtMSNrEs3t /N0pEebl0RxkqjrkcNynAM7Vk5mwMlNornhQThCh9B8mOsScXfNsXEShEbEyfyGq jhJGZMQwJo1nUgodj7ENm6CN8S6S8Wdfwk9HhAuzmbeHod96/LjSxqVZCSSGcyUF 0COrxlTXA8/qbCqZhB9OURaLBZil4uP0KXqbqAgm7UQoVAPO7fpMjaiBkOFqJA+n fotiJMlXYtoKo7faWVr03IPoIReh6nNcdn/aCEprW9WBzcWqHng/HpIXiWfxcatf y5mOQ5DdmHskAiY6VKnK4JyuAbwPeA== =Cvyc -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 13 13:51:38 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A0B12942F; Mon, 13 Mar 2017 13:51:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943829270.20377.5941745728642467008@ietfa.amsl.com> Date: Mon, 13 Mar 2017 13:51:32 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-voucher-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:51:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Voucher Profile for Bootstrapping Protocols Authors : Kent Watsen Michael C. Richardson Max Pritikin Toerless Eckert Filename : draft-ietf-anima-voucher-01.txt Pages : 19 Date : 2017-03-13 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". The voucher artifact is a YANG-defined JSON document that has been signed using a PKCS#7 structure. The voucher artifact is generated by the pledge's manufacture or delegate (i.e. the MASA). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-voucher-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 14:07:16 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5A12951E for ; Mon, 13 Mar 2017 14:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 iF2--xHR0mdw for ; Mon, 13 Mar 2017 14:07:14 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 71CC512942F for ; Mon, 13 Mar 2017 14:07:14 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id b5so19652325pgg.1 for ; Mon, 13 Mar 2017 14:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=065ytRX0hiTr8B90pg97f/IjZTY2r6sGClf46K96Ljk=; b=jfunKDoHhMbbpM03g5/VixV3B2pYMjWp+xI8dp9zA9xF9ehn//Nc+nwDDy/ykKDemY bJP/p74omIC7kinJFu6QdIfbOk3AGhfkf4+vt2CQBvZhG2tjl1nBrQHAzUho1JIrZGon xcXRiGMkyJo5spVe9vpRMY8dfGiPCsYOvOkiKLIeEpEnLVSJA0rYxj7HGXCQoia2odYt CKcfmRaowrNXTYa1KXTnGWY6pxBBwWkcK1H7lxc84Hy6F9xiYXOlfIkUwcL4SVg2NEbO vfFLEIYpD/1TW//Qynr8oQ0K68uXpyWcy+7q0u90VdWLYysxLtYKBzdIfP4NaDoQG0SI GIjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=065ytRX0hiTr8B90pg97f/IjZTY2r6sGClf46K96Ljk=; b=GqxdUUyuKDhN5yXC02GtoMZwQSpo7+4Qy9G0YO13RQx3+kfdifI8/B5N6vvAu06l5n wXWSctXR8okwVSXFzJACADcrCC2NSSj9BcXoKTEIu2nLJlvOVV4nA4wu+aY0QIwI/9SN NbOvQ44hkAn931MGKKHl9lF84K8O9AzRTCX1ge8VVE0NkZT+SASdrdcBuuam9ndbXo1p xHDDayQoGCfB2fEf7zWZD7RPzCI93t7LVtxL64sCVLq3Jyyp4+A7FXa9iMjNhKtY0hQt d1VdU1GXV1qYywgQ7DYaFtgghEZbFJF9voGUXGDadKBX7fYpMtx8Qu1Xn2OJUwk//r6p lKAA== X-Gm-Message-State: AMke39kSQqsJ5T3AS94FE+lFsHRQkrA4rHidPzCo2mwQrzv2j0d24Lo0nGhSx6hddaH8IQ== X-Received: by 10.84.131.197 with SMTP id d63mr51170992pld.103.1489439234089; Mon, 13 Mar 2017 14:07:14 -0700 (PDT) Received: from [172.26.32.151] ([104.129.192.110]) by smtp.gmail.com with ESMTPSA id x21sm34335807pfa.71.2017.03.13.14.07.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 14:07:13 -0700 (PDT) To: Michael Richardson , "Michael H. Behringer" References: <29636.1489262429@obiwan.sandelman.ca> <8438.1489433180@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <34877974-be20-f5d1-dcdc-0d18bf094816@gmail.com> Date: Tue, 14 Mar 2017 10:07:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8438.1489433180@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:07:16 -0000 On 14/03/2017 08:26, Michael Richardson wrote: > > Michael H. Behringer wrote: > > The configuration of the device is outside scope, I think! If a config > > change removes the last ACP tunnel (for example), then it's that > > removal that changes the state in the AN machine. > > I like this way of writing it. > As long as we have working ACP tunnels, then we can fix the configuration. > > What happens when the last ACP tunnel dies? Two things that I know about should happen, IMHO: 1. The ACP "ASA" (the thing that builds and maintains the ACP) will just revert to its initial mode where it's listening for neighbors and periodically trying to discover neighbors. 2. A Boolean somewhere will flip to False so that users of the ACP (including GRASP) know that they are on their own. Brian From nobody Mon Mar 13 14:52:26 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66A129BA7; Mon, 13 Mar 2017 14:52:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944194143.20385.9814981620178250957@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:52:21 -0700 Archived-At: Cc: anima@ietf.org Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:52:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Michael H. Behringer Steinthor Bjarnason Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-05.txt Pages : 55 Date : 2017-03-13 Abstract: This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed X.509 certificate, in combination with a vendor's authorizing service, both online the Internet, and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 14 15:42:55 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0419E13160F for ; Tue, 14 Mar 2017 15:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 WKhiTlJiaXDz for ; Tue, 14 Mar 2017 15:42:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07D713160E for ; Tue, 14 Mar 2017 15:42:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F2D412009E for ; Tue, 14 Mar 2017 19:05:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E79E0636E0 for ; Tue, 14 Mar 2017 18:42:51 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <34877974-be20-f5d1-dcdc-0d18bf094816@gmail.com> References: <29636.1489262429@obiwan.sandelman.ca> <8438.1489433180@obiwan.sandelman.ca> <34877974-be20-f5d1-dcdc-0d18bf094816@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Factory reset: Do we need two types? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 22:42:54 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Michael H. Behringer wrote: >> > The configuration of the device is outside scope, I think! If a config >> > change removes the last ACP tunnel (for example), then it's that >> > removal that changes the state in the AN machine. >> >> I like this way of writing it. >> As long as we have working ACP tunnels, then we can fix the configuration. >> >> What happens when the last ACP tunnel dies? > Two things that I know about should happen, IMHO: > 1. The ACP "ASA" (the thing that builds and maintains the ACP) will > just revert to its initial mode where it's listening for neighbors and > periodically trying to discover neighbors. > 2. A Boolean somewhere will flip to False so that users of the ACP > (including GRASP) know that they are on their own. Yes. I think that this goes into the ACP draft. The above is the minimum... BUT: I think that we need additional text though... it seems to me that one might need to do additional things specific to the device itself, but that these things might be risky. Specifically, I think that it the device should consider if there have been connectivity changes provisioned (such as changing PVIDs at layer-2, admin enabling/disabling interfaces, or firewall changes) since the last time the ACP was working. It should consider if it ought to revert to last known to be working configuration, but that that is in fact the risky part. I suspect that perhaps there is a lot of vendor-secret-sauce possibilities here; so I don't want to be prescriptive, but rather to say that when the last ACP connection goes down, that the device has essentially become unmanaged, and that it needs to do something (autonomic) to return to managed state. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljIcesACgkQgItw+93Q 3WU+AAf/RFi8QywC9brU6wjGZej/fnh5ZMRzp1TUDhO++rMzZkazypG0pVgywPdL Vl0Xy08fKWcNTRAgKwaejT3EQuMdkToZqBUlJCL3VktEylTLHZOso6Sl29KKM49q XuN0f5EPlCge2mF691si7qybkJsezI38o7YhlzhcSbE9sPXXXnOaDG/1HRoEMZ7I so6gT9X9Zn09BAb6B7QzsLo21ztAOi8wASVB6X2GUZydrdyiPwu6qQgjO3PlDGsZ VpiylUzWbfV5h73vdIr7Lhy3P8im/W5u//WjT8OR18jE8Ol4j5npFGqXaxljZHz1 HsK6tG3lQ2//pMNPzMKyzWI+zvSnCg== =8DRM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 15 09:50:33 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E1F13171A; Wed, 15 Mar 2017 09:50:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148959663171.14162.12842116802682668622@ietfa.amsl.com> Date: Wed, 15 Mar 2017 09:50:31 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-voucher-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:50:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : Voucher Profile for Bootstrapping Protocols Authors : Kent Watsen Michael C. Richardson Max Pritikin Toerless Eckert Filename : draft-ietf-anima-voucher-02.txt Pages : 19 Date : 2017-03-15 Abstract: This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". The voucher artifact is a YANG-defined JSON document that has been signed using a PKCS#7 structure. The voucher artifact is generated by the pledge's manufacture or delegate (i.e. the MASA). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-anima-voucher-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 15 09:59:53 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F173A131715 for ; Wed, 15 Mar 2017 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 UzXM1T5uG5mY for ; Wed, 15 Mar 2017 09:59:50 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9761316A1 for ; Wed, 15 Mar 2017 09:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cudVn2IbepRZ2ScDnVqpmr8wakSyRv5m/vlWtf0fQHA=; b=ZuZiLBbQGrhzjIZ4dxJFolWGKTvPK2yKOLEKi1CwpneyJ1Fo/PQOzPmazVNEhldvr3vfJjYx+sZ7DLFFQJthuoIQUiPa/NILbAs8NoNl8Hf81SI548uKVLxmQ6RTqPDhI1w+GChPEEFJWznslvTZkoImtYXaXI34QQVgOlA6aqo= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 16:59:44 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0977.010; Wed, 15 Mar 2017 16:59:44 +0000 From: Kent Watsen To: "anima@ietf.org" Thread-Topic: [Anima] I-D Action: draft-ietf-anima-voucher-02.txt Thread-Index: AQHSnaxE6R/jK51EqEO795oGO9Wl9aGV3K6A Date: Wed, 15 Mar 2017 16:59:43 +0000 Message-ID: <9135C6C8-24C3-4123-80AE-6EDBFE265F49@juniper.net> References: <148959663171.14162.12842116802682668622@ietfa.amsl.com> In-Reply-To: <148959663171.14162.12842116802682668622@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:DuCepN21IuCT0Jt+OFjaKxjp/7+bWLu9DJ9Dw1ygDh84WF3khZOXgofHysoveQjzKeU4EqqUTDSsa+PXoUvIgOjEUH9CQFbVoT+zelSsp2Jzv2L+20cfm/WdYoSxetCt83jFoRdPnEJwDf7O7gSs9BRo+5idCfQwuB3qbesVRkxHfzysIUrIyI8FcG3Vaq859jHocmNZGjFleGpn7/unkQme7jIUMN0D4pUwQw/rUFiClmwv3Q74xvNvBxgD86BwkjdgdE19OC+JwAI0vSZgjhcUV/8mV9b8iTsU8E/bWE9WobxeXMVwdYmx54X93KIZCb21SQgkmh7hYIzVPyqkKw== x-ms-office365-filtering-correlation-id: 7bfd0c2f-824a-4565-57dd-08d46bc4add2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(377424004)(99286003)(76176999)(6306002)(6512007)(86362001)(122556002)(77096006)(54356999)(6436002)(6506006)(50986999)(36756003)(2950100002)(5640700003)(229853002)(2900100001)(6486002)(2501003)(189998001)(2351001)(5660300001)(4001350100001)(33656002)(82746002)(25786008)(8936002)(81166006)(83716003)(6916009)(8676002)(2906002)(66066001)(1730700003)(3660700001)(230783001)(7736002)(305945005)(3280700002)(3846002)(102836003)(53936002)(6116002)(6246003)(38730400002)(110136004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8AE3A42ED02EC84DB962BF057B0A6FDF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 16:59:43.9187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-voucher-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:59:52 -0000 QWxsLA0KDQpUaGlzIHVwZGF0ZSB3YXMgcG9zdGVkIG1vc3RseSBieSByZXF1ZXN0IGZyb20gb3Vy IEFEIChCZW5vaXQpIHRvOg0KDQoxKSBzZWUgaWYgdGhlcmUgaXMgYSBkaXNjcmVwYW5jeSBpbiBo b3cgZGlmZmVyZW50IFlBTkcgdmFsaWRhdGlvbg0KICAgdG9vbHMgYXJlIGhhbmRsaW5nIFhQYXRo cw0KDQoyKSBzZWUgaWYgdGhlcmUgaXMgYSBidWcgaW4gdGhlIFlBTkcgdmFsaWRhdGlvbiBOSVRz IGNvZGUgKHRoZXJlDQogICB3YXMvaXMsIGFuZCB3ZSBmb3J3YXJkZWQgYSBzY3JlZW5zaG90IHRv IHRoZSB0b29scyB0ZWFtKQ0KDQpJIGFsc28gdG9vayB0aGUgb3Bwb3J0dW5pdHkgdG8gZml4IFRv ZXJsZXNzJ3MgY29udGFjdCBpbmZvLg0KDQpDaGVlcnMsDQpLZW50DQoNCg0KDQpBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdXRvbm9taWMg TmV0d29ya2luZyBJbnRlZ3JhdGVkIE1vZGVsIGFuZCBBcHByb2FjaCBvZiB0aGUgSUVURi4NCg0K ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBWb3VjaGVyIFByb2ZpbGUgZm9yIEJvb3RzdHJhcHBp bmcgUHJvdG9jb2xzDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEtlbnQgV2F0c2VuDQogICAg ICAgICAgICAgICAgICAgICAgICAgIE1pY2hhZWwgQy4gUmljaGFyZHNvbg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBNYXggUHJpdGlraW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgVG9l cmxlc3MgRWNrZXJ0DQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1hbmltYS12b3VjaGVy LTAyLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDE5DQoJRGF0ZSAgICAgICAgICAgIDogMjAxNy0w My0xNQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHN0cmF0ZWd5IHRv IHNlY3VyZWx5IGFzc2lnbiBhIHBsZWRnZSB0byBhbg0KICAgb3duZXIsIHVzaW5nIGFuIGFydGlm YWN0IHNpZ25lZCwgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSwgYnkgdGhlDQogICBwbGVkZ2UncyBt YW51ZmFjdHVyZXIuICBUaGlzIGFydGlmYWN0IGlzIGtub3duIGFzIGEgInZvdWNoZXIiLg0KDQog ICBUaGUgdm91Y2hlciBhcnRpZmFjdCBpcyBhIFlBTkctZGVmaW5lZCBKU09OIGRvY3VtZW50IHRo YXQgaGFzIGJlZW4NCiAgIHNpZ25lZCB1c2luZyBhIFBLQ1MjNyBzdHJ1Y3R1cmUuICBUaGUgdm91 Y2hlciBhcnRpZmFjdCBpcyBnZW5lcmF0ZWQNCiAgIGJ5IHRoZSBwbGVkZ2UncyBtYW51ZmFjdHVy ZSBvciBkZWxlZ2F0ZSAoaS5lLiB0aGUgTUFTQSkuDQoNCiAgIFRoaXMgZG9jdW1lbnQgb25seSBk ZWZpbmVzIHRoZSB2b3VjaGVyIGFydGlmYWN0LCBsZWF2aW5nIGl0IHRvIG90aGVyDQogICBkb2N1 bWVudHMgdG8gZGVzY3JpYmUgc3BlY2lhbGl6ZWQgcHJvdG9jb2xzIGZvciBhY2Nlc3NpbmcgaXQu DQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFuaW1hLXZvdWNo ZXIvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYW5pbWEtdm91Y2hlci0wMg0KDQpB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hbmltYS12b3VjaGVyLTAyDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkFuaW1hIG1haWxpbmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0KDQo= From nobody Fri Mar 17 06:56:10 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE4112943C for ; Fri, 17 Mar 2017 06:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2_v2PWYkTVRu for ; Fri, 17 Mar 2017 06:56:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F1C129438 for ; Fri, 17 Mar 2017 06:56:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A781205BD; Fri, 17 Mar 2017 10:19:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 516D0636BB; Fri, 17 Mar 2017 09:56:04 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: anima@ietf.org, Michael.H.Behringer@gmail.com In-Reply-To: <20170306220030.GB7471@faui40p.informatik.uni-erlangen.de> References: <20170306220030.GB7471@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] MichaelR: section 5.1.1 question (draft-ietf-anima-autonomic-control-plane-05) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 13:56:08 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > I remember from Berlin that you wanted to suggest a better > format/encoding for the AN domain certificate to indicate a > pledge/devices ACP address. I have not seen a followup re. this item (i > apologize in case i have overlooked an email re. this). Hi. sorry to have not replied to your email. My thought was that we should have an actual subjectAltName otherName entry. I had originally proposed defining a new OID for the IID part of the address, leaving the upper bits up to the RPL PIO. There are other options are to use the subjectAltName iPAddress choice. See https://tools.ietf.org/html/rfc5280#section-4.2.1.6 I think that I proposed text that would allocate an EUI64 OID for the certificate. (I have operational code using mbedtls (client) and openssl (CA) to do things using an OID from my ORG_SANDELMAN (46930) PEN.) If the WG has consensus on this, then I'll dig the text up. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljL6vMACgkQgItw+93Q 3WXvNwgAlKwkCMMEYcxhOaNmohAFLqF39ZrQK90vQe8xLhe9yVFziZmY6RcdN5Hf JpJWlKtYOf0JHECGpPj+pJD3neDR1w7Vfz1H9+d/IXzMs/D+dLgHyBj4yCgYi0cY g6GX0duVacwSgp1rgpNMRzm6ajVCOTw6+RPvLap0OcWhP8kfodnTAC7Hq13SKDou Ky9PDiWUTQg6+zrHKlYKW0HnmN3VT4uT+UBhiL82iV5nEpKBwlTHsy79ZUiaxUwx bXnz2mmYcvQ+QKj7o2gmcgkW60xMK8uV2FFJJCYNJu7i8aqeeNkXwhD7zg5r20K2 vuc06Gie4+o3DOZkXVhG1PyawT5vWA== =2BAH -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 19 17:51:52 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F1E129435; Sun, 19 Mar 2017 17:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 ZlxVBL7NrckS; Sun, 19 Mar 2017 17:51:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05DF12702E; Sun, 19 Mar 2017 17:51:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJE56963; Mon, 20 Mar 2017 00:51:45 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 20 Mar 2017 00:51:44 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 20 Mar 2017 08:51:37 +0800 From: Sheng Jiang To: Anima WG CC: "anima-chairs@ietf.org" Thread-Topic: =?gb2312?B?UHJpbWFyeSBBTklNQSBBZ2VuZGEgQCBJRVRGOTijrCBDaGljYWdvo6wgVVNB?= Thread-Index: AdKhFBq5Bm3c6JxpR4OR3MdEIX+0gQ== Date: Mon, 20 Mar 2017 00:51:36 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CCD49DE@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CCD49DENKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58CF27A1.01E7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3b82fabd7f7189f5d5a32f0c30ee8a8b Archived-At: Subject: [Anima] =?gb2312?b?UHJpbWFyeSBBTklNQSBBZ2VuZGEgQCBJRVRGOTijrCBD?= =?gb2312?b?aGljYWdvo6wgVVNB?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 00:51:51 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CCD49DENKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFOSU1BIGFsbCwNCg0KVGhlIGNoYWlycyBoYXZlIHVwbG9hZGVkIGEgcHJpbWFyeSBtZWV0 aW5nIGFnZW5kYSBmb3Igb3VyIEFOSU1BIFdHIHNlc3Npb25zIGluIEJlcmxpbiwgR2VybWFueS4N Cg0KTW9uZGF5LCAxMzowMC0xNTowMCwgWnVyaWNoIEEsIEFmdGVybm9vbiBzZXNzaW9uIEkNCkZy aWRheSwgOTowMC0xMTowMCwgWnVyaWNoIEEsIE1vcm5pbmcgc2Vzc2lvbiBJDQoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OC9hZ2VuZGEvYW5pbWEvDQoNCklmIHRoZXJl IGlzIGFueSBxdWVzdGlvbiBvciByZXF1ZXN0IG9uIHRoZSBhZ2VuZGEsIHBsZWFzZSBsZXQgdGhl IGNoYWlycyBrbm93Lg0KDQpUaGUgc3BlYWtlcnMgcGxlYXNlIHNlbmQgeW91ciBzbGlkZXMgdG8g dGhlIGNoYWlyIGluIGFkdmFuY2UsIHNvIHRoYXQgd2UgY291bGQgdXBsb2FkIHRoZW0gYmVmb3Jl IHRoZSBtZWV0aW5nLiBUaGUgc2xpZGVzIGFyZSBkdWUgYmVmb3JlIDRwbSBvbiBTYXR1cmRheSwg TWFyY2ggMjV0aC4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZyArIFRvZXJsZXNzDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B927CCD49DENKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, ANIMA all,

 

The chairs have uploaded a primary meeting agenda for our ANIMA WG = sessions in Berlin, Germany.

 

Monday, 13:00-15:00, Zurich A, Afternoon session I<= /span>

Friday, 9:00-11:00, Zurich A, Morning session I

 

h= ttps://datatracker.ietf.org/meeting/98/agenda/anima/<= /p>

 

If there is any question or request on the agenda, please let the c= hairs know.

 

The speakers please send your slides to the chair in advance, so th= at we could upload them before the meeting. The slides are due before 4pm o= n Saturday, March 25th.

 

Best regards,

 

Sheng + Toerless

--_000_5D36713D8A4E7348A7E10DF7437A4B927CCD49DENKGEML515MBXchi_-- From nobody Mon Mar 20 13:08:21 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19ACD1274D2 for ; Mon, 20 Mar 2017 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 z0VBNIjdEEQg for ; Mon, 20 Mar 2017 13:08:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0502126C0F for ; Mon, 20 Mar 2017 13:08:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2597DE1FC for ; Mon, 20 Mar 2017 16:31:40 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B563A636BB for ; Mon, 20 Mar 2017 16:08:15 -0400 (EDT) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] CASM BOF X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 20:08:20 -0000 --=-=-= Content-Type: text/plain https://trac.tools.ietf.org/bof/trac/ writes about: Coordinated Address Space Management (CASM) - Approved for IETF 98 Description: Organizations use IP Address Space Management (IPAM) tools to manage their IP address space, often with proprietary database and interfaces. This work intends to evolve IPAM into standardized interfaces for coordinated management of IP addresses, including SDN/NFV networks and other forms of virtualization. Use cases include dynamic allocation and release of IP addresses and prefixes based on usage (reallocation in case of no more in use) and/or user intent (for specific services). The purpose of the BoF is to gather a common set of requirements from a larger set of operators and, if needed, possible protocol work milestones and scope. It seems that there should be coordination with ANIMA... consider showing up to this BOF!!! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljQNq4ACgkQgItw+93Q 3WWYAwf+J1x0IMu4Ep93j9kKXB8A2fNcqXwTsCCU6PQnxsXLR8xeClVcNVHyXBnN NiNN9wgTlTPMUSmz+W4BsgczkHFAOVeLawYAxGicB0eJTITC++Qc+OF0hUj/96Wq X7fK9naP8HRBvWyxl6zB18BY8r4PkZ+jxarbT0KVNchuQRG/Drq0+udaWyjBuvNE T0xkMHqatvZW+2ZTFTnN+HViPSru6Nw7LvW9OGK5YSWs9VI+WFO56HvOxtl8GjwZ UrGXdxTchlG9s8/bHB2qzyOlUY5LceJRMO25j1aY1ht/eC+WUf2XjaAb93MxDe9j sxLX/Bpw2i/nsPyFVWmzrAQ6ETbudQ== =U1OV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 20 14:50:28 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BD2127B31 for ; Mon, 20 Mar 2017 14:50:26 -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 tNhQ6EbfYy92 for ; Mon, 20 Mar 2017 14:50:24 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD461293F4 for ; Mon, 20 Mar 2017 14:50:20 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 190so8570002itm.0 for ; Mon, 20 Mar 2017 14:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=jAfRoF7VlA9OgsjygNcUHnt7BjvjldAmPA9fq8cB/kI=; b=tRthXqijNTMgpppLXTQIh+5NkH0iF8fo3nELYggzSBRxP/IMgMQeyKUfM8n6bCJKcr gsPM+ZD2cZvOTn0sDQI6F19lmPmP4+k2wJS5pQiqn6JLGWcLikqb8pfcUmRT4OcMBEEw ym6qvpkJI1WOX8tIqVbWSCgwNx7D+mIvhVBRuD8pHaXKca+huAjDr+Kcv/DOcVrDtwGZ 6i7kWGqmC+GpFr+I4arRZ5TFKWsuprG/judCrrwzvBzxsED5DzxZOCpETDCjrb8d+/XE VxdsKTHx2SaU7TSvBlOARi92awYWGQ7cf4Vdr1Qw80SNaoQLBnyhtNZY7PN5qMvRLpzw w2Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=jAfRoF7VlA9OgsjygNcUHnt7BjvjldAmPA9fq8cB/kI=; b=Qnc9OhzP8Vqm/7DqyrlqgxBuQb5fGB7WZNGHFUYQiMukI1fySQIldJhT8L+0xABRyF R7SZlO997Nd5C6Em2rcP2a34ZByRkCCZPvlYIJrd1UuU0wDaibZSzBh+RlzM32E176D3 Z8W9y1nOoVukEUoQ0w8aGJ2y1FPRLeBTUmnnbHddygU+JwPn9V+K8/6LImRD5viwkV/C tSEYh31sxkIJZ9+v5X1gBmlLcqL4E9O+UX8zQ91kuFIMXvdgYUP2M15YTIwyBXTwORLt 6MPumRIKcNhPP0yKG73531Po6s5Dh6ZRtH4ovastIyokwYrNkLXI2m7+fhoc+PylsCTt umjA== X-Gm-Message-State: AFeK/H0SlmFWnqdpLSYaYTG4igmNZWkR4OBpHQXTGp3nQZl3xl0Nkw5xa3F0sjgRvJHEJw== X-Received: by 10.36.82.82 with SMTP id d79mr254869itb.29.1490046619298; Mon, 20 Mar 2017 14:50:19 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id e195sm5786018itb.18.2017.03.20.14.50.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 14:50:18 -0700 (PDT) To: Michael Richardson , anima References: <583.1490040495@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9c4fa532-7abd-1f70-51d3-514463ddb0fd@gmail.com> Date: Tue, 21 Mar 2017 10:50:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <583.1490040495@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] CASM BOF X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 21:50:26 -0000 I've been tracking this a bit. Their main focus is on a YANG interface between the NOC and the IPAM system. It's thanks to me that the C stands for Coordinated instead of Centralized. I believe that our prefix management use case is part of the back end for this rather than competition, but we should definitely track the work. Regards Brian On 21/03/2017 09:08, Michael Richardson wrote: > > https://trac.tools.ietf.org/bof/trac/ > > writes about: > Coordinated Address Space Management (CASM) - Approved for IETF 98 > > Description: Organizations use IP Address Space Management (IPAM) > tools to manage their IP address space, often with proprietary > database and interfaces. This work intends to evolve IPAM into > standardized interfaces for coordinated management of IP addresses, > including SDN/NFV networks and other forms of virtualization. Use > cases include dynamic allocation and release of IP addresses and > prefixes based on usage (reallocation in case of no more in use) > and/or user intent (for specific services). The purpose of the BoF is > to gather a common set of requirements from a larger set of operators > and, if needed, possible protocol work milestones and scope. > > It seems that there should be coordination with ANIMA... > consider showing up to this BOF!!! > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Mar 20 16:01:34 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90B4127077 for ; Mon, 20 Mar 2017 16:01:33 -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 m-5wNl641RFn for ; Mon, 20 Mar 2017 16:01:32 -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 EF61E126D85 for ; Mon, 20 Mar 2017 16:01:31 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id y18so197579itc.1 for ; Mon, 20 Mar 2017 16:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=wHZtGsbAv/JFsW4VFUqbs2nphs1Bgz2/L4lqT2BC1p4=; b=OVwhhrdx3YlePlP1zN3apyGjtskRPSlwPRSfcupFdF0kAwJj/TOBEx8wXOieIJiCa+ U+9G2nCyBkNYND+JfCFVTjbosNIQ6QHd7ANQ4lDM+Dasc4PDHM3aLx/Ff3PwTvDtfYPw KsFRO1e0ylKyk9xLcSmK6d3sW4ClvKPRFBwPBjI9xTiSzcp7p0ZEzxpbAD9Z1+OIvRZR Ol8UPkKwj+F4+uq4e4qMJrHO2C5fIZAH1kUwWSiUJ9cdZpVV2LN7YsfuTMZCU4XND6ik te7t6Jc+ycfkleVvpUhl8w8f8GMobhqjWKHGXwhTDPLoo3U0hdO7H4kmGmpD9dGolZQZ s0qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=wHZtGsbAv/JFsW4VFUqbs2nphs1Bgz2/L4lqT2BC1p4=; b=bomNJcRh0l/vT2cMhET4j3p/ao2UrvpUtKFUxEh1GB3b/Lf9IVIY02h4ZtXpQzXDKy VKlZgcdzmBQpqSDZRLaxyKchjWJ/mxU88axfv/TKDcrRTHnAxbp+8K2d6OvUB3pmgbU9 Lo4BbS6juW0+pRhAt3PNPIoX3AF2nOblTXfmnkwFVtsn4TF+AgrwMgi4zkjKffMgTu7h 2AzCUJqryuj80JDtJEdAuZIx3OK0BQvleRkF5xWRhJM4L/nH0rm+AfVAbe3LBXrb5nhp rTDmOML6KIsqRCv98egUy4WELr2P0X89t4DcbIT/PZi7V/uUHqEKLKZaGQHCuHQ/WVyf Dw6w== X-Gm-Message-State: AFeK/H0IbHpIQnJsdSHiRoFzqDU8Kl+ZI18/eGCQ3E89HA8j5m6NbbPLmJsfkUrFR0tBUQ== X-Received: by 10.36.77.148 with SMTP id l142mr11211itb.69.1490050891279; Mon, 20 Mar 2017 16:01:31 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id k68sm9213225iod.13.2017.03.20.16.01.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Mar 2017 16:01:30 -0700 (PDT) To: Michael Richardson , anima References: <583.1490040495@obiwan.sandelman.ca> <9c4fa532-7abd-1f70-51d3-514463ddb0fd@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <622210d9-daf1-d5eb-aed0-7d427fc62a5d@gmail.com> Date: Tue, 21 Mar 2017 12:01:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9c4fa532-7abd-1f70-51d3-514463ddb0fd@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] CASM BOF X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 23:01:34 -0000 Specifically, if you look at https://tools.ietf.org/html/draft-sun-i2apm-address-pool-management-yang-02 you will see data that could be used to trigger an ASA for the PrefixManager and PrefixManager.Params objectives defined in https://tools.ietf.org/html/draft-ietf-anima-prefix-management-02 I've written some "toy" code for those objectives, by the way. It doesn't do anything real but it can negotiate prefixes with another copy of itself. I'm hoping to make it better during the hackathon. The first cut is at https://www.cs.auckland.ac.nz/~brian/graspy/pfxm1.py Regards Brian On 21/03/2017 10:50, Brian E Carpenter wrote: > I've been tracking this a bit. Their main focus is on a YANG > interface between the NOC and the IPAM system. It's thanks to > me that the C stands for Coordinated instead of Centralized. > > I believe that our prefix management use case is part of > the back end for this rather than competition, but we should > definitely track the work. > > Regards > Brian > > On 21/03/2017 09:08, Michael Richardson wrote: >> >> https://trac.tools.ietf.org/bof/trac/ >> >> writes about: >> Coordinated Address Space Management (CASM) - Approved for IETF 98 >> >> Description: Organizations use IP Address Space Management (IPAM) >> tools to manage their IP address space, often with proprietary >> database and interfaces. This work intends to evolve IPAM into >> standardized interfaces for coordinated management of IP addresses, >> including SDN/NFV networks and other forms of virtualization. Use >> cases include dynamic allocation and release of IP addresses and >> prefixes based on usage (reallocation in case of no more in use) >> and/or user intent (for specific services). The purpose of the BoF is >> to gather a common set of requirements from a larger set of operators >> and, if needed, possible protocol work milestones and scope. >> >> It seems that there should be coordination with ANIMA... >> consider showing up to this BOF!!! >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> From nobody Tue Mar 21 07:12:30 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F39129705 for ; Tue, 21 Mar 2017 07:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 T_CI6Wj7uXmH for ; Tue, 21 Mar 2017 07:12:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA5A1297E1 for ; Tue, 21 Mar 2017 07:12:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D948E209; Tue, 21 Mar 2017 10:35:54 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5DC2C636BB; Tue, 21 Mar 2017 10:12:27 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima In-Reply-To: <9c4fa532-7abd-1f70-51d3-514463ddb0fd@gmail.com> References: <583.1490040495@obiwan.sandelman.ca> <9c4fa532-7abd-1f70-51d3-514463ddb0fd@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Tue, 21 Mar 2017 10:12:27 -0400 Message-ID: <18243.1490105547@obiwan.sandelman.ca> Archived-At: Subject: Re: [Anima] CASM BOF X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 14:12:30 -0000 Brian E Carpenter wrote: k> I've been tracking this a bit. Their main focus is on a YANG interface k> between the NOC and the IPAM system. It's thanks to me that the C k> stands for Coordinated instead of Centralized. Cool. k> I believe that our prefix management use case is part of the back end k> for this rather than competition, but we should definitely track the k> work. I agree: it complementary. I guess I think of ANIMA as being the front end that talks to the IPAM in the back-end :-) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Mar 21 09:05:24 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C911296B8 for ; Tue, 21 Mar 2017 09:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 1Xu-8-BGl2Wj for ; Tue, 21 Mar 2017 09:05:19 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0108.outbound.protection.outlook.com [104.47.1.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B88129AB3 for ; Tue, 21 Mar 2017 09:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Uv6pOxphUOoT0lbabSpnxEZUBwlSFlDJTBXq7TBTHIk=; b=lYqBiAU9mWoGDTh4qI93dAs8RclUM9fZqzZCXi6LUb5F2iHccA6lC7mZQ8iUf8e90Nyw3i1huGf3PzVTX7yR7PMgpBymChBq5NWpDrPVZvL81MSbF19dnjRxdb53E114v1vgzKOCY88RjGSiH4YWL/8Pmz7LU8AZ6iO/rp/HD+E= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia-bell-labs.com; Received: from [135.224.222.104] (135.245.212.8) by VI1PR0701MB2205.eurprd07.prod.outlook.com (10.169.137.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 16:05:15 +0000 To: Michael Richardson , Brian E Carpenter References: <583.1490040495@obiwan.sandelman.ca> <9c4fa532-7abd-1f70-51d3-514463ddb0fd@gmail.com> <18243.1490105547@obiwan.sandelman.ca> CC: anima From: Laurent Ciavaglia Organization: Nokia Bell Labs Message-ID: Date: Tue, 21 Mar 2017 17:05:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <18243.1490105547@obiwan.sandelman.ca> Content-Type: multipart/alternative; boundary="------------C683432639E646C1F533D82A" X-Originating-IP: [135.245.212.8] X-ClientProxiedBy: DB6P191CA0018.EURP191.PROD.OUTLOOK.COM (10.175.236.156) To VI1PR0701MB2205.eurprd07.prod.outlook.com (10.169.137.26) X-MS-Office365-Filtering-Correlation-Id: 23dc8fea-3198-4dfb-3b49-08d47074109b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:VI1PR0701MB2205; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 3:mcRq+MaJOvYzMChtEifzwnoOwD8mMlYNx4P6d7abwYcYwGk7b5whPgppnn58loaGdIH7DCJXCZ3iUYzkQ9FbmMrRDiDXIFdeauF4OM0tlU+8YdcStpnex0XiSfAeTkPVfJHP7NV+FCB7348JWKNdoB0fx0/0Eh1U+PUVL2YEPNzN3BEyLbnER0EZF14NT0OjrfZ8KDb7rqdczaHe0QeSmzg1QniXV1W4nz9nh+PnnGe0mULAM4+Nvp4L3Fby8hdOnRk/exsIu9JQ5o0hItfGF8nLvjsxBk3MYesB1mOW4ZA=; 25:FEk+ccguvllorFTYeAsUNKNvfzgz198r/I7MwQClBJN/RW2FUPSZFFVDX1poAuHpjjxvt0Sc9hPvJrHbnZxgcyn3fNCMlNSBc23Yqo7zn4rjmiLuVVi8F//IcgZKa5tawiWObjmERledmMRDBcwvlcMCzSCOqTIH+5mXq1JfqFTylCf8Wj5Y+mDiq3Xav6BMv9EF+GHDjXk9shYHdVHvXjufw6yP8aW4jqlgI4uDh6SUzg/t33nz/Stbez2hAL7iX0ktC3jPsBq0Mh7czgDIavKZLewbZg01AloqTaED5qzHwXp4t8Gn3bFGR5oNV2h/FBSBCSKn1CRlFCQT316WRK84hA1N6RfxmahCYm6ttkLha7tJtP6bWf/Zx7sgXa6yLmajFJ+rarScaPu1ABcoJa3cAzcvBxS6w0yxK02MEsv+a1ldeNi17az6um90C5Gc8v7/UiaQ25//Gm9Sd+Mmnw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 31:pyGv/dHwzPnPzjKmKcm+Us/9TCsSOcAgxtQ+j3nlpnZYxeebwb2PIR+lymtkChuSOMpzFQpFTCQfvtHGq45X+lm0q/8HvAfvZ97wTzIR+u1F/QwQqPV8KW9eDY7K/AuKxONoCzTDLOg+88fvF2m4S56OeRXxUA5lEp4YSLE1Zfg4rupUbuuPbslUGsjLGrXWGs2g2dFfVbZaMP4YfTMcUdMknwyHB41MtWVIktXGaTLtDIjGVuuA84wdCzhLsiOGCG3x3FSeuM5fzPenVDqP7Q==; 20:8Tr6C/Jj5cKUke+KBFVoS76BoUaBCisria6Le1Ip+sGv5heQ2IJJlvV7Ca6qvF3Vtyg/azxr4wjofmcDXoLaOfzp31vajUywy21BB7Ce6YeBuiVkdocIKuyGudKm3TMA4+F5vw8Q1PIl5fyIPMlcC1Tk3lBvfk8aOzGp47xXZ+xAgJuQnBq+O5x9VxpD0+8Ed0QoLDGBwxhA/Q6fPvSACIqdgetOF5nkUzYqduo4HvLQG5jJ4kUKw5cnCF90p9JpCl1pQVXtg3MpTTStkvKTEAHngdC9TScHlXHMyHPfnWfn2ynDRuHNb+0fWuT9uobgFjomEGUtjhWjj/v0yP9b3eWqbX+4m3Gc+b+6Q2djf823kJ+N0LzerFn9b72Y8Uw3KGeaV4E+H7P5Xfb+bSBSppMEO4pz52D4Ltf/ohffftyErtREzkw6awxzgmhp2pa9BmAODISGF/xF8yeSHb6/xgK3pkEY4yyDBLw0OwGlqGnkwgc+ora781spzGgHOzFq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(81160342030619); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:VI1PR0701MB2205; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2205; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 4:srM7knsoSknaRBib5V6dHfLdfqXSWcLy0HGBMEjAN1xce52xIfj3XcgMnvQ4z6dL8i3f2hD4oGzDsIJ+vUEcn3fuBqy005pbV/DDzgiuj7LreXfDKYlud5vkuWP1Cw2qAZHMb4QEVHTGt7/ASPwxFTyuDFbdWLGg0mza+ZEHueoEVO/8DuF9FQhsiynDhFyiwHYx0buLKjWaOJCaQiB1z2sf4UN4AQ/emS1D+kjKzlzZRKDoG8HAOQHS342N+wZ4dOxa4gmJuYMVYkoXA7juNCu6AiGFEWuDuIYyXBQ/IhFV0W8pd0BeWyXpacmyCHfPmrGhtXCzFyDGZziGPBdPn4qxqYiiJJ7XjAqL+Rn+IO9z4kFmctx7Q7KZIAEWT4R4mUPzD0v2Zb7SjLM8AmdaRZGEk83XKjKLypISDYnF7qPcns+/S0Z3gsxkZPZgtCycmQfWEz4Cz48NtS2triIs6+EYQhfWXtCCoRCWvJujQdwfMdsen2xneu831G8K0PwM0Wwi4TVBW6kDkAvY3PC/P4IVyrVmhyL6rnxJ4iF7f0udfRrxu1kLoHdPRtmMhxG75bwyxmqcvd+Cp7PTtEeq+J8m3B/PMSKoDh0NSRD1u4pP5cqm+F9vNnpNQIMoPbLNc3x8yUZyyo5zV0aUc7dMm3ATjKF0BrZKUDHngl5oXes= X-Forefront-PRVS: 02530BD3AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(39410400002)(39450400003)(39840400002)(39860400002)(39850400002)(24454002)(5660300001)(76176999)(31686004)(50986999)(42186005)(54356999)(4001350100001)(54896002)(36756003)(189998001)(6306002)(33646002)(606005)(966004)(236005)(65956001)(8676002)(81166006)(6486002)(53936002)(65806001)(90366009)(66066001)(4326008)(2906002)(229853002)(7736002)(38730400002)(83506001)(64126003)(84326002)(6246003)(6666003)(2950100002)(3846002)(6116002)(86362001)(7906003)(512874002)(53546009)(31696002)(25786008)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2205; H:[135.224.222.104]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR0701MB2205; 23:jl2naFXsXPB23V3sToiompgNyUEjMUfSZBMmhS5?= =?us-ascii?Q?i0Q6GafehyqrYFERrqfiZEFvWjRfKfGsK14R5I7jPC8BoVZbZeVWG8pf2bw8?= =?us-ascii?Q?x4RMwHEG5AP1UQZzuTvU1dluBk41shRXhNA3wvIA20v6nNf9JmqZFvIuH8qX?= =?us-ascii?Q?SLj/L/bW6Id1MM+H/xtBFtGU8gnacQX1faVNRcDXOMMJwIssEB4WThS5YRfj?= =?us-ascii?Q?WH1+9ooKawm8r2W9nH9CuhSbR8dtXJ/uHspS0zoehPg/SbdG5SOVIABudsB8?= =?us-ascii?Q?OLf8XRREkQj+bAPaNH5jQZY4+2kkCG32oMRWGBKdiEenzyPTeuzRRmtw6BtH?= =?us-ascii?Q?ceANHbh9RFnsGz25pHWihYJ4321D3HsMXXJ+9MMxR1rvZyswnHBZcz0q8oaM?= =?us-ascii?Q?4NfaA5vrGQGgXkmHxMa9f1KbNcoZrkPzhnKEpP+4tyEHpBN/KF0wx7G9+14l?= =?us-ascii?Q?MltROG3GU76XokkYu76YrElFc5RHAFDYoOk/WmRI+LelBPIGTl9GMx+aUCvu?= =?us-ascii?Q?L+g+BlU3io4whJbfOMSEXkMloOEcWhjq16LBT0Xu5GZwCWDJKplsR+DHQt99?= =?us-ascii?Q?NctsczDOL6zmGwdT3q2wIQwSeyWqEy6jr6JMoKvhvLehM1QPb+ME9mGjn4px?= =?us-ascii?Q?bYpOwwU16nxCb3l5uYCPDJAb0v71HsbfxWW0ivoYvibNgB52VSB0ZKChNoor?= =?us-ascii?Q?S8IGf1isHjhkotTzhNy2d+D9HsPz9D1uPQ5WkcpKAdRLvl+diXMl/ZDIIdvZ?= =?us-ascii?Q?kbzp1HaInKDy0cvs0wdd2oe0aQMWuJvZTzQu/xZNfbUwI00em19na8OWMKzD?= =?us-ascii?Q?7Z1cMUAa141BUr2TUaAkaTo52tHE+iEkTaWLnSyFVNkYeFVJD2O/avwVOP/q?= =?us-ascii?Q?hxi99GdW6e8zoEm3PNxT7UsjBUk+4QcsT7BG1eGuioSF0cEeKzX9yf3GcBgV?= =?us-ascii?Q?Qi6bFKboiwjMtc+X4FAaLZq/ajATtmqxZRTxZkIv23jAWarHNNc7XiIJotMe?= =?us-ascii?Q?S/b48IXo+MQ1qF21xpJX0twi2U5enW4JCxYu/l4wjt6pacorU7IlDSR5GeZt?= =?us-ascii?Q?+gwSYKW2m+7ZVn4DeoHZ1NxEnx/BwxcZTkPbU5HwsrgV68uj1xmRt3GzSBwB?= =?us-ascii?Q?NBuZ8R/QBjepXsMBwfgR8k/1kyFaEJxIaX/fJyykuLsFQ4OAphC4EetM8y3t?= =?us-ascii?Q?N++Mt6+SZBtm2ZsKCRuXWPMU8d/Ow+2shItbY1iC3NP3ESFRaQaN0+TLGKwc?= =?us-ascii?Q?yckS9YMKILE0jULX4tko=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 6:eYf7GYn0Mnjippe+UQR2Uiw6cQwITBUzTv8UFrJUbHFIQSIlR4n3BdBVfs4d+9A6b3/8VHXM4CTCoS+7rLnBV1Ufmu5S3QO4+3bStRofIebi1V233MDfzQQXodiz1gL4hSIFo8LisxCMYKu5A2xZLJ1gY97P7lIBHVKqFYTeSgqaoUOAWLbFr0gOUm+tQ0C3InYI/5zutbKGog8y5k0po09GihgoEfMCAzYq5RDRJHEoO6RSPrDf0g1HKg1ejZvpTyukTSPbaIeGSDGfoMDv3dlaMIIg7eim+Pp9MhD2CuK5MObUOD453rJ38/3TlYYuh6YZA2nShSi0wuONNXND9YyVar81sz05EFL/Ahe6vrUNs73vA5Aju8v6tZ3yCwG6j99Qa6jaODzchu2ZI+xgihffnM1nzS16vfym3r2hjCA=; 5:BCSslB5VE3D2TRl25NubOhMaEQo4BcOFUXAFi+S1Fjl0bZW7SAkC0dMj5qZZ1N086obdoN5WmXHzxCOGNLpC7TzF/1WM32SHWx3R4k/OH29O0ZR3pZRvU9XAwnjoDawyRZ1ZS/nrnYzyWIy5bnR9fQ==; 24:XXgfUBLH/AYA5aTK3bcMLYlOBw51zP0jnm7PcjTtOWwdbf5TuI2o5Uy/yZLwEg55sSIMfH9gEFE/Iv9Ieci7NQWCJkYsyCKCwJcA/8wo0po= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2205; 7:3LBZZXzEu7xQEoNwiqud88jTmv5U4pWUru7MpT9JSDX2XQYH2kf1aXqozEm66BNyyzeVW76z7SFw7ARfyg8YJKxf15fuWs9VevhatGOPqSUTULXszl4HO4x0wOGrpstFzve4D59lMXutUYt2E7r4c8gyAN2NWghA2Nzl7APBAEgGciHflbeTCUXMl69tllexUwLu3pSYagjMu/th1lKw6ZrulOmhpNT4AnDUP2XGyhAISB/2bV7NmauicH+t1gExITE/+f7V64Kn0Wqwo8cyqXmaZFqoZRG5KI7W/PP3B6WHymzrJNJHtKpl5erFHKCKCxZXm3IayZ9Txvc5fqVvPA== X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2017 16:05:15.8424 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2205 Archived-At: Subject: Re: [Anima] CASM BOF X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 16:05:22 -0000 --------------C683432639E646C1F533D82A Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hello, Indeed a very important change from Centralized to Coordinated. I remember discussions at IETF94/Yokohama about possible solutions to the ASM problem and the centralized approach was really preeminent and thus putting out of scope potential solutions more distributed (à la ANIMA). Also, ASM is one of the problems that might benefit from a "coordinated" management approach. We could think about generalizing the scheme to shared resources / resource pool management (instead of only addresses / address ranges as the resource). Best regards, Laurent. On 21/03/2017 15:12, Michael Richardson wrote: > Brian E Carpenter wrote: > k> I've been tracking this a bit. Their main focus is on a YANG interface > k> between the NOC and the IPAM system. It's thanks to me that the C > k> stands for Coordinated instead of Centralized. > > Cool. > > k> I believe that our prefix management use case is part of the back end > k> for this rather than competition, but we should definitely track the > k> work. > > I agree: it complementary. I guess I think of ANIMA as being the front > end that talks to the IPAM in the back-end :-) > > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Laurent Ciavaglia Nokia, Bell Labs +33 160 402 636 route de Villejust - Nozay, France linkedin.com/in/laurent.ciavaglia --------------C683432639E646C1F533D82A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hello,

Indeed a very important change from Centralized to Coordinated.
I remember discussions at IETF94/Yokohama about possible solutions to the ASM problem and the centralized approach was really preeminent and thus putting out of scope potential solutions more distributed (à la ANIMA).

Also, ASM is one of the problems that might benefit from a "coordinated" management approach.
We could think about generalizing the scheme to shared resources / resource pool management (instead of only addresses / address ranges as the resource).

Best regards, Laurent.


On 21/03/2017 15:12, Michael Richardson wrote:
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    k> I've been tracking this a bit. Their main focus is on a YANG interface
    k> between the NOC and the IPAM system. It's thanks to me that the C
    k> stands for Coordinated instead of Centralized.

Cool.

    k> I believe that our prefix management use case is part of the back end
    k> for this rather than competition, but we should definitely track the
    k> work.

I agree: it complementary.  I guess I think of ANIMA as being the front
end that talks to the IPAM in the back-end :-)


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

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

--

Laurent Ciavaglia

Nokia, Bell Labs

 

+33 160 402 636

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia

--------------C683432639E646C1F533D82A-- From nobody Tue Mar 21 14:06:22 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAA51293E9 for ; Tue, 21 Mar 2017 14:06:21 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 V1MJiyZzIHS8 for ; Tue, 21 Mar 2017 14:06:19 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318081293DB for ; Tue, 21 Mar 2017 14:06:19 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id w124so15557861itb.1 for ; Tue, 21 Mar 2017 14:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=i74h+54xQwdDGrvWmIRKS/ULsjf0xTX24FVvkz1R840=; b=s6c4aHi6jBwWVvI2BM9eZbAPJZI8CIoB6AqhDp3D2ShUAAe+5Vj+umVEnDZDFKfyvl YJm8z7Ma/Qqbz9yie5cpAUPYZwg1QSxMGcXr9clvvVjLeq2ciR8WJJWL5l14JSeWW6Hk CPLNw8lhNc0c5M9hCu4cIPwFR3iSSFMHjDu8rd2sVHR6zV3zjjPtxzKGIMHTC690wqb3 x2K1GG+8wv7nKqovCa27iiwR3xd8pWXTQOOL8Hizz+fDz/jKd2YSR8NqmaU/ANGJ3X+m 9gNLOPfFvRqhQeRoDcEgDu3ohQD6g+6nercufrIHrnXKcW9Ry+4iTajRXeQwyRfD0nYG Rr2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=i74h+54xQwdDGrvWmIRKS/ULsjf0xTX24FVvkz1R840=; b=Ee9EvdYtgKhYVK9Li+rLUtqzRughkurN5x34d2kEh30xsiiWbiovmmGQWb8QLG+HDS avLbdQ4zCCB3ZHmuIXGfnxZd/0YSEqMLltgQFLzROyqRSG0vVJjFxxAdmlLwmB4zhsiq nUcY/AAuoHgG9xHdh08FVy/GhLgYlJObtFrIZA0aN01J1bgfY1St6BPEUdAKDIlZXG2t h1Vh1p6F2/t/5OTF772ARwVmM33BGD+XFTLwn46+/ZeX+bWckbxMaR39bxz5vDc27Og3 dVfOegG9lqA8Gp/rv6rdlI7sNTbCVQciEJFrUk5euPUPxnFCdjKpFwFz0Gbt48cyJE+g qR+Q== X-Gm-Message-State: AFeK/H0cE7P5c5e4eoEIi9m9oQUMGiiqRyn6fROR2zVSH81OfhgJT9AakKyjh+YS3Rec6Q== X-Received: by 10.36.40.9 with SMTP id h9mr4854560ith.13.1490130378274; Tue, 21 Mar 2017 14:06:18 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id s21sm7321315ite.0.2017.03.21.14.06.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 14:06:17 -0700 (PDT) To: Anima WG References: <148944194143.20385.9814981620178250957@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <01fbc1cb-9f09-10d4-ee60-91b786ba527d@gmail.com> Date: Wed, 22 Mar 2017 10:06:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148944194143.20385.9814981620178250957@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-05.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 21:06:21 -0000 Hi, > 5. Proxy Discovery Protocol Details ... > proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, > transport-proto, port-number ] ] If that's a GRASP objective, it needs to include the loop-count and flags fields. Also, I thought it was officially a "Join Assistant" now... Also, if you use M_FLOOD to announce it, you MAY associate a locator directly with the flood message, so you don't need it in the value field. > 6. Registrar Discovery Protocol Details > > The registrar responds to discovery messages from the proxy (or GRASP > caches between them) as follows: (XXX changed from M_DISCOVERY) > > objective = ["AN_registrar", F_DISC, 255 ] > discovery-message = [M_NEG_SYN, session-id, initiator, objective] That's a bit confused too. I don't know quite what it's supposed to mean. I think the basic point is that the spec should focus on the objectives and the semantics of their value fields. Get that right and the use of GRASP messages will fall out immediately. We can code up a Python model during the hackathon, with a bit of luck. I already have that for the versions of the objectives in draft-carpenter-anima-ani-objectives-01. After that, figure out some example message flows. ... > ...In each case, the traffic SHOULD be proxied to the same > port at the ULA address provided. Yes, we hope it will be a ULA address in the ACP, but that isn't a protocol issue in itself. Any address should work. Regards Brian On 14/03/2017 10:52, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Michael H. Behringer > Steinthor Bjarnason > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-05.txt > Pages : 55 > Date : 2017-03-13 > > Abstract: > This document specifies automated bootstrapping of a remote secure > key infrastructure (BRSKI) using vendor installed X.509 certificate, > in combination with a vendor's authorizing service, both online the > Internet, and offline. Bootstrapping a new device can occur using a > routable address and a cloud service, or using only link-local > connectivity, or on limited/disconnected networks. Support for lower > security models, including devices with minimal identity, is > described for legacy reasons but not encouraged. Bootstrapping is > complete when the cryptographic identity of the new key > infrastructure is successfully deployed to the device but the > established secure connection can be used to deploy a locally issued > certificate to the device as well. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Mar 22 13:38:32 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CAD1292D3; Wed, 22 Mar 2017 13:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 xvYCxmu17hBF; Wed, 22 Mar 2017 13:38:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE0E1289B0; Wed, 22 Mar 2017 13:38:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJJ48036; Wed, 22 Mar 2017 20:38:11 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 22 Mar 2017 20:38:10 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Wed, 22 Mar 2017 13:37:46 -0700 From: "Kiran.Makhijani" To: NVO3 , "teas@ietf.org" , "Anima@ietf.org" , "nfvrg@irtf.org" , "detnet@ietf.org" , "dmm@ietf.org" CC: Alex Galis , "stewart.bryant" , "Dongjie (Jimmy)" Thread-Topic: IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 Thread-Index: AQHSoz+5Xjw5TZfZoEyeQL1fJee2j6GhUdQA Date: Wed, 22 Mar 2017 20:37:46 +0000 Message-ID: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.14] Content-Type: multipart/alternative; boundary="_000_2716CB655FA7467DA2CE301888D946BChuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58D2E0B4.01C5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4886b10f17bc7b9a67c89c68471584c5 Archived-At: Subject: [Anima] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:38:17 -0000 --_000_2716CB655FA7467DA2CE301888D946BChuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0NoYW5nZWQgcmVjZXBpZW50cyBmcm9tIEJDQyB0byDigJhUb+KAmTogTlYwMywgRE1NLCBERVRO RVQsIFRFQVMsIEFOSU1BLCBORlZSRyB0byBieXBhc3MgbGlzdC1vd25lcuKAmXMgYXBwcm92YWw7 IFBsZWFzZSBkb27igJl0IHJlcGx5LWFsbF0NCg0KSGVsbG8gYWxsLA0KV2UgaW52aXRlIHlvdSB0 byBwYXJ0aWNpcGF0ZSBpbiBOZXRTbGljZXMgc2lkZSBtZWV0aW5nIGF0IElFVEYgOTguIFRoZSBk ZXRhaWxzIGFyZSBhcyBmb2xsb3dzIC0NCg0KDQotICAgICAgICAgIExvY2F0aW9uOiBSb29tIFZl dmV5IDEvMiwNCg0KLSAgICAgICAgICBEYXRlL1RpbWU6IDIwMTcuMDMuMjcsIDE4OjE1LTIxOjE1 DQoNCi0gICAgICAgICAgQWdlbmRhOiBodHRwczovL2dpdGh1Yi5jb20vbmV0c2xpY2VzL0lFVEYt TmV0U2xpY2VzL3RyZWUvbWFzdGVyL0lFVEY5OF9TaWRlbWVldGluZzAyDQpQbGVhc2Ugc2VlIGRl dGFpbGVkIChhZ2VuZGEubWQpIGFuZCBzdW1tYXJpemVkIChhZ2VuZGEudHh0KSB0ZXh0Lg0KU2Nv cGUgb2YgdGhlIG1lZXRpbmcgaXMgbWVudGlvbmVkIGluIGFnZW5kYSBhcyB3ZWxsLg0KDQpQbGVh c2UgZmVlbCBmcmVlIHRvIGZvcndhcmQgdGhpcyBpbnZpdGF0aW9uIHRvIGFueW9uZSBpbnRlcmVz dGVkLg0KDQpSZWdhcmRzDQpLaXJhbiwgRG9uZ0ppZSwgQWxleCwgU3Rld2FydA0K --_000_2716CB655FA7467DA2CE301888D946BChuaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2DF0A511FC6DEB4491962E706EC108C2@huawei.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseTpDYWxpYnJpO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTQwMzQ4MjQxOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg4NTE2MTU5OCAtNzcyNzYzMTYy IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPltDaGFuZ2VkIHJlY2VwaWVudHMgZnJvbSBCQ0MgdG8g4oCYVG/igJk8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjogTlYwMywgRE1NLCBERVRORVQsIFRFQVMsIEFOSU1B LCBORlZSRyB0byBieXBhc3MgbGlzdC1vd25lcuKAmXMgYXBwcm92YWw7IFBsZWFzZSBkb27igJl0 IHJlcGx5LWFsbF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhl bGxvIGFsbCwgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIGludml0ZSB5b3UgdG8gcGFydGljaXBhdGUg aW4gTmV0U2xpY2VzIHNpZGUgbWVldGluZyBhdCBJRVRGIDk4LiBUaGUgZGV0YWlscyBhcmUgYXMg Zm9sbG93cyAtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5Mb2NhdGlvbjogUm9vbSBWZXZleSAxLzIsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkRhdGUvVGltZTogMjAxNy4wMy4yNywgMTg6MTUtMjE6MTU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWdlbmRhOiA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5j b20vbmV0c2xpY2VzL0lFVEYtTmV0U2xpY2VzL3RyZWUvbWFzdGVyL0lFVEY5OF9TaWRlbWVldGlu ZzAyIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRzbGljZXMvSUVURi1OZXRTbGljZXMvdHJlZS9t YXN0ZXIvSUVURjk4X1NpZGVtZWV0aW5nMDI8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBzZWUgZGV0YWlsZWQgKGFn ZW5kYS5tZCkgYW5kIHN1bW1hcml6ZWQgKGFnZW5kYS50eHQpIHRleHQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4 dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNjb3BlIG9mIHRo ZSBtZWV0aW5nIGlzIG1lbnRpb25lZCBpbiBhZ2VuZGEgYXMgd2VsbC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBmZWVsIGZyZWUgdG8gZm9yd2FyZCB0 aGlzIGludml0YXRpb24gdG8gYW55b25lIGludGVyZXN0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5SZWdhcmRzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPktpcmFuLCBEb25nSmllLCBBbGV4LCBTdGV3YXJ0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2716CB655FA7467DA2CE301888D946BChuaweicom_-- From nobody Wed Mar 22 14:06:03 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7149C1293D6 for ; Wed, 22 Mar 2017 14:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 NsksO-DLxalX for ; Wed, 22 Mar 2017 14:05:47 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 0CAD9128BBB for ; Wed, 22 Mar 2017 14:05:44 -0700 (PDT) Received: (qmail 29445 invoked by uid 0); 22 Mar 2017 21:05:43 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 22 Mar 2017 21:05:43 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id z95f1u00V2SSUrH0195i1P; Wed, 22 Mar 2017 15:05:42 -0600 X-Authority-Analysis: v=2.1 cv=WOnsABcR c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=WiVod9pSvdkA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=nzR3x2kru8NTdGTmOnUA:9 a=QEXdDO2ut3YA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=HwIBhcbR+8kwmWWgZKpDqxuDD1knhpV/yIsN87am56s=; b=AiXoDE4TGRaCYhn3iOytoFICy9 Bm2IO0plQ/7ZMfy7quzDjorR328lVzDK55GTQgmgbRMOVeSD3I837AzS4r9NIcGxrO0xYsTskW9wS ar6QsL7txPwEdgeaEaZ/5w3DK; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:43154 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cqnRq-0004ka-SC; Wed, 22 Mar 2017 15:05:39 -0600 To: "Kiran.Makhijani" , NVO3 , "teas@ietf.org" , "Anima@ietf.org" , "nfvrg@irtf.org" , "detnet@ietf.org" , "dmm@ietf.org" References: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> Cc: Alex Galis , "Dongjie (Jimmy)" , "stewart.bryant" From: Lou Berger Message-ID: <49562b95-29b3-230f-9a37-aeb6d545db6e@labn.net> Date: Wed, 22 Mar 2017 17:05:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1cqnRq-0004ka-SC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:43154 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Anima] [Detnet] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 21:05:48 -0000 Given the wide distribution and formalism of this so called side meeting, I'd like to remind all of RFC6771 as well as remind the contributors that there are chartered WGs that would be open to hearing from them. Lou PS With chair hat off, I'd love to hear why this isn't a BoF? Was it simply to sidestep the two bof rule? On 3/22/2017 4:37 PM, Kiran.Makhijani wrote: > > [Changed recepients from BCC to ‘To’: NV03, DMM, DETNET, TEAS, ANIMA, > NFVRG to bypass list-owner’s approval; Please don’t reply-all] > > > > Hello all, > > We invite you to participate in NetSlices side meeting at IETF 98. The > details are as follows - > > > > - Location: Room Vevey 1/2, > > - Date/Time: 2017.03.27, 18:15-21:15 > > - Agenda: > https://github.com/netslices/IETF-NetSlices/tree/master/IETF98_Sidemeeting02 > > Please see detailed (agenda.md) and summarized (agenda.txt) text. > > Scope of the meeting is mentioned in agenda as well. > > > > Please feel free to forward this invitation to anyone interested. > > > > Regards > > Kiran, DongJie, Alex, Stewart > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Mar 22 15:41:57 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30BF128BE1 for ; Wed, 22 Mar 2017 15:41:54 -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 mTNCzBnC5dHQ for ; Wed, 22 Mar 2017 15:41:52 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8731012709D for ; Wed, 22 Mar 2017 15:41:52 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id z13so73018253iof.2 for ; Wed, 22 Mar 2017 15:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version; bh=zu+buAwbT5+Xq/aVB8NtKWpJVMZg6bOTBEMXj5jiARE=; b=ZVCam0HO6M36uqMdkmF4XpTcFlpTSdUppJDIK9HbVPuJKooiJ0Whcy6VeAJiIMSGbv 4KhjrsQpE0L52eVtPuYLq4cufRT5fqsqqRHzfaLW66u4YTg1yFmDm2XVCzeoQQa4BEGC Wc4/oyY4QJp3FAXP7Xrdci/2BQULun224qUjQOUP6MlC8GG6h8UW6XAttXJi4c43rHEp 526N0LRXrMTYI6cuTx+SNhumt1pIMtHDYygsiXVTwp0HUGTGKmL8l11QiA6LUuE5KIbY 1Iuca+X9pPcUAesE/bxamlekCtc6IYaUlG3s5djIWF2ku3OzWGWKMeTpYhGioJc1YLLc 5rYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version; bh=zu+buAwbT5+Xq/aVB8NtKWpJVMZg6bOTBEMXj5jiARE=; b=XpV04BgrVdcLZ19sDDdpdP0U/7w6+yr1dS116AEFGlamMluNnfwY/gyhJhvsuapkwh wNASPO8F1SpMyezXYusBTdwZg766vaIczwXZHzFA3Ydqlq/FUScGAZZZ3r7a9eAjsKYO 7jmmBa3wAwiKKyh2ijKHojSc4jA2Pdg2hT5sN9Tx/auF5+k2a8L8s34SuoTXsE5GIkng LB0DlGSTY3487zKQgT4XWu7fhcJkMrBDc6RVfMuBzQ+E0unv56OhaToQCXdPMslrPCpM cNXT3QArQUCPMwXyRhRbMS4sDEUy+DtP3Rag9JSQNQfr7wDmdxjzN/rrRlQexFgZUvtQ ddJg== X-Gm-Message-State: AFeK/H2i8VxBEkpjtb0pFcAPUPw8BUvPKphVLQkKslVmGIy80dyiszbt1089V9MWk70Mcw== X-Received: by 10.107.11.35 with SMTP id v35mr38925432ioi.86.1490222511676; Wed, 22 Mar 2017 15:41:51 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id x26sm1487478ioi.5.2017.03.22.15.41.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 15:41:51 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> Date: Thu, 23 Mar 2017 11:41:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------7AFD91A6F74B44A2662633D4" Archived-At: Subject: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:41:55 -0000 This is a multi-part message in MIME format. --------------7AFD91A6F74B44A2662633D4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, We will discuss the GRASP API (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago. One related topic is how to map this API into C, which is perhaps the most fundamental mapping. People with more C coding experience than me: please look at the attached header file. All kinds of comments are needed. Regards Brian Carpenter --------------7AFD91A6F74B44A2662633D4 Content-Type: text/plain; charset=UTF-8; name="graspi.h" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="graspi.h" Ly8gRHJhZnQgaGVhZGVyIGZpbGUgZm9yIEdSQVNQIEFQSSBpbiBDDQovLyBGb3IgYmFja2dy b3VuZCBzZWUgZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWFwaQ0KDQojaW5jbHVkZSA8c3RkYm9v bC5oPg0KI2luY2x1ZGUgPHN0ZGludC1nY2MuaD4NCiNpbmNsdWRlIDxzdHJpbmcuaD4gICAg ICAgIC8vIE5vdCB1c2VkIGhlcmUgYnV0IHByb2JhYmx5IG5lZWRlZC4uLg0KDQovLyBHZW5l cmljIHR5cGVzDQoNCiNpZm5kZWYgaW42X2FkZHINCnR5cGVkZWYgc3RydWN0IHsNCiAgICB1 aW50OF90IHM2X2FkZHJbMTZdOyAgIC8vIGNvdWxkIHVzZSBJUHY0LW1hcHBlZCBpbiBoZXJl IHRvbw0KICAgIH0gaW42X2FkZHI7DQojZW5kaWYNCg0KI2lmbmRlZiBib29sDQp0eXBlZGVm IGVudW0geyBmYWxzZSwgdHJ1ZSB9IGJvb2w7DQojZW5kaWYNCg0KLy8gVHlwZXMgZm9yIEdS QVNQIEFQSQ0KDQp0eXBlZGVmIHVpbnQzMl90IGFzYV9ub25jZTsNCg0KLy8gV2Ugd2FudCBh bGwgc3RyaW5ncyB0byBoYXZlIGFuIGFzc29jaWF0ZWQgbGVuZ3RoIGZpZWxkLCBhcyBhbiBh aWQNCi8vIHRvIGJ1ZmZlciBvdmVyZmxvdyBwcmV2ZW50aW9uLiBCdXQgaWYgdGhlcmUncyBh IGdvb2Qgc3RyaW5nIGxpYnJhcnkNCi8vIGF2YWlsYWJsZSwgdXNlIHRoYXQgYXQgYWxsIGNv c3RzLg0KDQp0eXBlZGVmIHN0cnVjdCB7DQogICAgaW50IHN0X3NpemU7DQogICAgdW5zaWdu ZWQgY2hhciBzdF92YWx1ZVtdOyAgICAgLy8gVVRGLTggYnl0ZXMsIG51bGwgdGVybWluYXRl ZCBhdCBzdF92YWx1ZVtzdF9zaXplXSBzbw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC8vIG1hbGxvYygpIGF0IGxlYXN0IG9uZSBzcGFyZSBieXRlDQogICAgfSBnc3Ry aW5nOw0KDQp0eXBlZGVmIHN0cnVjdCB7DQogICAgdWludDMyX3QgaWRfdmFsdWU7DQogICAg aW42X2FkZHIgc291cmNlOw0KICAgIH0gc2Vzc2lvbl9ub25jZTsNCg0KdHlwZWRlZiBzdHJ1 Y3Qgew0KICAgIGluNl9hZGRyIGFfbG9jYXRvcjsgLy8gaWYgaXNfaXBhZGRyZXNzDQogICAg Z3N0cmluZyBzX2xvY2F0b3I7ICAvLyBpZiAoaXNfZnFkbiB8fCBpc191cmkpDQogICAgaW50 IHByb3RvY29sOw0KICAgIGludCBwb3J0Ow0KICAgIGludCBpZmk7DQogICAgdWludDMyX3Qg ZXhwaXJlOw0KICAgIGJvb2wgZGl2ZXJ0ZWQsIGlzX2lwYWRkcmVzcywgaXNfZnFkbiwgaXNf dXJpOw0KICAgIH0gYXNhX2xvY2F0b3I7DQoNCnR5cGVkZWYgc3RydWN0IHsNCiAgICBnc3Ry aW5nIG5hbWU7DQogICAgdWludDhfdCBmbGFnczsgICAgICAgICAgICAvLyBlbmNvZGUgYXMg aW4gR1JBU1Agc3BlYw0KICAgIGludCBsb29wX2NvdW50Ow0KICAgIGludCB2YWx1ZV9zaXpl OyAgICAgICAgICAgLy8gc2l6ZSBvZiB2YWx1ZQ0KICAgIHVpbnQ4X3QgKmNib3JfdmFsdWVb XTsgICAgLy8gQ0JPUiBieXRlc3RyaW5nIG9mIHZhbHVlOw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLy8gdXNlciBtdXN0IGRvIG1hbGxvYygpIGFuZCBmcmVlKCkNCiAgICB9 IG9iamVjdGl2ZTsNCg0KdHlwZWRlZiBzdHJ1Y3Qgew0KICAgIG9iamVjdGl2ZSBvYmo7DQog ICAgYXNhX2xvY2F0b3Igc291cmNlOw0KICAgIH0gdGFnZ2VkX29iamVjdGl2ZTsNCg0KLy8g R1JBU1AgQVBJIGZ1bmN0aW9uIGRlY2xhcmF0aW9ucyBmb2xsb3cNCi8vIFRoZXkgcmV0dXJu IDAgZm9yIHN1Y2Nlc3MgYW5kIGFuIGVycm9yIGNvZGUgPjAgZm9yIGZhaWx1cmUuDQoNCi8v IE5vbi1ibG9ja2luZyB2YXJpYW50cyBjb3VsZCByZXR1cm4gbm9SZXBseSAoMikgaWYgbm8g cmVwbHkgeWV0DQoNCmludCAgcmVnaXN0ZXJfYXNhKGFzYV9uYW1lLCBub25jZSkNCiAgICAg Z3N0cmluZyBhc2FfbmFtZTsNCiAgICAgYXNhX25vbmNlICpub25jZTsNCiAgICAge30NCg0K aW50ICBkZXJlZ2lzdGVyX2FzYShhc2FfbmFtZSwgbm9uY2UpDQogICAgIGdzdHJpbmcgYXNh X25hbWU7DQogICAgIGFzYV9ub25jZSBub25jZTsNCiAgICAge30NCg0KaW50ICByZWdpc3Rl cl9vYmoobm9uY2UsIG9iaiwgdHRsLCBkaXNjb3ZlcmFibGUsIG92ZXJsYXAsIGxvY2FsKQ0K ICAgICBhc2Ffbm9uY2Ugbm9uY2U7DQogICAgIG9iamVjdGl2ZSBvYmo7DQogICAgIHVpbnQz Ml90IHR0bDsNCiAgICAgYm9vbCBkaXNjb3ZlcmFibGUsIG92ZXJsYXAsIGxvY2FsOyAgLy8g U2hvdWxkIGJlIGZhbHNlIGJ5IGRlZmF1bHQNCiAgICAge30NCg0KaW50ICBkZXJlZ2lzdGVy X29iaihub25jZSwgb2JqKQ0KICAgICBhc2Ffbm9uY2Ugbm9uY2U7DQogICAgIG9iamVjdGl2 ZSBvYmo7DQogICAgIHt9DQoNCmludCAgZGlzY292ZXIobm9uY2UsIG9iaiwgdGltZW91dCwg Zmx1c2gsIHJlbGF5X2lmaSwgY291bnQsIGxvY2F0b3JzKQ0KICAgICBhc2Ffbm9uY2Ugbm9u Y2U7DQogICAgIG9iamVjdGl2ZSBvYmo7DQogICAgIHVpbnQzMl90IHRpbWVvdXQ7DQogICAg IGJvb2wgZmx1c2gsIHJlbGF5X2lmaTsgICAgICAgLy8gU2hvdWxkIGJlIGZhbHNlIGJ5IGRl ZmF1bHQNCiAgICAgaW50ICpjb3VudDsgICAgICAgICAgICAgICAgICAvLyBjb3VudCBvZiBk aXNjb3ZlcmVkIGxvY2F0b3JzICh6ZXJvIGlmIG5vbmUpIA0KICAgICBhc2FfbG9jYXRvciAq bG9jYXRvcnNbXTsgICAgIC8vIGFycmF5IG9mIGFzYV9sb2NhdG9yDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLy8gVGhlIHVzZXIgbXVzdCBmcmVlKGxvY2F0b3JzKSBh c2FwLg0KICAgICB7fQ0KDQppbnQgIHJlcV9uZWdvdGlhdGUoYW5vbmNlLCBvYmosIHBlZXIs IHRpbWVvdXQsIHNub25jZSwgcm9iaiwgcmVhc29uKQ0KICAgICBhc2Ffbm9uY2UgYW5vbmNl Ow0KICAgICBvYmplY3RpdmUgb2JqOyAgICAgICAgICAgICAgIC8vIHByb2ZmZXJlZCBvYmpl Y3RpdmUNCiAgICAgYXNhX2xvY2F0b3IgcGVlcjsNCiAgICAgdWludDMyX3QgdGltZW91dDsN CiAgICAgc2Vzc2lvbl9ub25jZSAqc25vbmNlOyAgICAgICAvLyBtYXkgYmUgMCwwDQogICAg IG9iamVjdGl2ZSAqcm9iajsgICAgICAgICAgICAgLy8gY291bnRlci1vZmZlcmVkIG9iamVj dGl2ZQ0KICAgICBnc3RyaW5nICpyZWFzb247ICAgICAgICAgICAgIC8vIHJlYXNvbiBzdHJp bmcgZm9yIGZhaWxlZCBuZWdvdGlhdGlvbg0KICAgICB7fQ0KDQppbnQgIG5lZ290aWF0ZV9z dGVwKGFub25jZSwgc25vbmNlLCBvYmosIHRpbWVvdXQsIHJvYmosIHJlYXNvbikNCiAgICAg YXNhX25vbmNlIGFub25jZTsNCiAgICAgc2Vzc2lvbl9ub25jZSBzbm9uY2U7DQogICAgIG9i amVjdGl2ZSBvYmo7ICAgICAgICAgICAgICAgLy8gcHJvZmZlcmVkIG9iamVjdGl2ZQ0KICAg ICB1aW50MzJfdCB0aW1lb3V0Ow0KICAgICBvYmplY3RpdmUgKnJvYmo7ICAgICAgICAgICAg IC8vIGNvdW50ZXItb2ZmZXJlZCBvYmplY3RpdmUNCiAgICAgZ3N0cmluZyAqcmVhc29uOyAg ICAgICAgICAgICAvLyByZWFzb24gc3RyaW5nIGZvciBmYWlsZWQgbmVnb3RpYXRpb24NCiAg ICAge30NCg0KaW50ICBuZWdvdGlhdGVfd2FpdChhbm9uY2UsIHNub25jZSwgdGltZW91dCkN CiAgICAgYXNhX25vbmNlIGFub25jZTsNCiAgICAgc2Vzc2lvbl9ub25jZSBzbm9uY2U7DQog ICAgIHVpbnQzMl90IHRpbWVvdXQ7DQogICAgIHt9DQoNCmludCAgZW5kX25lZ290aWF0ZShh bm9uY2UsIHNub25jZSwgcmVzdWx0LCByZWFzb24pDQogICAgIGFzYV9ub25jZSBhbm9uY2U7 DQogICAgIHNlc3Npb25fbm9uY2Ugc25vbmNlOw0KICAgICBib29sIHJlc3VsdDsNCiAgICAg Z3N0cmluZyByZWFzb247ICAgICAgICAgICAgLy8gTWF5IGJlICcnDQogICAgIHt9DQoNCmlu dCAgbGlzdGVuX25lZ290aWF0ZShhbm9uY2UsIG9iaiwgc25vbmNlLCByb2JqKQ0KICAgICBh c2Ffbm9uY2UgYW5vbmNlOw0KICAgICBvYmplY3RpdmUgb2JqOyAgICAgICAgICAgICAgIC8v IG5hbWVkIG9iamVjdGl2ZQ0KICAgICBzZXNzaW9uX25vbmNlICpzbm9uY2U7DQogICAgIG9i amVjdGl2ZSAqcm9iajsgICAgICAgICAgICAgLy8gcmVxdWVzdGVkIG9iamVjdGl2ZQ0KICAg ICB7fQ0KDQppbnQgIHN0b3BfbmVnb3RpYXRlKGFub25jZSwgb2JqKQ0KICAgICBhc2Ffbm9u Y2UgYW5vbmNlOw0KICAgICBvYmplY3RpdmUgb2JqOyAgICAgICAgICAgICAgIC8vIG5hbWVk IG9iamVjdGl2ZQ0KICAgICB7fQ0KDQppbnQgIHN5bmNocm9uaXplKGFub25jZSwgb2JqLCBw ZWVyLCB0aW1lb3V0LCByb2JqKQ0KICAgICBhc2Ffbm9uY2UgYW5vbmNlOw0KICAgICBvYmpl Y3RpdmUgb2JqOyAgICAgICAgICAgICAgIC8vIG5hbWVkIG9iamVjdGl2ZQ0KICAgICBhc2Ff bG9jYXRvciBwZWVyOw0KICAgICB1aW50MzJfdCB0aW1lb3V0Ow0KICAgICBvYmplY3RpdmUg KnJvYmo7ICAgICAgICAgICAgIC8vIHN5bmNocm9uaXplZCBvYmplY3RpdmUNCiAgICAge30N Cg0KaW50ICBsaXN0ZW5fc3luY2hyb25pemUoYW5vbmNlLCBvYmopDQogICAgIGFzYV9ub25j ZSBhbm9uY2U7DQogICAgIG9iamVjdGl2ZSBvYmo7ICAgICAgICAgICAgICAgLy8gb2JqZWN0 aXZlIHRvIGJlIHNlbnQNCiAgICAge30NCg0KaW50ICBzdG9wX3N5bmNocm9uaXplKGFub25j ZSwgb2JqKQ0KICAgICBhc2Ffbm9uY2UgYW5vbmNlOw0KICAgICBvYmplY3RpdmUgb2JqOyAg ICAgICAgICAgICAgIC8vIG5hbWVkIG9iamVjdGl2ZQ0KICAgICB7fQ0KDQppbnQgIGZsb29k KGFub25jZSwgdHRsLCBjb3VudCwgdGFnZ2VkX29ianMpDQogICAgIGFzYV9ub25jZSBhbm9u Y2U7DQogICAgIHVpbnQzMl90IHR0bDsNCiAgICAgaW50IGNvdW50OyAgICAgICAgICAgICAg ICAgICAgICAgLy8gY291bnQgb2YgdGFnZ2VkIG9iamVjdGl2ZXMNCiAgICAgdGFnZ2VkX29i amVjdGl2ZSAqdGFnZ2VkX29ianNbXTsgLy8gYXJyYXkgb2YgdGFnZ2VkIG9iamVjdGl2ZXMN CiAgICAge30NCg0KaW50ICBnZXRfZmxvb2QoYW5vbmNlLCBjb3VudCwgdGFnZ2VkX29ianMp DQogICAgIGFzYV9ub25jZSBhbm9uY2U7DQogICAgIGludCAqY291bnQ7ICAgICAgICAgICAg ICAgIC8vIGNvdW50IG9mIHRhZ2dlZCBvYmplY3RpdmVzICh6ZXJvIGlmIG5vIHJlc3VsdCkg IA0KICAgICB0YWdnZWRfb2JqZWN0aXZlICp0YWdnZWRfb2Jqc1tdOyAgLy8gYXJyYXkgb2Yg dGFnZ2VkX29iamVjdGl2ZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLy8g VGhlIHVzZXIgbXVzdCBmcmVlKHRhZ2dlZF9vYmpzKSBhc2FwLg0KICAgICB7fQ0KDQppbnQg IGV4cGlyZV9mbG9vZChhbm9uY2UsIHRhZ2dlZF9vYmopDQogICAgIGFzYV9ub25jZSBhbm9u Y2U7DQogICAgIHRhZ2dlZF9vYmplY3RpdmUgdGFnZ2VkX29iajsNCiAgICAge30NCg0K --------------7AFD91A6F74B44A2662633D4-- From nobody Thu Mar 23 08:43:48 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A34B1275AB for ; Thu, 23 Mar 2017 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uyEIt9QlNVqx for ; Thu, 23 Mar 2017 08:43:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29839127275 for ; Thu, 23 Mar 2017 08:43:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 512BF203B9; Thu, 23 Mar 2017 12:07:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 14110636E0; Thu, 23 Mar 2017 11:43:43 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> References: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 15:43:46 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Hi, > We will discuss the GRASP API > (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago. > One related topic is how to map this API into C, which is perhaps the > most fundamental mapping. As someone who writes lots of C, I am not convinced this is a useful exercise. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljT7S4ACgkQgItw+93Q 3WUuVAf8DOZnuU5b7Smo6TXoqKBa+0PD5AsvMCGszOkfsXyGQecFxKT9Hq3Zi2uS cqukMQSjV+Nlpxo7ddz8vWUDEitpjj+QSOAMntfnC0EKDFY81PoST8CoGEhdhNRw Mm80jyUsWpslppflvhSQAGRvQ1iDC/ghBgt7xcnYnXeHQ4WBEDAYUVX44Bu3fv+s 5IexG/XbgtTDzz4rxoFiNGR8exozhQL51hZo9aQLwJmFngCZaPJfCFe4Km34XGmv DnudYFJ9Z3LuJ7Oibg/NtGQM/RQufAfwIXZqUpvf9CTGYFDMwezuslO7AFA2eK5R 9BxwubiOLlWggBUx4dt0xUjhQwSXfA== =vlCz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 23 11:12:24 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9969129B15 for ; Thu, 23 Mar 2017 11:12: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 gF9ZLzfz3Zdc for ; Thu, 23 Mar 2017 11:12:16 -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 69CB4129B31 for ; Thu, 23 Mar 2017 11:12:15 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id w124so45070064itb.1 for ; Thu, 23 Mar 2017 11:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=loG413FlLyLyHxisppgbejE1jayBZDidvPhbFSQEIcE=; b=WVfVwZLMF+CRSUXtoMupyf2fVhe0E2vpamQilXEH4KHQodyKyGzbfIy4iSQqPAN585 iZ6WBhqq+Meigac8bUvwaO4iwqSxwiZBMWIjFjwOTYicUUZ1okfuFQlUnmCkGi8aSaFE ZKRX6NLIMMnmHFz6Y0rej82n2cqf7xbecNDrIClGCbqkYCAi7wcg+/pyesMgH8zpbMsX t3TDRZJYRWOigrkF0ue25ou6OG1QhHTTJ/yBQJfF5y5fe3MfxS3uKvYQBz+MdYbt51fq SbG2+jXREaO0ireyn9WMC6V8rGOW6/efLsFP6EYC+sK9BH3TIfJSpQW8oO9HLGXEa1sm 6qiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=loG413FlLyLyHxisppgbejE1jayBZDidvPhbFSQEIcE=; b=lg/WH1OEgD3N1ZhytpqsMWpwEQaSmtwzNAVQsVC0wiylgckBsTBhUKxhjMP/BCwkaW NQPpLM6jyf/PPgyTTOhQvvKymuy4Oo6BICWjA4ahjPPA4qxWK+C0sXtH+uQ2Rp9w+TIU +3nIztDSq7E3L1HNqZrwJu2u4QoDrUiWfvSuHm5sLnBDHCIvjQQ3jcXBiiZ2qKbLxxvC DF8XIaanQfmHmTKjoYnxjpt+CIgQ0+PEAmpWBoFRb7Xxpql0t8yI1hmlHXTxMW5r0JQL 7JSRo3KQSKpQK2mnLs1JpoDNzWuc5ZCR8SqALXfsJed4ok91s2ln0vyYRgLVZ5QveNp3 /Edw== X-Gm-Message-State: AFeK/H3EbZgrXKTWlmVU1OH+pdu8qm4x3dOjVN2Zp0MkmAijDAY55/nRx3/6BdtnAsDhxw== X-Received: by 10.36.26.4 with SMTP id 4mr2910598iti.58.1490292734640; Thu, 23 Mar 2017 11:12:14 -0700 (PDT) Received: from [10.103.46.124] ([8.28.179.23]) by smtp.gmail.com with ESMTPSA id y124sm2049996itd.19.2017.03.23.11.12.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 11:12:14 -0700 (PDT) To: Michael Richardson References: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> <9809.1490283823@obiwan.sandelman.ca> Cc: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <76345f98-758c-49a1-f1cd-9bb50c3c757e@gmail.com> Date: Fri, 24 Mar 2017 07:12:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9809.1490283823@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:12:18 -0000 On 24/03/2017 04:43, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Hi, > > > We will discuss the GRASP API > > (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago. > > > One related topic is how to map this API into C, which is perhaps the > > most fundamental mapping. > > As someone who writes lots of C, I am not convinced this is a useful exercise. Can you explain? If you're arguing that no ASAs will be written in C, that's defensible, but maybe that isn't your argument? Brian From nobody Thu Mar 23 12:05:44 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0395129BF0 for ; Thu, 23 Mar 2017 12:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 1gaKZxDH9cll for ; Thu, 23 Mar 2017 12:05:39 -0700 (PDT) Received: from nm2-vm1.bullet.mail.ne1.yahoo.com (nm2-vm1.bullet.mail.ne1.yahoo.com [98.138.91.33]) (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 DE2D81294EC for ; Thu, 23 Mar 2017 12:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1490295938; bh=iwzxkeln6wKSi6BmjQ1ZGNNKZoSO68ZM2RgPcWCLrGA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=V77TAEXRYB0ANl4Zqq/c+djs7gOqAHPoo2bgv03SuA2XYon5FoGa8KwPsMJ4YVPwHz0R0kcoTJfeNX+QJ5dAivetqZ+MadOxHKgl/GSCbs4eorvrpU3qylap5a26ZhknIu1hgLGT1bLtZ9/TlBkft8cYecBENdrSOCrjcJYOHIcLSbphthgxtzve912+DGLpLpHGoUXMW9Awm5uf/+iGRBXdjps3gZKegd66zr7smBdT5YaBiA3eEJzoKgmQ3pytq/NI0/TmuyZWpVunfWEjqcCDz6vanHZTjvbTEPTcuOkyc0RiM5y2WogCEiO65Bc8g5Mtt0K06vqmCDIYmYTgzw== Received: from [98.138.100.113] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 23 Mar 2017 19:05:38 -0000 Received: from [98.138.89.254] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 23 Mar 2017 19:05:38 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 23 Mar 2017 19:05:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 993958.87764.bm@omp1046.mail.ne1.yahoo.com X-YMail-OSG: rNJ39_cVM1mNTcy1YUKvl4GAfJEQfexe7XEVm0hf4NYfnfRVzB1XGeIIjGDGdhn YaGeAl7GbSkUhLcbzfqChjDibXm7qNWnSRaqS81hIRAcnbiTQWmOpJW8VVIWbBkfY96cNjupaWJ2 18jqA0vMOZauF1r43BjW.WmG1ZQEHaU8LUIAZTcCO7lvj3BTPGiPPeiYBEPq25mePUC5r1zWu_c7 2g92pidp2xlSCuNMRwSaocpiDeHEPi6qK.xqFJbXqq.gm1RnWV5.dZhw5eNRKuypmuG8vIjtiByw 6_C9k.1qtuDq2XR9yQXXAgUBn.Jv9MtugyxWaU358_KH8rvrinhPdRNqQL4hGsl4XFO9B89rJiHo xbsM7oU5TnBzRkGqnlZ0x3ZVxgphtWYQgOvMW4xu0nH.69KD25LbU0OJQiVpv_1n8cgUu5pI4cf_ ocHgzQQTwC8T_62LvaT.nuH8A3jqVZNzhooj2vxbCx1GjcEqzxoi7Ma1.Q8mMwpsttmY7NWcruDw XyzfYN47FdvA- Received: from jws200060.mail.ne1.yahoo.com by sendmailws140.mail.ne1.yahoo.com; Thu, 23 Mar 2017 19:05:37 +0000; 1490295937.607 Date: Thu, 23 Mar 2017 19:05:37 +0000 (UTC) From: Reply-To: To: "Kiran.Makhijani" , NVO3 , "teas@ietf.org" , "Anima@ietf.org" , "nfvrg@irtf.org" , "detnet@ietf.org" , "dmm@ietf.org" Cc: Alex Galis , "Dongjie (Jimmy)" , "stewart.bryant" , Chao Kan Message-ID: <936460141.2410376.1490295937351@mail.yahoo.com> In-Reply-To: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> References: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2410375_880826400.1490295937351" Archived-At: Subject: Re: [Anima] [nvo3] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 19:05:42 -0000 ------=_Part_2410375_880826400.1490295937351 Content-Type: multipart/alternative; boundary="----=_Part_2410374_1283835280.1490295937348" ------=_Part_2410374_1283835280.1490295937348 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kiran, DongJie, Alex, Stewart, Is the NetSlices a BoF? =C2=A0It's not on the official agenda. =C2=A0A few = of us would like to attend remotely. =C2=A0Will there be an audio/Jabber pr= ovided to allow remote participation? =C2=A0Thanks.=C2=A0Ning So972-955-091= 4 From: Kiran.Makhijani To: NVO3 ; "teas@ietf.org" ; "Anima@ietf.org= " ; "nfvrg@irtf.org" ; "detnet@ietf.org" ; "dmm@ietf.org" =20 Cc: Alex Galis ; Dongjie (Jimmy) ; stewart.bryant Sent: Wednesday, March 22, 2017 3:38 PM Subject: [nvo3] IETF98 NetSlices side meeting agenda and schedule (27/03 M= on @ 18:15) Location: Vevey 1/2 =20 [Changed recepients from BCC to =E2= =80=98To=E2=80=99: NV03, DMM, DETNET, TEAS, ANIMA, NFVRG to bypass list-own= er=E2=80=99s approval; Please don=E2=80=99t reply-all] =C2=A0 Hello all, W= e invite you to participate in NetSlices side meeting at IETF 98. The detai= ls are as follows - =C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Location: Room Vevey 1/2, -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Date/Time: 2017.03.27, 18:15-21:15 -=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Agenda: https://github.com/netslices/IETF-Net= Slices/tree/master/IETF98_Sidemeeting02 Please see detailed (agenda.md) and= summarized (agenda.txt) text. Scope of the meeting is mentioned in agenda = as well. =C2=A0 Please feel free to forward this invitation to anyone inter= ested. =C2=A0 Regards Kiran, DongJie, Alex, Stewart _______________________= ________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 =20 ------=_Part_2410374_1283835280.1490295937348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= Kiran, DongJie, Alex, Stewar= t,

Is the NetSlices a BoF?  It's not on th= e official agenda.  A few of us would like to attend remotely.  W= ill there be an audio/Jabber provided to allow remote participation?  = Thanks.
 
Ning So
972-955-0914


= From: Kiran.Makhijani <= Kiran.Makhijani@huawei.com>
To= : NVO3 <nvo3@ietf.org>; "teas@ietf.org" <teas@ietf.org&= gt;; "Anima@ietf.org" <Anima@ietf.org>; "nfvrg@irtf.org" <nfvrg@ir= tf.org>; "detnet@ietf.org" <detnet@ietf.org>; "dmm@ietf.org" <d= mm@ietf.org>
Cc: Al= ex Galis <galis.alex@gmail.com>; Dongjie (Jimmy) <jie.dong@huawei.= com>; stewart.bryant <stewart.bryant@gmail.com>
Sent: Wednesday, March 22, 2017 3:38 PM<= br> Subject: [nvo3] IETF98= NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: V= evey 1/2

=20 =20 =20 =20
[Changed recepients from BCC to =E2=80=98To=E2=80=99: NV03, DMM, DETNET, TEAS, ANIMA, NFVRG to bypas= s list-owner=E2=80=99s approval; Please don=E2=80=99t reply-all]=20
 
=20
Hel= lo all,
=20
We invite you to participate in NetSlices side meeting at IET= F 98. The details are as follows -
=20
&nb= sp;
=20
-<= span style=3D"font:7.0pt;">        =   Location: Room Vevey 1/2,
=20
-&n= bsp;         Date/Time: 2017.03.27, 18:1= 5-21:15
=20
-<= span style=3D"font:7.0pt;">        =   Agenda: https://github.com/netslices/IETF-NetSlices/tree/master/IETF98_Sidemeeting0= 2
=20
Please see detailed (agenda.md) a= nd summarized (agenda.txt) text.
=20
Scope of the meeting is mentioned= in agenda as well.
=20
 
=20
Ple= ase feel free to forward this invitation to anyone interested.
= =20
 
= =20
Regards
= =20
Kiran, DongJie, Alex, Stewart
=20
_______________________________________________
nvo3 mailing list<= br>nvo3@i= etf.org
https://www.ietf.org/mailman/listinfo/nvo3


------=_Part_2410374_1283835280.1490295937348-- ------=_Part_2410375_880826400.1490295937351 Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Untitled" Content-ID: <646d6506-1d71-4aa1-8d98-f785bfd77526@yahoo.com> X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbnZvMyBtYWls aW5nIGxpc3QKbnZvM0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMK ------=_Part_2410375_880826400.1490295937351-- From nobody Thu Mar 23 23:40:34 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EC11293DF; Thu, 23 Mar 2017 23:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 olQeGHKo451G; Thu, 23 Mar 2017 23:40:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 AD22C13172E; Thu, 23 Mar 2017 23:40:22 -0700 (PDT) Received: from mb.local ([IPv6:2607:fb90:2702:d75:d551:9213:f4e9:3ce5]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v2O6e5n1096995 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 24 Mar 2017 06:40:06 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2607:fb90:2702:d75:d551:9213:f4e9:3ce5] claimed to be mb.local To: ningso@yahoo.com, "Kiran.Makhijani" , NVO3 , "teas@ietf.org" , "Anima@ietf.org" , "nfvrg@irtf.org" , "detnet@ietf.org" , "dmm@ietf.org" References: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> <936460141.2410376.1490295937351@mail.yahoo.com> Cc: Alex Galis , "stewart.bryant" , Chao Kan , "Dongjie (Jimmy)" From: joel jaeggli Message-ID: Date: Thu, 23 Mar 2017 23:40:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <936460141.2410376.1490295937351@mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i2AJRFR9Qig1odx2g2POvKWFuJOxL0a2o" Archived-At: Subject: Re: [Anima] [nvo3] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 06:40:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i2AJRFR9Qig1odx2g2POvKWFuJOxL0a2o Content-Type: multipart/mixed; boundary="3eE068vh87TbE33D7Q8Lef9iwTadBNNeC"; protected-headers="v1" From: joel jaeggli To: ningso@yahoo.com, "Kiran.Makhijani" , NVO3 , "teas@ietf.org" , "Anima@ietf.org" , "nfvrg@irtf.org" , "detnet@ietf.org" , "dmm@ietf.org" Cc: Alex Galis , "stewart.bryant" , Chao Kan , "Dongjie (Jimmy)" Message-ID: Subject: Re: [nvo3] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 References: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> <936460141.2410376.1490295937351@mail.yahoo.com> In-Reply-To: <936460141.2410376.1490295937351@mail.yahoo.com> --3eE068vh87TbE33D7Q8Lef9iwTadBNNeC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/23/17 12:05 PM, ningso@yahoo.com wrote: > Kiran, DongJie, Alex, Stewart, >=20 > Is the NetSlices a BoF? It's not on the official agenda. A few of us > would like to attend remotely. Will there be an audio/Jabber provided > to allow remote participation? Thanks. It is not. it's also outside the hours of streaming coverage. joel > Ning So > 972-955-0914 >=20 >=20 > -----------------------------------------------------------------------= - > *From:* Kiran.Makhijani > *To:* NVO3 ; "teas@ietf.org" ; > "Anima@ietf.org" ; "nfvrg@irtf.org" ; > "detnet@ietf.org" ; "dmm@ietf.org" > *Cc:* Alex Galis ; Dongjie (Jimmy) > ; stewart.bryant > *Sent:* Wednesday, March 22, 2017 3:38 PM > *Subject:* [nvo3] IETF98 NetSlices side meeting agenda and schedule > (27/03 Mon @ 18:15) Location: Vevey 1/2 >=20 > [Changed recepients from BCC to =91To=92: NV03, DMM, DETNET, TEAS, ANIM= A, > NFVRG to bypass list-owner=92s approval; Please don=92t reply-all] > =20 > Hello all, > We invite you to participate in NetSlices side meeting at IETF 98. The > details are as follows - > =20 > - Location: Room Vevey 1/2, > - Date/Time: 2017.03.27, 18:15-21:15 > - Agenda: > https://github.com/netslices/IETF-NetSlices/tree/master/IETF98_Sidemeet= ing02 > Please see detailed (agenda.md) and summarized (agenda.txt) text. > Scope of the meeting is mentioned in agenda as well. > =20 > Please feel free to forward this invitation to anyone interested. > =20 > Regards > Kiran, DongJie, Alex, Stewart > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >=20 --3eE068vh87TbE33D7Q8Lef9iwTadBNNeC-- --i2AJRFR9Qig1odx2g2POvKWFuJOxL0a2o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAljUv0QACgkQ8AA1q7Z/VrK1pwCdH5mgZ5L//WwcMjOxV1V/I5xn khEAn3AYNLPKtZbUbltx4ITEnuEqlyyH =pfoI -----END PGP SIGNATURE----- --i2AJRFR9Qig1odx2g2POvKWFuJOxL0a2o-- From nobody Fri Mar 24 11:46:49 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48430129536 for ; Fri, 24 Mar 2017 11:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Dy9S27MC6SxU for ; Fri, 24 Mar 2017 11:46:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3071294BE for ; Fri, 24 Mar 2017 11:46:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DC8E42009E; Fri, 24 Mar 2017 15:10:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C20FA636E0; Fri, 24 Mar 2017 14:46:44 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <76345f98-758c-49a1-f1cd-9bb50c3c757e@gmail.com> References: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> <9809.1490283823@obiwan.sandelman.ca> <76345f98-758c-49a1-f1cd-9bb50c3c757e@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 18:46:48 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Brian E Carpenter wrote: > Hi, >> >> > We will discuss the GRASP API > >> (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago. >> >> > One related topic is how to map this API into C, which is perhaps >> the > most fundamental mapping. >> >> As someone who writes lots of C, I am not convinced this is a useful >> exercise. > Can you explain? If you're arguing that no ASAs will be written in C, > that's defensible, but maybe that isn't your argument? I think that ASAs that are written in C will be written in that language for reasons of extreme constraints. As such, they won't bother with a library/API. It will all be statically initialized globals and other stuff. (Go read the Contiki code for an example of what I mean...) Everyone else will write their ASAs in a higher level language: python, ruby, perl, java, scala, *go*, maybe rust. The really hard thing about the C api is that doesn't deal well with indefinites like intents... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljVaZQACgkQgItw+93Q 3WVKrQgAjQnK+u/YYP1l5GePCp2FlAtierMDu4lOTZYhdLCbYrnPG4gY03T1soQq Docv5f3TaJVjDP89cZKrIxprVsfL7GKusZyzWo//yLFYulenQa9vLxjqf25n3Yl3 N558yrUeN1cpsTl8DCgS0b3KRBFVi/GxIAZZDq5aPPK984dtkcBYJFkVyngyjkmd +6emociiNMM/Fq7D+UclnpfkS1tEb/GAyhnqtqjxAHFAU1j+c7n6DW34e6qNBT88 y05uXu++mUu4vfMZ1NMomY+LqGsKXueWKUrx5udbYwpNKVVeJD1p0iItLcm+46rp ZIpMhvM4Jcg+iNh7QH0vo0lUfV6rCA== =5ub7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 24 13:02:28 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627CF12708C for ; Fri, 24 Mar 2017 13:02:26 -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 Z3yEkEQmc6_Q for ; Fri, 24 Mar 2017 13:02:24 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 00FD6126BF0 for ; Fri, 24 Mar 2017 13:02:23 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id y18so20121518itc.0 for ; Fri, 24 Mar 2017 13:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BHYs+f5QHlCyruJSuVa9FSsbXAuNIcbeQjo4MGRFR1U=; b=Y+NTI7RHgBQCj3YRxXxuXjejAoXvgIo8FYzxEBYw6vijsRh5efZEyLFznYUZx2Sy4R 5QLsV8lILAOx/a5FKzJiOTKbM+q+HQMr9jEAziutR04gxdJmhssDcPeD4srLWaV8wH54 JL6raAwr+72Hjjnbagw3YK4J95a1eaR6j/5ppDfZVCo1tSpmZ8CF5zRdptnGVhBkPw3B Mx/hscLEWHYxS0mprGqPbHQu13Rlv0xtwq6nTt9SbjTl/eLWHXaHO3bWK/eoPVVD+mxb 1tvmBHsjpddHyMt9JxFtkcPtJY/cX96U7fVAsxDtdmZnImMkp9gXasKbkgduXc8iMKHb vNBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BHYs+f5QHlCyruJSuVa9FSsbXAuNIcbeQjo4MGRFR1U=; b=q2zxr9RFuCbOgAkb2jYknqpzdtBMmoH5zQS3Q92jTrenNg0m6GAs4oQLV9CCIzuRsW T9lsdlb3DQLflL8SkiKC+nG67gjAIksHrwhLMn2epiG4vhPY1lddw0n8rp5qwbHtC5oE 1kErm+jZfteqT6ROyuknrG4/pAGOKyY6+bAD/aJaT6OacwIZSPuE+4y/Pa9PJE4iBRQw RhSssj2HRwIpb+utTQ+sI8ps7GT5ve6Ueqmsm18Bm7dozJ4zV7rbCHkyFfhklEyLyOB5 oWAEt3+SBD197X3lGoXWKSgIIRvndFig+3DD2vIg0dWBUxGHzrit9U3+YUcQASZpEtfI vSyg== X-Gm-Message-State: AFeK/H2MLBcjjAAkaP8LmWyTqREs6AWrDx7ztMdiLPYJJOJMja/DlMeo2E64Gr96v6YIIw== X-Received: by 10.107.46.198 with SMTP id u67mr11007707iou.8.1490385743057; Fri, 24 Mar 2017 13:02:23 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id 62sm2939247itl.1.2017.03.24.13.02.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2017 13:02:22 -0700 (PDT) To: Michael Richardson References: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> <9809.1490283823@obiwan.sandelman.ca> <76345f98-758c-49a1-f1cd-9bb50c3c757e@gmail.com> <18940.1490381204@obiwan.sandelman.ca> Cc: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <298db127-0970-68ee-dda6-0a9c0c625041@gmail.com> Date: Sat, 25 Mar 2017 09:02:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <18940.1490381204@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 20:02:26 -0000 On 25/03/2017 07:46, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> Brian E Carpenter wrote: > Hi, > >> > >> > We will discuss the GRASP API > > >> (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago. > >> > >> > One related topic is how to map this API into C, which is perhaps > >> the > most fundamental mapping. > >> > >> As someone who writes lots of C, I am not convinced this is a useful > >> exercise. > > > Can you explain? If you're arguing that no ASAs will be written in C, > > that's defensible, but maybe that isn't your argument? > > I think that ASAs that are written in C will be written in that language for > reasons of extreme constraints. As such, they won't bother with a > library/API. It will all be statically initialized globals and other stuff. > (Go read the Contiki code for an example of what I mean...) > > Everyone else will write their ASAs in a higher level language: python, ruby, > perl, java, scala, *go*, maybe rust. The really hard thing about the C api > is that doesn't deal well with indefinites like intents... It doesn't deal well with flexible types either, a dangerous luxury in Python that I've got very fond of. But it seems to me that if a GRASP core implementation is written in C for efficiency, it will *need* to offer an API in C that higher level languages can build on. And if we are happy with a core written in a high level language, we'll need to call it from other languages. That can be complicated too. BTW, my not-production-quality Python version of the GRASP core is now about 1800 lines of code, but if we take out the stuff for diagnostics and debugging there's maybe 1000 lines. I hope we'll find out in the hackathon how big the BUPT code is; so far they don't support an API, so they are on your model. Brian From nobody Fri Mar 24 15:46:46 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13001274D2 for ; Fri, 24 Mar 2017 15:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 e6jnrAt-NJMl for ; Fri, 24 Mar 2017 15:46:42 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254D5120326 for ; Fri, 24 Mar 2017 15:46:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C9D8AE00B; Fri, 24 Mar 2017 19:10:19 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 05F29636E0; Fri, 24 Mar 2017 18:46:41 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <298db127-0970-68ee-dda6-0a9c0c625041@gmail.com> References: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> <9809.1490283823@obiwan.sandelman.ca> <76345f98-758c-49a1-f1cd-9bb50c3c757e@gmail.com> <18940.1490381204@obiwan.sandelman.ca> <298db127-0970-68ee-dda6-0a9c0c625041@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 22:46:45 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > It doesn't deal well with flexible types either, a dangerous luxury in > Python that I've got very fond of. But it seems to me that if a GRASP > core implementation is written in C for efficiency, it will *need* to > offer an API in C that higher level languages can build on. No, because it will be monolithic: not part of a library, no sockets API, etc. > BTW, my not-production-quality Python version of the GRASP core is now > about 1800 lines of code, but if we take out the stuff for diagnostics > and debugging there's maybe 1000 lines. I hope we'll find out in the > hackathon how big the BUPT code is; so far they don't support an API, > so they are on your model. My understanding is that uPython is getting significant traction in some constrained environments: someone may want to rewrite your code to this very limited subset (less than python 2, I'm told). I think that this is more likely to be a "library" than any C code. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljVodAACgkQgItw+93Q 3WVM3wf/UE6yZ+PS09mPlS++mX0tSEqunLVfMkiknvuNoWESMF02rKS9n2KWv2/I JVOk622hPggjJ092qvrjGfKPe6+eGYB6MfRQexvdQk2qxogiK3JTG4GFwzFFTqbq sFTbp+TYwREBMmtMGSqg3u7ztSMpXeKHjHdsDkXsWg9fJbBrpO0+k41qJYSaS2rQ sU/bGyO1k8z+rAZWQP0O3M55EeKE4riT3RMp5bGL/tmiQLUsBjWNcJkZLq5d1mbg eMdhcbiaydtCCLKjtzPT1cOiYYpyrO4Lv8EbUWkWRz54jnaM1QFx3APaj8H50xxN 2dfS9gtDpBkVscXQoDOiIx0P9PvEhQ== =QHNN -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 25 06:26:06 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65E512944F for ; Sat, 25 Mar 2017 06:26:04 -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 sZGRHPPi9utM for ; Sat, 25 Mar 2017 06:26:03 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 33EC9129447 for ; Sat, 25 Mar 2017 06:26:03 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id y18so14399872itc.1 for ; Sat, 25 Mar 2017 06:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5yiCuOI2vbaAHqY5EwAVDGhAuo7jfKokNXj3nn9X4Eg=; b=J5VfUAHR6c3QlnYs/rtroW3LW5+GH0CO17oa3es64c/jKODXjPdCipglSR+Vaze1uo 9MN266SKAnMUCTng1oL2QbeHoMvGSsNjlFkoiSwvX4NKmxoEbTlBRjnkaMlUCpjZemam y0icvzIrjMqBI7obfWrT+rN7j1z8+w3FSoukQshA8SJ3NotutVanF0UuqvqYhlZgmxx5 kibtDAm7Re5kx0KztJaIYJVMYNIjxpv511ftEkmDpCukcfWaYNb3+61RiK0ffY/hY/nq 7Vw1+QOhzoSYKFCgEQRY+jcfHwYGxAYAOicLz2M/Gvyz5XeL2fJHFHcIQP4/aUTrUmMI MRFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=5yiCuOI2vbaAHqY5EwAVDGhAuo7jfKokNXj3nn9X4Eg=; b=q0xVL5lxYPHMT6fSbLp+v+uT/igmAI8KAKcf38zfPFPfDxv1o7iy5+sH7YYBbpGpNu Xp4kSYQ9FmgR6GnDjXbmvHGAak2escJSE1JhhoPvuYglz7PGMEN86VHy6YiQ6s9oKSel 5i1kF5rvD6zmLCWZN4bRB5LD5buaKH5Rn79KpLzT9jiXH+tVdtZSV5Z6R1qCmZmsy7cS hNyswRYlELKLBichG+pONJ3hAMl+RZQKQonyb1jK+wrhsxudfVVM78T8oW31FQLVu/5j SYLAUlSRxvPws4JnA8RVOWQPw5ZxQjz4YoC4ofAGhzq1X5yoJxUAd815EtynCHdkcURY xj9Q== X-Gm-Message-State: AFeK/H2EeGRTWJHpOrnsm3U92eXI8ktUiAxgU/+PtRDlO4Zclkz9GSrCQzm4Q6zOE0CMKw== X-Received: by 10.36.215.129 with SMTP id y123mr1913206itg.17.1490448362468; Sat, 25 Mar 2017 06:26:02 -0700 (PDT) Received: from [172.16.11.95] (50-76-68-137-static.hfc.comcastbusiness.net. [50.76.68.137]) by smtp.gmail.com with ESMTPSA id m77sm2460634ita.16.2017.03.25.06.26.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Mar 2017 06:26:01 -0700 (PDT) To: Michael Richardson References: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> <9809.1490283823@obiwan.sandelman.ca> <76345f98-758c-49a1-f1cd-9bb50c3c757e@gmail.com> <18940.1490381204@obiwan.sandelman.ca> <298db127-0970-68ee-dda6-0a9c0c625041@gmail.com> <8914.1490395600@obiwan.sandelman.ca> Cc: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 26 Mar 2017 02:25:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8914.1490395600@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 13:26:05 -0000 On 25/03/2017 11:46, Michael Richardson wrote: > > Brian E Carpenter wrote: > > It doesn't deal well with flexible types either, a dangerous luxury in > > Python that I've got very fond of. But it seems to me that if a GRASP > > core implementation is written in C for efficiency, it will *need* to > > offer an API in C that higher level languages can build on. > > No, because it will be monolithic: not part of a library, no sockets API, etc. It can't be monolithic in a general-purpose device with a variety of ASAs sharing a discovery cache, flood cache, etc. Well, I'll show you my code later today if you like. (I will get to the hackathon at a time that depends on service on the Red Line train...). > > BTW, my not-production-quality Python version of the GRASP core is now > > about 1800 lines of code, but if we take out the stuff for diagnostics > > and debugging there's maybe 1000 lines. I hope we'll find out in the > > hackathon how big the BUPT code is; so far they don't support an API, > > so they are on your model. > > My understanding is that uPython is getting significant traction in some > constrained environments: someone may want to rewrite your code to this > very limited subset (less than python 2, I'm told). I think that this is > more likely to be a "library" than any C code. I know nothing about uPython. I did look at downgrading my code to Python 2 but quickly gave up because, well, Python 3 is better. So it all depends on what they've kept and what they've removed in uPython. Brian From nobody Sat Mar 25 09:22:01 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2A128BBB for ; Sat, 25 Mar 2017 09:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ahP8TtDAyOA5 for ; Sat, 25 Mar 2017 09:21:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F37126C26 for ; Sat, 25 Mar 2017 09:21:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 181E1203B2; Sat, 25 Mar 2017 12:45:35 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CFE0F636E0; Sat, 25 Mar 2017 12:21:53 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: References: <83c2beba-2ad5-eb1d-b188-fe2d9e688391@gmail.com> <9809.1490283823@obiwan.sandelman.ca> <76345f98-758c-49a1-f1cd-9bb50c3c757e@gmail.com> <18940.1490381204@obiwan.sandelman.ca> <298db127-0970-68ee-dda6-0a9c0c625041@gmail.com> <8914.1490395600@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] GRASP API in C? X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 16:21:57 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Brian E Carpenter wrote: > It doesn't >> deal well with flexible types either, a dangerous luxury in > Python >> that I've got very fond of. But it seems to me that if a GRASP > core >> implementation is written in C for efficiency, it will *need* to > >> offer an API in C that higher level languages can build on. >> >> No, because it will be monolithic: not part of a library, no sockets >> API, etc. > It can't be monolithic in a general-purpose device with a variety of > ASAs sharing a discovery cache, flood cache, etc. Well, I'll show you Exactly: it can't be monolithic on a general-purpose device. When it's not a general-purpose device, that's when writing it in C will be required. >> My understanding is that uPython is getting significant traction in >> some constrained environments: someone may want to rewrite your code >> to this very limited subset (less than python 2, I'm told). I think >> that this is more likely to be a "library" than any C code. > I know nothing about uPython. I did look at downgrading my code to > Python 2 but quickly gave up because, well, Python 3 is better. So it > all depends on what they've kept and what they've removed in uPython. I don't know much about it either. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljWmSEACgkQgItw+93Q 3WWquQf/d5BkTEvW+IuKbo0ksozcTG+5geSrVhAf0kmyQO8CCRSZ45uXXkFqI2Oh xJt7azpv8IV9+FJVbOllIa3AqNn1vSLhJdi7Q7vkhmwWfl0XBAAkR4OTDFhjSbfg ao8P4ZWym+UPmjzyjPl6HBg3hpBUzD6XTICVUlfuXHrdKOD/zPoHC+Zu7q3+1SFV jutrVVykzGZBmj/1Eefy91sV5PdKB7p/LHglPEccAvRy5X/WRfyEM1j47DNGnHzj 9R/XK7FsMxXa/KvK0+W81bhbS3EeVbEKWbBBvFXWO4lbdOyRQrVecSXGkEGjNqIZ nbbjToxbeldziQqh5dystjwobTKhzw== =ptFz -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 26 17:53:04 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351CC128E19; Sun, 26 Mar 2017 17:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RIJ64B0E2z4j; Sun, 26 Mar 2017 17:52:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FA8128D2E; Sun, 26 Mar 2017 17:52:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDN54092; Mon, 27 Mar 2017 00:52:47 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Mar 2017 01:52:46 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Sun, 26 Mar 2017 17:52:32 -0700 From: "Kiran.Makhijani" To: joel jaeggli , "ningso@yahoo.com" , NVO3 , "teas@ietf.org" , "Anima@ietf.org" , "nfvrg@irtf.org" , "detnet@ietf.org" , "dmm@ietf.org" CC: Alex Galis , "stewart.bryant" , Chao Kan , "Dongjie (Jimmy)" Thread-Topic: [nvo3] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 Thread-Index: AQHSoz+5Xjw5TZfZoEyeQL1fJee2j6GhUdQAgAHt7oCAAMIHAIAD4IcA Date: Mon, 27 Mar 2017 00:52:32 +0000 Message-ID: <69C6C1C4-F3A8-405C-9330-88AF3E592E9B@huawei.com> References: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> <936460141.2410376.1490295937351@mail.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.96] Content-Type: multipart/mixed; boundary="_002_69C6C1C4F3A8405C933088AF3E592E9Bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.58D86260.00E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 07d13e0a6990687940d4384a3d572a8e Archived-At: Subject: Re: [Anima] [nvo3] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 00:52:55 -0000 --_002_69C6C1C4F3A8405C933088AF3E592E9Bhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-ID: <2B5F2DCD7502EF4F850EB02122B17945@huawei.com> Content-Transfer-Encoding: base64 SGVsbG8sDQpXZSBoYXZlIGJlZW4gYWJsZSB0byBnZXQgd2ViZXggbGluayBmb3IgdGhlIHNpZGUg bWVldGluZy4gUGxlYXNlIHNlZSBhdHRhY2htZW50IGZvciBkZXRhaWxzLg0KDQpUaGFua3MgDQpL aXJhbg0KDQpPbiAzLzI0LzE3LCAxOjQwIEFNLCAiam9lbCBqYWVnZ2xpIiA8am9lbGphQGJvZ3Vz LmNvbT4gd3JvdGU6DQoNCiAgICBPbiAzLzIzLzE3IDEyOjA1IFBNLCBuaW5nc29AeWFob28uY29t IHdyb3RlOg0KICAgID4gS2lyYW4sIERvbmdKaWUsIEFsZXgsIFN0ZXdhcnQsDQogICAgPiANCiAg ICA+IElzIHRoZSBOZXRTbGljZXMgYSBCb0Y/ICBJdCdzIG5vdCBvbiB0aGUgb2ZmaWNpYWwgYWdl bmRhLiAgQSBmZXcgb2YgdXMNCiAgICA+IHdvdWxkIGxpa2UgdG8gYXR0ZW5kIHJlbW90ZWx5LiAg V2lsbCB0aGVyZSBiZSBhbiBhdWRpby9KYWJiZXIgcHJvdmlkZWQNCiAgICA+IHRvIGFsbG93IHJl bW90ZSBwYXJ0aWNpcGF0aW9uPyAgVGhhbmtzLg0KICAgIA0KICAgIEl0IGlzIG5vdC4gaXQncyBh bHNvIG91dHNpZGUgdGhlIGhvdXJzIG9mIHN0cmVhbWluZyBjb3ZlcmFnZS4NCiAgICANCiAgICBq b2VsDQogICAgDQogICAgPiBOaW5nIFNvDQogICAgPiA5NzItOTU1LTA5MTQNCiAgICA+IA0KICAg ID4gDQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+ICpGcm9tOiogS2lyYW4uTWFraGlqYW5p IDxLaXJhbi5NYWtoaWphbmlAaHVhd2VpLmNvbT4NCiAgICA+ICpUbzoqIE5WTzMgPG52bzNAaWV0 Zi5vcmc+OyAidGVhc0BpZXRmLm9yZyIgPHRlYXNAaWV0Zi5vcmc+Ow0KICAgID4gIkFuaW1hQGll dGYub3JnIiA8QW5pbWFAaWV0Zi5vcmc+OyAibmZ2cmdAaXJ0Zi5vcmciIDxuZnZyZ0BpcnRmLm9y Zz47DQogICAgPiAiZGV0bmV0QGlldGYub3JnIiA8ZGV0bmV0QGlldGYub3JnPjsgImRtbUBpZXRm Lm9yZyIgPGRtbUBpZXRmLm9yZz4NCiAgICA+ICpDYzoqIEFsZXggR2FsaXMgPGdhbGlzLmFsZXhA Z21haWwuY29tPjsgRG9uZ2ppZSAoSmltbXkpDQogICAgPiA8amllLmRvbmdAaHVhd2VpLmNvbT47 IHN0ZXdhcnQuYnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+DQogICAgPiAqU2VudDoq IFdlZG5lc2RheSwgTWFyY2ggMjIsIDIwMTcgMzozOCBQTQ0KICAgID4gKlN1YmplY3Q6KiBbbnZv M10gSUVURjk4IE5ldFNsaWNlcyBzaWRlIG1lZXRpbmcgYWdlbmRhIGFuZCBzY2hlZHVsZQ0KICAg ID4gKDI3LzAzIE1vbiBAIDE4OjE1KSBMb2NhdGlvbjogVmV2ZXkgMS8yDQogICAgPiANCiAgICA+ IFtDaGFuZ2VkIHJlY2VwaWVudHMgZnJvbSBCQ0MgdG8g4oCYVG/igJk6IE5WMDMsIERNTSwgREVU TkVULCBURUFTLCBBTklNQSwNCiAgICA+IE5GVlJHIHRvIGJ5cGFzcyBsaXN0LW93bmVy4oCZcyBh cHByb3ZhbDsgUGxlYXNlIGRvbuKAmXQgcmVwbHktYWxsXQ0KICAgID4gIA0KICAgID4gSGVsbG8g YWxsLA0KICAgID4gV2UgaW52aXRlIHlvdSB0byBwYXJ0aWNpcGF0ZSBpbiBOZXRTbGljZXMgc2lk ZSBtZWV0aW5nIGF0IElFVEYgOTguIFRoZQ0KICAgID4gZGV0YWlscyBhcmUgYXMgZm9sbG93cyAt DQogICAgPiAgDQogICAgPiAtICAgICAgICAgIExvY2F0aW9uOiBSb29tIFZldmV5IDEvMiwNCiAg ICA+IC0gICAgICAgICAgRGF0ZS9UaW1lOiAyMDE3LjAzLjI3LCAxODoxNS0yMToxNQ0KICAgID4g LSAgICAgICAgICBBZ2VuZGE6DQogICAgPiBodHRwczovL2dpdGh1Yi5jb20vbmV0c2xpY2VzL0lF VEYtTmV0U2xpY2VzL3RyZWUvbWFzdGVyL0lFVEY5OF9TaWRlbWVldGluZzAyDQogICAgPiBQbGVh c2Ugc2VlIGRldGFpbGVkIChhZ2VuZGEubWQpIGFuZCBzdW1tYXJpemVkIChhZ2VuZGEudHh0KSB0 ZXh0Lg0KICAgID4gU2NvcGUgb2YgdGhlIG1lZXRpbmcgaXMgbWVudGlvbmVkIGluIGFnZW5kYSBh cyB3ZWxsLg0KICAgID4gIA0KICAgID4gUGxlYXNlIGZlZWwgZnJlZSB0byBmb3J3YXJkIHRoaXMg aW52aXRhdGlvbiB0byBhbnlvbmUgaW50ZXJlc3RlZC4NCiAgICA+ICANCiAgICA+IFJlZ2FyZHMN CiAgICA+IEtpcmFuLCBEb25nSmllLCBBbGV4LCBTdGV3YXJ0DQogICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gbnZvMyBtYWlsaW5nIGxp c3QNCiAgICA+IG52bzNAaWV0Zi5vcmcgPG1haWx0bzpudm8zQGlldGYub3JnPg0KICAgID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQogICAgPiANCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgPiBudm8zIG1haWxpbmcgbGlzdA0KICAgID4gbnZvM0BpZXRmLm9y Zw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQogICAg PiANCiAgICANCiAgICANCiAgICANCg0K --_002_69C6C1C4F3A8405C933088AF3E592E9Bhuaweicom_ Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3658; creation-date="Mon, 27 Mar 2017 00:52:32 GMT"; modification-date="Mon, 27 Mar 2017 00:52:32 GMT" Content-ID: <951BC8326344C3438A3214DF5FEE19FE@huawei.com> Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpDZW50cmFsIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE1MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA1MDAKVFpPRkZTRVRUTzotMDYwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE1MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDYw MApUWk9GRlNFVFRPOi0wNTAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86a2lyYW4ubWFraGlqYW5pQGh1YXdlaS5jb20KT1JH QU5JWkVSO0NOPSJQQUxTIFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpwYWxzLWNoYWlyc0BpZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkNlbnRyYWwgVGltZSI6MjAxNzAzMjdUMTgwNTAwCkRURU5EO1RaSUQ9 IkNlbnRyYWwgVGltZSI6MjAxNzAzMjdUMjEzNTAwCkxPQ0FUSU9OOmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0ZgpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE0OTA1NzI4NDUKVUlEOjJjOGY2ZWUz LWQ0ZTAtNDhhMi1hZGMzLTEzNmEyZTBlMmRjNApEVFNUQU1QOjIwMTcwMzI3VDIzMDUwMFoKREVT Q1JJUFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW0zODZhZTQ1ZDY5ODhjNWViYmVjMGY2ODRkMjE1MDYyZlxuTWVl dGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ0IDk5MiAyNDdcbk1lZXRpbmcgcGFzc3dvcmQ6 IG5ldHNsaWNlXG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRv bGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwg bnVtYmVyIChVUy9DYW5hZGEpXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogXG5o dHRwczovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5c bkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczovL2hlbHAud2ViZXguY29tL2RvY3MvRE9D LTU0MTJcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXgg c2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRo ZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEg bGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkg Y29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWlu ZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90 IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQg U0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjxGT05U IFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW0zODZhZTQ1ZDY5ODhjNWViYmVjMGY2ODRkMjE1MDYyZiI+PEZPTlQg U0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRpbmc8 L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogNjQ0IDk5MiAyNDc8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwvdGFibGU+CQkJCQkJ PHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5uZXRzbGljZTwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4J CTwvRk9OVD48YnI+PEZPTlQgc2l6ZT0iMiIgQ09MT1I9IiNGRjAwMDAiPjwvRk9OVD48YnI+PEZP TlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPjxGT05U IFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04NzctNjY4LTQ0OTM8L3N0cm9u Zz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7 IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+ MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5h ZGEpPC9GT05UPiZuYnNwOyA8QlI+PGEgaHJlZj0iaHR0cHM6Ly93d3cud2ViZXguY29tL3BkZi90 b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIg RkFDRT0iYXJpYWwiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZu YnNwOyA8QlI+PC9GT05UPjxCUj48QlI+CSZuYnNwOzxCUj4JPGEgaHJlZj0iaHR0cHM6Ly9oZWxw LndlYmV4LmNvbS9kb2NzL0RPQy01NDEyIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjki IEZBQ0U9IkFyaWFsIj5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD48L2E+CSZuYnNwOzxC Uj4mbmJzcDs8QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5J TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwg ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNl c3Npb24uPC9GT05UPjwvRk9OVD4KU1VNTUFSWTpOZXR3b3JrIFNsaWNpbmcgU2lkZSBNZWV0aW5n ClBSSU9SSVRZOjUKQ0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElP TjpESVNQTEFZCkRFU0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6 VkNBTEVOREFSCg== --_002_69C6C1C4F3A8405C933088AF3E592E9Bhuaweicom_-- From nobody Mon Mar 27 09:03:15 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEFA1297C3; Mon, 27 Mar 2017 09:03:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149063059017.30557.11315916703004624549@ietfa.amsl.com> Date: Mon, 27 Mar 2017 09:03:10 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:03:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : An Autonomic Control Plane Authors : Michael H. Behringer Toerless Eckert Steinthor Bjarnason Filename : draft-ietf-anima-autonomic-control-plane-06.txt Pages : 38 Date : 2017-03-27 Abstract: Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out of band channel" for OAM communications over a network that is not configured, or mis-configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-06 https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 11:47:34 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598B7129481; Mon, 27 Mar 2017 11:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 av84iNIwtRX7; Mon, 27 Mar 2017 11:47:29 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 C57501292FC; Mon, 27 Mar 2017 11:47:29 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id 102so26922354otv.0; Mon, 27 Mar 2017 11:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=51JNk3NacVrKjH0LCkc+CyTLtUEkbZ4ODCHOfAcQZ58=; b=qM/fnP/T68owDud3DPWTZSmkCJnS9buQ7a0GbiaYHErknI+gkvPK5sEeMPZEwibqoD AnOPyCFMz3VKtKwYbC0jZ6lECcthpupYTB7q4EWbR2fTfHS6HBLHqSE8KMciO66aqccW SA384/YS5uaMgCjkxhWEPV61qFrzci6aHGn1NK670t3BvDxC+/TvRqogjKFxPAgcpLBr 7IUG9A4mFXE31rvmbR/IC8gvZ5TjkxdF95wNQRnaQdIr+0DLQRYgS9GCpbYmiGb91zux Pv/abY79jBgX7l0zZrGSm+lAsQ2GOC/WJLBUMSzBUFa06hAFAdh1DeEsq5a21KpKCdto tiew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=51JNk3NacVrKjH0LCkc+CyTLtUEkbZ4ODCHOfAcQZ58=; b=IoEwf+O0BCRrZ2YRpx0lJyHeTO6ZovIgN6nkWpfJsveXO03DGl9mV8/B+/dsmF/Zoy g/Efp6/KQofW4yLLMad34rW2mBkmudp6QKcbgEgBbMOXV87McPWQNTSoZhd/b/EUpE+K LAZqtLFhiYZpGwJh1Q62xu4dTLDQ4Jfu53WG3C0P5hw8LkyQrn7EH7Pq1oUxIjcPv5oZ BN+/J+f/0RhzaKVOjeyhIT00SezdunrNtxIxeJvCOdnEDeZv9nEjCeqdadNHzS+LIRO+ P2W7BPy1URak5Dyl6xYt5IK0xyr967cn/2lR17kTEZN2Rcg3lq15mdOtCB3AYGAWF8rS RoIA== X-Gm-Message-State: AFeK/H1+TRoRvJp1NXDexuvw1329BL7kIffyiAg389r360jMfQSDj+Ab/u3iPljOQ6xVNm/tGRlok4ckorCK7w== X-Received: by 10.157.53.34 with SMTP id o31mr7072646otc.76.1490640449226; Mon, 27 Mar 2017 11:47:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Mon, 27 Mar 2017 11:47:28 -0700 (PDT) In-Reply-To: <69C6C1C4-F3A8-405C-9330-88AF3E592E9B@huawei.com> References: <2716CB65-5FA7-467D-A2CE-301888D946BC@huawei.com> <936460141.2410376.1490295937351@mail.yahoo.com> <69C6C1C4-F3A8-405C-9330-88AF3E592E9B@huawei.com> From: Greg Mirsky Date: Mon, 27 Mar 2017 13:47:28 -0500 Message-ID: To: "Kiran.Makhijani" Cc: joel jaeggli , "ningso@yahoo.com" , NVO3 , "teas@ietf.org" , "Anima@ietf.org" , "nfvrg@irtf.org" , "detnet@ietf.org" , "dmm@ietf.org" , Alex Galis , "Dongjie (Jimmy)" , Chao Kan , "stewart.bryant" Content-Type: multipart/alternative; boundary=001a113e09ce76db56054bbac644 Archived-At: Subject: Re: [Anima] [nvo3] IETF98 NetSlices side meeting agenda and schedule (27/03 Mon @ 18:15) Location: Vevey 1/2 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 18:47:32 -0000 --001a113e09ce76db56054bbac644 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kiran, would you kindly record the discussion through WebEx and share the recording? Regards, Greg On Sun, Mar 26, 2017 at 7:52 PM, Kiran.Makhijani wrote: > Hello, > We have been able to get webex link for the side meeting. Please see > attachment for details. > > Thanks > Kiran > > On 3/24/17, 1:40 AM, "joel jaeggli" wrote: > > On 3/23/17 12:05 PM, ningso@yahoo.com wrote: > > Kiran, DongJie, Alex, Stewart, > > > > Is the NetSlices a BoF? It's not on the official agenda. A few of > us > > would like to attend remotely. Will there be an audio/Jabber > provided > > to allow remote participation? Thanks. > > It is not. it's also outside the hours of streaming coverage. > > joel > > > Ning So > > 972-955-0914 > > > > > > ------------------------------------------------------------ > ------------ > > *From:* Kiran.Makhijani > > *To:* NVO3 ; "teas@ietf.org" ; > > "Anima@ietf.org" ; "nfvrg@irtf.org" >; > > "detnet@ietf.org" ; "dmm@ietf.org" > > *Cc:* Alex Galis ; Dongjie (Jimmy) > > ; stewart.bryant > > *Sent:* Wednesday, March 22, 2017 3:38 PM > > *Subject:* [nvo3] IETF98 NetSlices side meeting agenda and schedule > > (27/03 Mon @ 18:15) Location: Vevey 1/2 > > > > [Changed recepients from BCC to =E2=80=98To=E2=80=99: NV03, DMM, DE= TNET, TEAS, ANIMA, > > NFVRG to bypass list-owner=E2=80=99s approval; Please don=E2=80=99t= reply-all] > > > > Hello all, > > We invite you to participate in NetSlices side meeting at IETF 98. > The > > details are as follows - > > > > - Location: Room Vevey 1/2, > > - Date/Time: 2017.03.27, 18:15-21:15 > > - Agenda: > > https://github.com/netslices/IETF-NetSlices/tree/master/ > IETF98_Sidemeeting02 > > Please see detailed (agenda.md) and summarized (agenda.txt) text. > > Scope of the meeting is mentioned in agenda as well. > > > > Please feel free to forward this invitation to anyone interested. > > > > Regards > > Kiran, DongJie, Alex, Stewart > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --001a113e09ce76db56054bbac644 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kiran,
would you kindly record the discussion throu= gh WebEx =C2=A0and share the recording?

Regards,
Greg

On Sun, Mar 26, 2017 at 7:52 PM, Kiran.Makhijani = <Kiran.M= akhijani@huawei.com> wrote:
Hello,
We have been able to get webex link for the side meeting. Please see attach= ment for details.

Thanks
Kiran

On 3/24/17, 1:40 AM, "joel jaeggli" <joelja@bogus.com> wrote:

=C2=A0 =C2=A0 On 3/23/17 12:05 PM, ning= so@yahoo.com wrote:
=C2=A0 =C2=A0 > Kiran, DongJie, Alex, Stewart,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Is the NetSlices a BoF?=C2=A0 It's not on the offici= al agenda.=C2=A0 A few of us
=C2=A0 =C2=A0 > would like to attend remotely.=C2=A0 Will there be an au= dio/Jabber provided
=C2=A0 =C2=A0 > to allow remote participation?=C2=A0 Thanks.

=C2=A0 =C2=A0 It is not. it's also outside the hours of streaming cover= age.

=C2=A0 =C2=A0 joel

=C2=A0 =C2=A0 > Ning So
=C2=A0 =C2=A0 > 972-955-0914
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > ---------------------------------------------------= ---------------------
=C2=A0 =C2=A0 > *From:* Kiran.Makhijani <Kiran.Makhijani@huawei.com>
=C2=A0 =C2=A0 > *To:* NVO3 <nvo3@iet= f.org>; "teas@ietf.org&quo= t; <teas@ietf.org>;
=C2=A0 =C2=A0 > "Anima@ietf.org" <Anima@ietf.org>; &quo= t;nfvrg@irtf.org" <nfvrg@irtf.org>;
=C2=A0 =C2=A0 > "detnet@ietf.org= " <detnet@ietf.org>; = "dmm@ietf.org" <dmm@ietf.org>
=C2=A0 =C2=A0 > *Cc:* Alex Galis <galis.alex@gmail.com>; Dongjie (Jimmy)
=C2=A0 =C2=A0 > <jie.dong@huaw= ei.com>; stewart.bryant <stewart.bryant@gmail.com>
=C2=A0 =C2=A0 > *Sent:* Wednesday, March 22, 2017 3:38 PM
=C2=A0 =C2=A0 > *Subject:* [nvo3] IETF98 NetSlices side meeting agenda a= nd schedule
=C2=A0 =C2=A0 > (27/03 Mon @ 18:15) Location: Vevey 1/2
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > [Changed recepients from BCC to =E2=80=98To=E2=80=99: NV= 03, DMM, DETNET, TEAS, ANIMA,
=C2=A0 =C2=A0 > NFVRG to bypass list-owner=E2=80=99s approval; Please do= n=E2=80=99t reply-all]
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hello all,
=C2=A0 =C2=A0 > We invite you to participate in NetSlices side meeting a= t IETF 98. The
=C2=A0 =C2=A0 > details are as follows -
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Location: Room Vevey= 1/2,
=C2=A0 =C2=A0 > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date/Time: 2017.03.2= 7, 18:15-21:15
=C2=A0 =C2=A0 > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Agenda:
=C2=A0 =C2=A0 > https= ://github.com/netslices/IETF-NetSlices/tree/master/IETF98_Sidemee= ting02
=C2=A0 =C2=A0 > Please see detailed (agenda.md) and summarized (agenda.txt) t= ext.
=C2=A0 =C2=A0 > Scope of the meeting is mentioned in agenda as well.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please feel free to forward this invitation to anyone in= terested.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards
=C2=A0 =C2=A0 > Kiran, DongJie, Alex, Stewart
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > nvo3 mailing list
=C2=A0 =C2=A0 > nvo3@ietf.org <m= ailto:nvo3@ietf.org>
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listi= nfo/nvo3
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > nvo3 mailing list
=C2=A0 =C2=A0 > nvo3@ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listi= nfo/nvo3
=C2=A0 =C2=A0 >





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


--001a113e09ce76db56054bbac644-- From nobody Mon Mar 27 12:32:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814EF129570 for ; Mon, 27 Mar 2017 12:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dZmIbsoIR5Bh for ; Mon, 27 Mar 2017 12:32:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C54C129440 for ; Mon, 27 Mar 2017 12:32:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 960D5200A3 for ; Mon, 27 Mar 2017 15:55:47 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 04E50636E0 for ; Mon, 27 Mar 2017 15:31:59 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] key management for MACsec X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:32:02 -0000 --=-=-= Content-Type: text/plain Reading 802.1AE-2006, I did not see any key management protocol for MACsec. I was thinking before that maybe we could write a MACsec key agreement mechanism in IKEv2. I am now informed of 802.1Xbx-2014: Amendment 1: MAC Security Key Agreement Protocol (MKA) Extensions but, I see that it's really an amendment to 802.1X, which I am fetching now. My thought was that if there *wasn't* a key agreement protocol for MACsec, that one could use IKEv2, and could propose a) MACsec, b) IPv6-over-IPsec, c) GRE-over-IPsec, and let the normal IKEv2 process select which is supported. But, if MACsec already has a key agreement protocol, that would be superfluous. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljZaKsACgkQgItw+93Q 3WWTFwgApoEJabR/egDKSy4qg+WCHpxbDTX63sYjMwvCQaRKBzcO6K/0oyHOVpXZ hetphb4cBBtWeFeb7R1SYCVsY8FqgelPBCoe8UgmMZ3HkgYI3qUphESkiMoLZw7y gi9jexCdL36thKs/pF79zIgC8i/wbjwnvxy3+vlg3YKc8UtXwW+Eg64/lGmYFLsB BIKRRlxm0WFUqKtTNsucOMEKwfk73t9I+jpt2Z6zcqwegaVJOr6T0P/NA7Dz+Dfu iqiaNOt32FcPR5f2xMOQrIkc27doNfEWjAHaoOLUasASdlGFAl7odJk0GJu/RxTB /yg3N7wcZVcjkwNjbmWMQeinm9AywA== =Azy5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 27 14:10:45 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C7B12967B for ; Mon, 27 Mar 2017 14:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ROsF6CFJg_mt for ; Mon, 27 Mar 2017 14:10:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E56129677 for ; Mon, 27 Mar 2017 14:10:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CA71A200A3 for ; Mon, 27 Mar 2017 17:34:29 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0B5EE636E0 for ; Mon, 27 Mar 2017 17:10:41 -0400 (EDT) From: Michael Richardson To: anima X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] autonomic framework X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:10:43 -0000 --=-=-= Content-Type: text/plain Michael, some comments driven by the slides: We changed the name from Join Assistant to Join Proxy, as a consistent name across netconf,anima and 6tisch. (Peter wants us to change it to Join Router, because it forwards packets... but...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljZf84ACgkQgItw+93Q 3WV/qwf/dBUDnrW42yoa8il9sZVjAwWdPLMxovSgU0GZfE46VrVGxqA790/lvBiD tA3iub9HH156Ao6c3v4ZZIVzaxe1fqGRBBUU92p6/C5c9XRy2caMk3EAFY+Ch652 R2YdGx0c9WG3i4ljuWiHFIlhUlteSDpqGCSBrkJ6cpcvApBxyTmdPR3X8BcyuSaB h91+SR3CElDb0Jv8YxPXOfYG8+5x35Y78Xsgrfu1DaGW9QVlkIG0DVxOATRMZuAr A1JGwRv82+1zTN4ssFDxjhaQkp6rXXH7Ax+D4eCTIBscjaUd+LamdZbJHDq0kOJG dy1SEH7I7jRqG8YQklrf7i25twmTgQ== =HpdY -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 27 14:43:53 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF71127B57 for ; Mon, 27 Mar 2017 14:43:52 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 EJ_11-m4Sj0t for ; Mon, 27 Mar 2017 14:43:50 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 33BC5126DEE for ; Mon, 27 Mar 2017 14:43:50 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id 76so14365078itj.0 for ; Mon, 27 Mar 2017 14:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tbUXPTQivd+yFefTyzQxp/LcfMiZSjRSixeWva3t29I=; b=INZ27mNOixuYJVOXURKKRvG5iWkmoqO90f2sKtEu8Izrg6NDP8EUZzWRVGeM7a3Cad qW0Ud/SFOhCjx0luro7jtCuItuoHp9GhVDBbvGAz498jdHOps/dEQn6qn9EoVdVWGE/4 9UbTiQdX6QCqUaDLgaha0C96OPGFBSo1zcRjI/3jX2mObMNchNMt5X4cXrluSvfw11sk tuX4jsHZznZgpYeAR8s7L6Dtr7k4oTzwST4Lr5SBKZxro+nby+K/ZhjnJYL3shrKE6ab r8S5rTwolCqxU7E92TRzd6fzL7qCm8Mk/FKngz2EOfrxkknuZNKDkwUmzskxzWYPBBsc dM4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=tbUXPTQivd+yFefTyzQxp/LcfMiZSjRSixeWva3t29I=; b=IvUOQNXeIgCXIjxFZT2VAiJBV/xImjay6ojeNKmJKo0oR6rOvzysYEMR2ORrduusnt NYlE5D54qiPirAwCbivLCXlww8EbqfCRDKZJnyhyZXS5rBixAF2sp37r8BD7N0venkZH uUfJBjuOiLZF0vLHmRpBad4GTYBfmlnsc9wm+8xlvpTYzCiFqA5uS1LBtg9YqhEa3rEV kEyUew3r3S6wNW0Hg40NYHEZ54DBCKt9NxwFfXM6qWbSKOVthWYM7kxtS8aBB2RyHNYF tDUXDmLcsprO/C+WAthXZKWxvXGRvrZ0qZb5FNitH7aLB/J8qukKFk3+S0hGGiYSvcNb UvAA== X-Gm-Message-State: AFeK/H2Oe5SwNR/5lMWd763/TDwfUvirH+x3BG6Cs2/zNLZ/qORRqqVDVRNmvORiyMMg6A== X-Received: by 10.36.25.139 with SMTP id b133mr3093439itb.0.1490651029626; Mon, 27 Mar 2017 14:43:49 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e195sm436141itb.18.2017.03.27.14.43.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 14:43:49 -0700 (PDT) To: Michael Richardson , anima References: <8858.1490649041@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <18b85223-7a64-c66d-eaf8-5dce3faad285@gmail.com> Date: Tue, 28 Mar 2017 10:43:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8858.1490649041@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] autonomic framework X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:43:52 -0000 So, are you going to stop changing the names now? Because each time you change them, I have to update draft-carpenter-anima-ani-objectives but more seriously my demo code too... Join Router is wrong. It forwards messages not packets. Maybe its next name should be Join Middlebox, but I'm happy with Join Proxy. Regards Brian On 28/03/2017 10:10, Michael Richardson wrote: > > Michael, some comments driven by the slides: > > We changed the name from Join Assistant to Join Proxy, as a consistent > name across netconf,anima and 6tisch. > > (Peter wants us to change it to Join Router, because it forwards > packets... but...) > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Mar 27 15:00:36 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68512708C for ; Mon, 27 Mar 2017 15:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6MW4FhsWyPYh for ; Mon, 27 Mar 2017 15:00:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DB312869B for ; Mon, 27 Mar 2017 15:00:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJT32176; Mon, 27 Mar 2017 22:00:18 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Mar 2017 23:00:17 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Mon, 27 Mar 2017 15:00:01 -0700 From: Hesham ElBakoury To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] key management for MACsec Thread-Index: AQHSpzDhUPALGHtCh0q2A8O4bo684aGpPFMw Date: Mon, 27 Mar 2017 22:00:00 +0000 Message-ID: References: <17467.1490643118@obiwan.sandelman.ca> In-Reply-To: <17467.1490643118@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58D98B72.01CF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 10618f2ed10c69bffea2121f6f05b641 Archived-At: Subject: Re: [Anima] key management for MACsec X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:00:35 -0000 Mike, 802.1AE (MACsec) key management is specified in 802.1X-rev2 (2010). Hesham -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Monday, March 27, 2017 12:32 PM To: anima@ietf.org Subject: [Anima] key management for MACsec Reading 802.1AE-2006, I did not see any key management protocol for MACsec.= I was thinking before that maybe we could write a MACsec key agreement me= chanism in IKEv2. I am now informed of 802.1Xbx-2014: Amendment 1: MAC Security Key Agreement Protocol (MKA) Extensions but, I see that it's really an amendment to 802.1X, which I am fetching now= . My thought was that if there *wasn't* a key agreement protocol for MACsec, = that one could use IKEv2, and could propose a) MACsec, b) IPv6-over-IPsec, c) GRE-over-IPsec, and let the normal IKEv2 process select which is supported. But, if MACsec already has a key agreement protocol, that would be superfluous. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Mon Mar 27 15:21:04 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C1C126BFD for ; Mon, 27 Mar 2017 15:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4vcQeJg2Oash for ; Mon, 27 Mar 2017 15:21:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085D7128E19 for ; Mon, 27 Mar 2017 15:21:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 353FA200A3; Mon, 27 Mar 2017 18:44:49 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3F03A636E0; Mon, 27 Mar 2017 18:21:00 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima In-Reply-To: <18b85223-7a64-c66d-eaf8-5dce3faad285@gmail.com> References: <8858.1490649041@obiwan.sandelman.ca> <18b85223-7a64-c66d-eaf8-5dce3faad285@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] autonomic framework X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:21:03 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > So, are you going to stop changing the names now? Because each time you > change them, I have to update draft-carpenter-anima-ani-objectives but > more seriously my demo code too... "me"? I didn't know I was authoritative for WG consensus :-) > Join Router is wrong. It forwards messages not packets. Maybe its next > name should be Join Middlebox, but I'm happy with Join Proxy. I agree. I'm thinking we should get a set of T-shirts. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljZkEwACgkQgItw+93Q 3WUBAAf7Bzj0fgsKFnAa4UULb2ad9Qjecm0+nyzCTZGPWx/9UNbrPClOirKpSnRW qTnKTdMFASDwlRWklUecOa/cQviAn+Buew4eXsKEpZKUVmaK/KeOc/Y8cbFy2k6Q LoAScvCqOjeLABLQpB8L0KEZQGkBZt6CuQ3wdXLZlrpn5UEixRRHk9EZtARf5cXB 4oJvfyMMuMRtz962fe7/DtXo8reITY4X3ZOuDXmCfTJdwrhBgUIQlNPs0cyWUslw T7EIV9OwumTOtOoTlOVZjOIMLD2eOTaeZWzFy3VRQNPMNzI8+zt1gU39VWAnTcvo UE/+9vmyO01fSf6bjmcgIyAiVbei6g== =5B1b -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 27 15:22:45 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3DA127871 for ; Mon, 27 Mar 2017 15:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 R8tK2NRzYLP5 for ; Mon, 27 Mar 2017 15:22:40 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347F7128E19 for ; Mon, 27 Mar 2017 15:22:40 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id 1ANd1v0094Hiz6i01ANdlE; Tue, 28 Mar 2017 00:22:38 +0200 Received: from t2001067c03700128d08b9180463cf798.v6.meeting.ietf.org (2001:67c:370:128:d08b:9180:463c:f798) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 28 Mar 2017 00:22:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Mar 2017 17:22:37 -0500 From: peter van der Stok To: Brian E Carpenter Cc: Michael Richardson , anima Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <18b85223-7a64-c66d-eaf8-5dce3faad285@gmail.com> References: <8858.1490649041@obiwan.sandelman.ca> <18b85223-7a64-c66d-eaf8-5dce3faad285@gmail.com> Message-ID: <56023943e511c758286fa765a538e625@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [Anima] autonomic framework X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:22:44 -0000 > > Join Router is wrong. It forwards messages not packets. Maybe its next > name should be Join Middlebox, but I'm happy with Join Proxy. > Yes it forwards the message, and IP-in-IP routes the packets. I prefer router because it makes it clear that the end to end transport is unbroken from pledge to registrar. The term proxy seems to provoke misunderstandings on that aspect. Peter From nobody Mon Mar 27 15:24:33 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1660126E3A for ; Mon, 27 Mar 2017 15:24:27 -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 G6obkWFUxjCC for ; Mon, 27 Mar 2017 15:24:26 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 36436126BFD for ; Mon, 27 Mar 2017 15:24:26 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 190so71049092itm.0 for ; Mon, 27 Mar 2017 15:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=bjZWMqX675r+4TmY0a0zyFjcK2/3Fd4PPL4Gi6aPBvA=; b=EhEaEgKAvfSQfsgCPXaxIfNurkGsqOLvGHM+3xJJfaDWxoyB3K7eMQdCMNILSPtgpS x6R8S/njOvA7ONUcFM4pyMZUeDenX8tsLBbM3zDBvZRrlcSuMA+/7utQ6NR7hApm28vC Pg8dJ082O4PW47PkLnBoqzXmVG3Pt2aLe7jyLHV8tmLU8L7MQ5iAYHWTexVf38oRADaE LgitUp0lLWSqe/L8y5cSdrdIf+E7w87UrynNVxthdax/6OV0LazuAvdso9vtOx69htJU IcgfzuDP3EoBPP1iTB8ReUjWSGLQ1hXaH037GYNKNsdfEKcRYe0zgfLOzk4/4LQ9fYsy h3lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=bjZWMqX675r+4TmY0a0zyFjcK2/3Fd4PPL4Gi6aPBvA=; b=r8uc8UJQvEl3uFRuMtTiM8wPQq6mvn/Ur89W/dShB3GL1el9A4VLF/M2FHCnxE7rsd IxqyOBkqcKz83/Ys0RoRLqWW30fXkpI7juQZI3tC3kPmk9BtGg7IouUyHYyt359mEJxW lWlIVzgA96D4FP651sOqIoHRpWVzmy4DBs6HLi/mlByYculAu3eDMQLXY5iDDMMxejPn oB+e4taKXzlj+Khlthw39XuwfL60m16qBYbTic4J9H65pKgYbpWwvz0Ih1QdRljKquWC RTR5md2+N8voKH3xm751rukUGi4hjh4rGwiOFa3U5HW4nd9Zf0kyRpj4IpebDfVUY//V m6sg== X-Gm-Message-State: AFeK/H2kA4SxauBR6Rj+ELQzm1uU1cumviFA842X8q2Tfoji1uefOB+zX76sS5pp41IXVw== X-Received: by 10.107.15.144 with SMTP id 16mr26488666iop.140.1490653465419; Mon, 27 Mar 2017 15:24:25 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 123sm911964iow.28.2017.03.27.15.24.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 15:24:25 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <704ebe84-8b56-4f27-c072-2b4ec23fbcb4@gmail.com> Date: Tue, 28 Mar 2017 11:24:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Proposed GRASP update text for Unicode issue X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:24:28 -0000 Hi, To follow up the Unicode issue mentioned today, I propose to add the following paragraph to the section "3.10.3. General Considerations for Objective Options" in draft-ietf-anima-grasp. Any comments from the WG? It would be nice to publish this while we are in Chicago: Names are expressed as UTF-8 strings for convenience in designing Objective Options for localized use. For generic usage, names expressed in the ASCII subset of UTF-8 are RECOMMENDED. Designers planning to use non-ASCII names are strongly advised to consult [RFC7564] or its successor to understand the complexities involved. Since the GRASP protocol compares names byte by byte, all issues of Unicode profiling and canonicalization MUST be specified in the design of the Objective Option. The only other difference would be to change the two SHOULDs for encryption to "MUST implement", as discussed today. Regards Brian From nobody Mon Mar 27 15:38:39 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3991B1296A3 for ; Mon, 27 Mar 2017 15:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MriL1E3G0s4A for ; Mon, 27 Mar 2017 15:38:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985BB12966F for ; Mon, 27 Mar 2017 15:38:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E2BF2200A3; Mon, 27 Mar 2017 19:02:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E0495636E0; Mon, 27 Mar 2017 18:38:35 -0400 (EDT) From: Michael Richardson To: Hesham ElBakoury cc: "anima\@ietf.org" In-Reply-To: References: <17467.1490643118@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] key management for MACsec X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:38:38 -0000 --=-=-= Content-Type: text/plain Hesham ElBakoury wrote: > 802.1AE (MACsec) key management is specified in 802.1X-rev2 (2010). yes, I've come to understand that it's there. mcr> but, I see that it's really an amendment to 802.1X, which I am fetching mcr> now. a) does it support stock PKIX certs for identities? b) is this implemented widely? c) are there major communities of users that essentially still use PSK to authenticate? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljZlGsACgkQgItw+93Q 3WV7MAgAkpVtULPWnejlOiPsgl5fpdtACLApYdPsYNCLeYwXo8nGMbKvl38/d2aT rMrHMBwVfPe024bSV+i59k0mUGGT/b77piMl2c3Y0NDp1pQl85lOwIap3tFaIYps ZV/vtGVAiAOmXcOkGG8+kRfVM0ep/lcDlNrC4ZFd++uryERquWUfQQQsQisb8t+O Z1tpHbFdECXv/ojO0T9Z2UZI4JJ5wnBomOl2HGxWK1f+Dezl1aPn870mosmoX+ZR aR4X+VWgIz8igtCiSEUzyaFJeCdPJYA8w3co6DXquqOC5K07KM1Zp84vFI3C2cs2 xeG05kW0xmtBWxp9FNa7O5uS92O4nQ== =Q3kB -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 27 19:24:29 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D181296E7 for ; Mon, 27 Mar 2017 19:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, 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 UCMOjvkBnJRF for ; Mon, 27 Mar 2017 19:24:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6AC12985B for ; Mon, 27 Mar 2017 19:24:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDQ04783; Tue, 28 Mar 2017 02:24:24 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 28 Mar 2017 03:24:23 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Mon, 27 Mar 2017 19:24:08 -0700 From: Hesham ElBakoury To: Michael Richardson CC: "anima@ietf.org" Thread-Topic: [Anima] key management for MACsec Thread-Index: AQHSpzDhUPALGHtCh0q2A8O4bo684aGpPFMwgACAYYD//8i8oA== Date: Tue, 28 Mar 2017 02:24:06 +0000 Message-ID: References: <17467.1490643118@obiwan.sandelman.ca> <28380.1490654315@obiwan.sandelman.ca> In-Reply-To: <28380.1490654315@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58D9C958.01DA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c78ee80b6d3de6f33db05ede19b0cf40 Archived-At: Subject: Re: [Anima] key management for MACsec X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 02:24:28 -0000 802.1X uses device certificates for mutual authentication. I am not sure h= ow wide spread the use of PSK is,=20 but I suspect it is fairly large given the ease of set-up, implementation a= nd test. For sure it is the most common use in WiFi. Hesham -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: Monday, March 27, 2017 3:39 PM To: Hesham ElBakoury Cc: anima@ietf.org Subject: Re: [Anima] key management for MACsec Hesham ElBakoury wrote: > 802.1AE (MACsec) key management is specified in 802.1X-rev2 (2010). yes, I've come to understand that it's there. mcr> but, I see that it's really an amendment to 802.1X, which I am fet= ching mcr> now. a) does it support stock PKIX certs for identities? b) is this implemented widely? c) are there major communities of users that essentially still use PSK to authenticate? -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Mon Mar 27 23:52:30 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87707129869 for ; Mon, 27 Mar 2017 23:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, 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 REgwckevvWK9 for ; Mon, 27 Mar 2017 23:52:27 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 9DE241296CD for ; Mon, 27 Mar 2017 23:52:26 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id w43so75592991wrb.0 for ; Mon, 27 Mar 2017 23:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=u1EblE2I1U1KQFcEj4Aj68lFjd41KGwmFoGH4E33Tqc=; b=gMWufhM4Mz4m3bJQ30pkkJZccMO5qY6NLaT9EfYeLbNAw+b4smzkg2R/GLFsgs2t04 pRCFO8mg8tLNeT88bjS4+fQ2zfbjFLqSSTw4+DXtVtFpgDAgopU9q74G5Tjv4FSlaHer V1fzWA1BbTjWVPms0fC7/wYX23M3GlCYK5wi7B4KXTR3XqtNP8Xdoosx0D/Uo+hDSkgs hj+L8pxFCnokVc82YTZm3cITu0m+CEyE2z+AZ0FSK84bxQsUWSGynJ6wbYkkIcN4o3kg gDfAeXV+fFc1pEGTwv/1y4MNxaX0kXRmJ66QTFY7FRJfFVoGn8RXmFYFzNdMnyxndXNg j4LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=u1EblE2I1U1KQFcEj4Aj68lFjd41KGwmFoGH4E33Tqc=; b=mTjH+i2fmxe2FsHMpBQ+dtzsm+cvX+E49xu/gn+p71M7TJ+pHShB/gkzBgGyQRAsOL yEyCuXqY6hXU50trbh+7Hqt+WW9VSVjsxeDY+1LILhUc4TSONCGXPk1hwpK8VW2RA3Jo dXvVnPgOoCIvL0akXN6lXo99/DyrDx/PvlArQxRjcP3t34jW+rPBpuJUpf2Fju0MtTFr 08r93UwrH4JQZHgXj23oar9P5bJHO0Op/yOxq4ekdcZvkw+xI1voX3ocUvuokllbJoaU bFA7a0gmuN1ayQDdrdMznln8WimZRNmgR2Y0tuQRIguysCMB3/oePcGd/ga+dBAZzQLs 4KtA== X-Gm-Message-State: AFeK/H3B29HUenPWqpZphZa0VYVeVcRzfOqK94BFZ31w5scdDFYtHWokcxZFOjqFesbNpQ== X-Received: by 10.28.90.2 with SMTP id o2mr11054774wmb.53.1490683945009; Mon, 27 Mar 2017 23:52:25 -0700 (PDT) Received: from [192.168.1.18] (ANice-652-1-9-124.w86-205.abo.wanadoo.fr. [86.205.176.124]) by smtp.gmail.com with ESMTPSA id 43sm3516568wry.45.2017.03.27.23.52.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 23:52:24 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Michael Richardson , anima References: <8858.1490649041@obiwan.sandelman.ca> Message-ID: Date: Tue, 28 Mar 2017 08:52:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8858.1490649041@obiwan.sandelman.ca> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Anima] autonomic framework X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 06:52:29 -0000
Join proxy is ok with me.

I find the "Join Registrar" a bit weird, to me "Registrar" itself is pretty clear in its purpose. But, never mind, main thing is we use the same terms everywhere.

I don´t really like the term "router" for the proxy. To me a "router" takes everything that comes in on one side, and sends it out the other. Here we´re talking a single protocol, thus very selective. "Proxy" describes that better than "router".

Michael

On 27/03/2017 23:10, Michael Richardson wrote:
Michael, some comments driven by the slides:

We changed the name from Join Assistant to Join Proxy, as a consistent
name across netconf,anima and 6tisch.

(Peter wants us to change it to Join Router, because it forwards
packets... but...)


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-






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

From nobody Tue Mar 28 20:30:04 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121DC127F0E for ; Tue, 28 Mar 2017 20:30:02 -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 pVW3vBkYXpPA for ; Tue, 28 Mar 2017 20:30:00 -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 E17D2127BA3 for ; Tue, 28 Mar 2017 20:29:59 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id y18so43616225itc.1 for ; Tue, 28 Mar 2017 20:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=XBhxSYmQqmqiRK5P/fqReVdwMfyEf1JLyaeojBKrfzI=; b=WiW7k2mDQ2xful/kQLHPKO8Fif7yr0sI5GMZdaHQ5Pa9xtJyI3Sv5vRu3nmLJ+6uMr CsBCT4kNLFvrfJT6toH2SjQr3TXGAo4qDdg6gnb2X+0hnK39IM2j8M63VUNNW2Uyvz1v jwH7fESbCR2mTs0aPHZGok7fDcQ3tS9566CrEAfH2PRjIDSmsEQoB97v5Jc7Q7dkJ5/Q oCZQC0rd+XZmxWOruZEwagqKdzi0lx3Vu65hPvaDkrbp3PeT5fLySJYbv431cxWc6UPc XvOF8I7X/7BbddG1SgZXR5xwUBLrZDn60DCDkJAQ0o1zXethh8XkR7jYjsl9QWxKVMxJ BvbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=XBhxSYmQqmqiRK5P/fqReVdwMfyEf1JLyaeojBKrfzI=; b=GOF9yEJXx31D5wBqRDltMvBnVHTbN2QBaLrfhDodIMhibPa0bjONylBfAm50W0+wYx WOlix1IWlkTStjlVgrl4OUDjaX2CvGjus9fY4MLEgwelyTwnz97KyOr6VfHBIgnpdkwX e/4wJj7GCsxPeg0vmF+1gLRIdGMY9Nf9phCWMziYgysRarWSk6eRbwmaaJqsw0D6y4/M lptgcx01Awpzfq/9495oCU8ilP5P/W+SrIpqgGyeouqH68GS7+Hz1X4RLcIWat11xxCF SKGQkg+DO9TZ76sYIhhtXmQP9eQkVH6wVH7z/KKmkRYuK5G8RgCTgpf1B8nEOrvhpvkN pmYA== X-Gm-Message-State: AFeK/H2UydyjyCazWj8IA9FeoOwGWdPNmF4EVg34Pes7rV3t0OPQTtIgWfNE6saQ0bTn2Q== X-Received: by 10.107.35.129 with SMTP id j123mr30205681ioj.195.1490758198921; Tue, 28 Mar 2017 20:29:58 -0700 (PDT) Received: from [31.133.147.88] (dhcp-9358.meeting.ietf.org. [31.133.147.88]) by smtp.gmail.com with ESMTPSA id r10sm3091640iod.33.2017.03.28.20.29.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 20:29:57 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <34d5f82d-c7b9-31c1-39b2-3ed51afe3665@gmail.com> Date: Wed, 29 Mar 2017 16:30:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Anima] FYI: GRASP testing this week X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 03:30:02 -0000 In the hackathon, the prototype GRASP implementation in Python 3 was=20 successfully tested on several Linux machines and a Windows host, provided by collaborators (Michael Richardson, William Atwood, J=C3=A9fer= son Campos Nobre) and myself. We also demonstrated the emulations of prefix assignment and secure bootstrap ASAs to interested people. We didn't hit any bugs in the Python (but all the test ASAs had been previously tested), so the main point was verifying portability. The test= s included at least one scenario with a physical topology loop (via Etherne= t and 802.11) which also demonstrated that GRASP multicast relaying does no= t cause packet loops. We seemed to spend a lot of time on installing current versions of Python and Python modules, and on networking setup. Actually running GRASP tests didn't take much time. After the hackathon, I worked with Bing Liu to test the BUPT student implementation of GRASP. Unfortunately it has some minor problems plus an error in the format of the Discovery messages, so that although we could move packets from one to the other, interoperation with the Python implementation was not possible. I also learned the hard way that the Python code throws an exception on a badly malformed Discovery packet (will fix!). We also tested the Python code on MacOS and showed it interoperating between Windows, Linux and MacOS simultaneously. =20 Regards Brian From nobody Wed Mar 29 08:04:40 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDF5126DD9; Wed, 29 Mar 2017 08:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tQYj2VUu4ADE; Wed, 29 Mar 2017 08:04:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3634127599; Wed, 29 Mar 2017 08:04:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 938BB200A3; Wed, 29 Mar 2017 11:28:03 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BBB12636E0; Wed, 29 Mar 2017 11:04:08 -0400 (EDT) From: Michael Richardson To: casm@ietf.org, anima@ietf.org cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org In-Reply-To: <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:04:13 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This discussion started in a private thread, so I'll try to bring people up-to-date by repeating and moving around text. The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is to do distributed prefix allocation. This is very much in the space of *coordinated* address management. (My take, BTW, is that CASM should be considered the first spin-off WG From=20ANIMA...) Mark and Brian discussed how HNCP does prefix distribution within Homenet. Brian then suggests: brian> But if the CE includes a little autonomic service agent (ASA) which brian> is in the ISP's security domain (not the SOHO domain), it can act = for brian> HNCP to solicit address space from the ISP. That's the southern si= de brian> of the CASM model and the northern side of HNCP. I asked a simple question: don't we have DHCPv6 for this? I also then asked: > a) the CPE device is now part of the ISP's ACP. > That's okay if the CPE device is owned by the ISP and/or the CPE devi= ce > includes some kind of trusted computation environment. > {But a CPE owned by the ISP, might not be trusted by the home owner, > so another router in between would be needed, Brian answered: > Really? Why not? I don't think that the ISP can trust to have code controlled by end users running in their ACP domain. I also think that many end-users will be quite reasonably upset that their ISPs can snoop on their internal traffic. This may in fact violate many work-at-home agreements; which is often the case of why you see multiple routers/firewalls in documents like https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. (Fred had more interesting diagrams in presentations, which I could dig up) >> b) DHCPv6 PD is already the protocol that solves prefix allocation a= cross >> trust boundaries. > Indeed. That's why we have "PD supported" as a Boolean property of t= he > PrefixManager objective. There's no intention to undermine PD. Why do I need to run a protocol in order to find if I can run a protocol, when DHCP has the same mechanism already. And use of DHCPv6 itself is well defined in cable and DSL connections already. >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that d= eals with >> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to t= he north. > Yes, the DSLAM is definitely a good place to put one. >> North of the ISP's device would be the ISP's (distributed) IPAM. >> GRASP/ASA-Prefix would be the protocol between. > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are > complementary not competitors. I don't see you saying that. I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HN= CP in the home) such that they interact directly, rather than using PD. You say this right here: brian> But if the CE includes a little autonomic service agent (ASA) which =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljbzOgACgkQgItw+93Q 3WWBcgf8CcE79ZLXXvDgkBd6u1TuXKIzWofyjbAJIC/ogOvh9QeCwsOi/WP89BNC EDxd6YytkRgHXyebOK7+L6PA3dQfUJBkcUUcAmJVJHfJT2lU0505TfAXIuQ6jPuU oWFjyzs/dG43v2wMd5nkMN+IcXIh5ceVeDagRkRW5GagItfbfqq4HHflSzrSHaRI +I4/tAd5P+KCBoX7N7hvI5TJ1W+xp1mBIVA0U/G673VeGFCyz1VQTnu+M+nRoY/l BBrxZrB8iZnC0jCSZjNp1Ki/5drlsQxAiT2XENrkNw5YFi6cEj+zLQSysgbuezmw 4iRD/nfxfrrLFv9dJUa5PkVn5vNMZA== =mM8R -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 09:13:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3563012943D; Wed, 29 Mar 2017 09:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sqhOfUkWceSO; Wed, 29 Mar 2017 09:13:46 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 7470F129876; Wed, 29 Mar 2017 09:13:39 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id f84so278811ioj.0; Wed, 29 Mar 2017 09:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DGYijWLnAJNW+R5cgLp4KNibgxvBxyPBwdlW20qNAWc=; b=JNRKI2yDcdhEGe8fn7YYL0ufmT1iuvACNDaov8lBqJchxjnkSWoBEI7kpDzPP0V69Z UeNSyyCxsLMue4oWF34pA2qWUnW7B4Ajw9eyr3Z3a6l6pOR+jec3Q3e4A91eGnPvKwP5 B/v25xwVhingtAO08iHw0AhfkNFU9RM4EQ7n9gVK7gejEYNhStu8mQG4HbX6W44gWtBX 6uld7afMKWlZfPpJEqfujywOXQG3xyJMpE1wDOstJMGLGmqMdRjKN5ARR1qqZnugoPoH yoj44qM2F008lq4dxol8VhtYeG/dJZ/WflIK/+oByAWY4XhFZUvH/B4IXhtcmZRcGEBD S/vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DGYijWLnAJNW+R5cgLp4KNibgxvBxyPBwdlW20qNAWc=; b=rew6F+OhFn/US34F9UbNRVB0nQcOhJ7RasBRnMeVAx7p9Id8NUSYGN7+fQrL+HPfvc qDoGMuYLGyGWzAHej2I/2nTbAaejbHOdp59PqZvwso9gfqykWO0l9hG0dcp12K7+2JK+ RpCiba4YwMH6UA8eFqCW/gbhXZH3vrtmIzbKs+GWrqhtQLQZsoQJ6YLOywRnaVMOUZys U/KsWv29fYl+fD8G6Fo+qWsW8jrQq7IAEtBLbcko8n4TprBtfjQX8i2GZYFwSsSIsVqS SC/NMvSjPT7BQltATbm0JqhNvBgCK/Y1babCBEy/nZkae+yho5c4jc7rUuW8+vtCMsvs hDCg== X-Gm-Message-State: AFeK/H1qP5aViKzEQrR+f1iuX1rgjI5JcAe7G51gqnKlWuSZEF/9BWCxRg178JlgzqFq6w== X-Received: by 10.107.47.130 with SMTP id v2mr1507287iov.201.1490804018715; Wed, 29 Mar 2017 09:13:38 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o97sm1760077ioi.53.2017.03.29.09.13.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 09:13:38 -0700 (PDT) To: Michael Richardson , casm@ietf.org, anima@ietf.org References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> Cc: Mark Townsley , homenet@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 05:13:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <28218.1490799848@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:13:49 -0000 OK, I'll front-post. Where you want to plug in an ASA (autonomic service agent) is anywhere you want plug in some intelligence to govern an automatic process. Intelligence, for example, to figure out what to do if the user side asks for a /48 and the ISP offers a /60. So the ASA might negotiate a compromise at /56 and then PD does its thing. But we didn't want to exclude a scenario where PD isn't available, hence a flag is included. About the domain boundary: > I don't think that the ISP can trust to have code controlled by end users > running in their ACP domain. Right. But in ISP-provided CEs this could presumably be fixed, because that code would be locked down. In a store-bought CE, isn't this exactly where BRSKI will help us? There is certainly an issue for home-made CE images, but they will be a tiny minority of users. Brian On 30/03/2017 04:04, Michael Richardson wrote: > > This discussion started in a private thread, so I'll try to bring people > up-to-date by repeating and moving around text. > > The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is > to do distributed prefix allocation. This is very much in the space of > *coordinated* address management. > > (My take, BTW, is that CASM should be considered the first spin-off WG > From ANIMA...) > > Mark and Brian discussed how HNCP does prefix distribution within Homenet. > > Brian then suggests: > > brian> But if the CE includes a little autonomic service agent (ASA) which > brian> is in the ISP's security domain (not the SOHO domain), it can act for > brian> HNCP to solicit address space from the ISP. That's the southern side > brian> of the CASM model and the northern side of HNCP. > > I asked a simple question: don't we have DHCPv6 for this? > > I also then asked: > > > a) the CPE device is now part of the ISP's ACP. > > That's okay if the CPE device is owned by the ISP and/or the CPE device > > includes some kind of trusted computation environment. > > {But a CPE owned by the ISP, might not be trusted by the home owner, > > so another router in between would be needed, > > Brian answered: > > Really? Why not? > > I don't think that the ISP can trust to have code controlled by end users > running in their ACP domain. > > I also think that many end-users will be quite reasonably upset that their > ISPs can snoop on their internal traffic. This may in fact violate many > work-at-home agreements; which is often the case of why you see multiple > routers/firewalls in documents like > https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. > > (Fred had more interesting diagrams in presentations, which I could dig up) > > >> b) DHCPv6 PD is already the protocol that solves prefix allocation across > >> trust boundaries. > > > Indeed. That's why we have "PD supported" as a Boolean property of the > > PrefixManager objective. There's no intention to undermine PD. > > Why do I need to run a protocol in order to find if I can run a protocol, > when DHCP has the same mechanism already. And use of DHCPv6 itself is well > defined in cable and DSL connections already. > > >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals with > >> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the north. > > > Yes, the DSLAM is definitely a good place to put one. > > > >> North of the ISP's device would be the ISP's (distributed) IPAM. > >> GRASP/ASA-Prefix would be the protocol between. > > > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are > > complementary not competitors. > > I don't see you saying that. > > I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP > in the home) such that they interact directly, rather than using PD. You > say this right here: > > brian> But if the CE includes a little autonomic service agent (ASA) which > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Mar 29 11:08:28 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180621292F4 for ; Wed, 29 Mar 2017 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jCxWwUp5sbaz for ; Wed, 29 Mar 2017 11:08:25 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 48C6D1289B0 for ; Wed, 29 Mar 2017 11:08:25 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id e75so10747696itd.1 for ; Wed, 29 Mar 2017 11:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=VGgvLKkAy4cPCLJoPyaOBZi9o/zQBspjURpeGfmAzNA=; b=SXLszstF4pvkamKrFrSbFvMScCThYbxue4MiUyEosbtrAApwFnipbLdzmVBYd6DeCF Jt2eLRV+UaBjVAj4Z4lYcyi4Ndh7LIU4XRRQVYln+FC9wiM9MQc1lbAy2ts4crwdXRdF Byt+QiyTgT5yFyc4DOa70M1jQ5xQKNHwpEVS/Bv8YsaPo6YTfVR0tLtOAbixx1Ufbdp8 9kDZ9P0SnliWy41XJBP1jxR8o7Az4H8o7lunH4aXCHz0BcCEoxKp6ozfbnr4FRJoiE3T r10re+//Rdy/vuUH2bSchG5pNcZpCU7ZOVXrfl/6Kk7wTO8P7Vd37Uzf4kqDFxaHz72b NVfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=VGgvLKkAy4cPCLJoPyaOBZi9o/zQBspjURpeGfmAzNA=; b=WnjgV+suJXXdLnjobVqHhhV7S5O/CMMY/NWZlXyZxJIgwqBCzAvE4k0K+yyaJN0PYP sHCasjG+iClfBQi06eM2PKmOtGiC1+KhfJj+HU8UQ8HB0JdSLU/DSVshZn+bluRc9370 MqcKzBMk8Z9jDTpdn5/08DCFvyfvv4JeVHwKDQootzdrEJyzo+nyE5z8LjdQpCWE4qAU QzgnWK9hxSS6OLDzKmW4vWsDXpygMR0BYJk36I13LivJMkeLX3Sk8byOIVSvdznGjSNI LVbFT7nq53r6P7lrE0lJJCGAZP8AT2zD6VFatOsvmPaQtQZZM5rq4lzBmoLa1E+51DKP YooA== X-Gm-Message-State: AFeK/H3+cSj5N/k1aHbd0NWz86PTcRKtIO/z3dsU5H0tvnZKfZ1ijp+eLpQ3RlbRcrT9Mw== X-Received: by 10.36.200.84 with SMTP id w81mr2688461itf.22.1490810904528; Wed, 29 Mar 2017 11:08:24 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m100sm22201iod.14.2017.03.29.11.08.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 11:08:24 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <1347ae5f-4e68-c4d7-4cfd-3df0295993ce@gmail.com> Date: Thu, 30 Mar 2017 07:08:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP multicast frequency X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:08:27 -0000 One more thing from our tests this week. We noticed when testing at busy times that link-local multicasts were often dropped. We would see quite long gaps when discovery and flooding simply did not occur. Suspecting that the wireless network was limiting the rate of multicasts, I cheated for a few minutes by sending multicasts 10 times more frequently, and the gaps in performance vanished. According to the NOC: > > Do the access points throttle the rate of IPv6 link-local multicasts? > Yes, we do MLD snooping on our wireless LAN controllers to prevent > multicast storms over the air. The MLD timeout and MLD query interval are > set to 60 seconds and 20 seconds, respectively. So, on a busy network the effect of that is apparently to incent a protocol like GRASP to increase its rate of LL multicasts to grab a sufficient share of capacity. Since we need the autonomic mechanisms to work well in times of overload, this effect needs to be understood by implementors. Regards Brian From nobody Wed Mar 29 13:16:38 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8ED127BA3; Wed, 29 Mar 2017 13:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 IsKGJZS7LrWD; Wed, 29 Mar 2017 13:16:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07D812704B; Wed, 29 Mar 2017 13:16:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F60C203B7; Wed, 29 Mar 2017 16:40:24 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 029BD636E0; Wed, 29 Mar 2017 16:16:29 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org In-Reply-To: References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:16:32 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Where you want to plug in an ASA (autonomic service agent) is anywhere > you want plug in some intelligence to govern an automatic process. > Intelligence, for example, to figure out what to do if the user side > asks for a /48 and the ISP offers a /60. So the ASA might negotiate > a compromise at /56 and then PD does its thing. But we didn't want > to exclude a scenario where PD isn't available, hence a flag is > included. To put this is pseudo-(monty)pythonesq: Customer: Hi, I'd like to buy a parrot. Store: Would you like a Blue Parrot or a Red Parrot? Customer: I'd like a Blue Parrot. Store: I'm sorry, but we don't sell Parrots. I just don't see the point of the ASA here. If DHCPv6-PD isn't available, then it's not a compliant ISP connection (RFC7204) and it's outside of the scope of homenet to begin with. > About the domain boundary: >> I don't think that the ISP can trust to have code controlled by end users >> running in their ACP domain. > Right. But in ISP-provided CEs this could presumably be fixed, because > that code would be locked down. In a store-bought CE, isn't this exactly > where BRSKI will help us? There is certainly an issue for home-made CE > images, but they will be a tiny minority of users. No, BRSKI doesn't help the ISP feel safe that the code I am running on my store-bought CE won't attempt to mess with their network. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcFhwACgkQgItw+93Q 3WUQYwf+I+RwnzYZOAh/cem16Dlxq+EA+qcmCY740lGwg6RmzXYYTy2qWVvvwYOH U2Op4ngX0x1aL6YVGiqJ2Du6KkeMV5InbUMMHksIh11l9szmexGAgQ605/Go8Uri /YHdR32safjVpEiS57VbAR+FLFZooQ9m3UQb617RWL1TMZHvV9X3Ud87KwqikziR A5SEruGC0jWIXZeIcNjCC/vYUcF6LeCwaoGHBHYyhkce0U19jAfVTxY+2xe1su+U l2yhWaG//XGuP2XtI/pS9bbt1aH/cDFekb6tj3BN8viIMqEU4t22yE6SxMK917tC MhSKAMlOR9UcVr5vuQoWG6KRnAwDRw== =LfbD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 13:47:00 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0728D12785F; Wed, 29 Mar 2017 13:46:53 -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 9FhHh5gQwgGt; Wed, 29 Mar 2017 13:46:51 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 0A6A912956C; Wed, 29 Mar 2017 13:46:51 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id w11so3643529itb.0; Wed, 29 Mar 2017 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=F60E85dKcF87/QWxtPhnnfRjuZXf/80TvUSMYICj9KM=; b=JAkNKRsUcHo8rNy1i27TOoSdw6rSe2R2mXtSTF4pvLMp+ZyfWgSRKFudHkfsWIdV5r JjJAItJ4D+yQWn1KE1Pyaph25j7yxPU3l5AaN6C3zDnm/iMGxIzMbV2LpwgLoUQ30ggz ltZJ4duHOQaZl8FH4/fpPO9rJ6WNTWXaCwk1hiNkhbic67sxtw/1c04EFviwG4lsF/Yt xWMlO9koZ6lyKf0Yic6A72YdEOjRrH3fFadi1FkOd6t2wrGlj6ucWtImN9D9HI71QDxS fWIosHx6bmAvn+orvkqJHRQiZTrj75BMMAP8N3Qk8WjroPb90QImOuSGFycasgxZeDoX HyGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=F60E85dKcF87/QWxtPhnnfRjuZXf/80TvUSMYICj9KM=; b=kHLLRAIhmXVNPlJoZZa52m/U5XxjWKVg1gp8f8mr+J5AZs/vs/KOU0ccTFP7EvaZVd cy6gg1PR5xaFONJtavQUsY+3FApb43kzzqLAhfzLllUj3fR14jn/PbK0vQixm6MB9JW7 HtC2ftGiXfNe6fNrIRlZgaHDIWLtgrbhIpy7RlrRk9rXTbV3PC7hLDEbFI4U5Xt1tXmU jS637QvietE7JWpq9k/csPjsaezRAxEd5ATk+RR9CIhmmUUO/hyiSBRGHvMxGmladNtW YJAf+vxR18NirAvht85RkQSp4MQOa66dyW4PKfSo3Xe7qlll6zYYzNW6auU3tzK8iLEL sCNA== X-Gm-Message-State: AFeK/H1ln8V7TJidnqP+7Kbp/nwvlH0VQ4tU3224Qb/F/OTw5dvCrGOLRFJVCrIGFNh+aQ== X-Received: by 10.36.28.130 with SMTP id c124mr409142itc.17.1490820410424; Wed, 29 Mar 2017 13:46:50 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q185sm3893461itc.22.2017.03.29.13.46.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 13:46:49 -0700 (PDT) To: Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> Cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> Date: Thu, 30 Mar 2017 09:46:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <14579.1490818588@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:46:53 -0000 On 30/03/2017 09:16, Michael Richardson wrote: > > Brian E Carpenter wrote: > > Where you want to plug in an ASA (autonomic service agent) is anywhere > > you want plug in some intelligence to govern an automatic process. > > Intelligence, for example, to figure out what to do if the user side > > asks for a /48 and the ISP offers a /60. So the ASA might negotiate > > a compromise at /56 and then PD does its thing. But we didn't want > > to exclude a scenario where PD isn't available, hence a flag is > > included. > > To put this is pseudo-(monty)pythonesq: > > Customer: Hi, I'd like to buy a parrot. > Store: Would you like a Blue Parrot or a Red Parrot? > Customer: I'd like a Blue Parrot. > Store: I'm sorry, but we don't sell Parrots. No, it's not really Pythonesque but negotiation is allowed to fail. > I just don't see the point of the ASA here. There's already a thing called an HNCP agent. Why couldn't it be enhanced to negotiate with an upstream ASA for resources? > If DHCPv6-PD isn't available, then it's not a compliant ISP connection > (RFC7204) and it's outside of the scope of homenet to begin with. No disagreement; the idea was simply to ensure that the GRASP objective can communicate that PD is or isn't available. If PD is required in a particular scenario then that parameter will always be set True. > > About the domain boundary: > > >> I don't think that the ISP can trust to have code controlled by end users > >> running in their ACP domain. > > > Right. But in ISP-provided CEs this could presumably be fixed, because > > that code would be locked down. In a store-bought CE, isn't this exactly > > where BRSKI will help us? There is certainly an issue for home-made CE > > images, but they will be a tiny minority of users. > > No, BRSKI doesn't help the ISP feel safe that the code I am running > on my store-bought CE won't attempt to mess with their network. Yes, I see that. (Unless of course we get into much more complex validation and authorization stuff, which seems unlikely to fly.) Brian From nobody Wed Mar 29 13:52:15 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2454512956C for ; Wed, 29 Mar 2017 13:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WovTn0IRNWa9 for ; Wed, 29 Mar 2017 13:52:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88AB12948A for ; Wed, 29 Mar 2017 13:52:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3171F203B7; Wed, 29 Mar 2017 17:16:06 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7776D636E0; Wed, 29 Mar 2017 16:52:10 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: <34d5f82d-c7b9-31c1-39b2-3ed51afe3665@gmail.com> References: <34d5f82d-c7b9-31c1-39b2-3ed51afe3665@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] FYI: GRASP testing this week X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:52:13 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > with the Python implementation was not possible. I also learned the > hard way that the Python code throws an exception on a badly > malformed Discovery packet (will fix!). It would be nice to capture that broken packet as a test case. Please send pcap if you have it. > We also tested the Python code on MacOS and showed it interoperating > between Windows, Linux and MacOS simultaneously. And your code needs python 3.4, 3.2 isn't new enough. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcHnoACgkQgItw+93Q 3WUqswf/WsuVuenqw48lIWbqUd1RfC7ukswIKfsqNqSZQvo9GVFhSkZjmSnwO04S gIvALxM4i41k4MEt3Z/cJT6blc6HIa3gJYStRyfesivDbldcp7IRKYtpkwnpPYbt vFMy35uGIeHO0YBOe4CKA95bpAtR1Z3sdxgVmdGQIqy+4xREQFZJn8il4iyjalry 59k/gV26dHNO8ScHr08Uz3VGeUbNSdEQOsDxmwQEG16md3OhT0PB0qc9xmO/lhZ+ 1qW94fafascqahwFbD0MB1plf6nCTd9tI/xdeO+dLdCJbniYuUzNzsfgJ5X0IQ0s 0X/X563XMeWyOlJnF0mImDLxAI2zYQ== =VItG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 13:56:35 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4569412945D; Wed, 29 Mar 2017 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 HP2lVjp_IezK; Wed, 29 Mar 2017 13:56:26 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 64909129891; Wed, 29 Mar 2017 13:56:25 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v2TKuNUF013675; Wed, 29 Mar 2017 22:56:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id ADB7AD78B7; Wed, 29 Mar 2017 22:56:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id arPhDVrfdgX9; Wed, 29 Mar 2017 22:56:22 +0200 (CEST) Received: from ijon.irif.fr (dhcp-8558.meeting.ietf.org [31.133.133.88]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D7242D78F6; Wed, 29 Mar 2017 22:56:18 +0200 (CEST) Date: Wed, 29 Mar 2017 15:56:22 -0500 Message-ID: <87shlvhkeh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Michael Richardson Cc: casm@ietf.org, anima@ietf.org, homenet@ietf.org In-Reply-To: <28218.1490799848@obiwan.sandelman.ca> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 29 Mar 2017 22:56:23 +0200 (CEST) X-Miltered: at korolev with ID 58DC1F77.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58DC1F77.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58DC1F77.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 20:56:28 -0000 brian> But if the CE includes a little autonomic service agent (ASA) which brian> is in the ISP's security domain (not the SOHO domain), it can act for brian> HNCP to solicit address space from the ISP. That's the southern side brian> of the CASM model and the northern side of HNCP. HNCP just doesn't care. HNCP has a notion of "External Connection", and an External Connection may provide one or more External Prefixes. HNCP will assign to each link in the HNCP one /64 from each External Prefix. HNCP doesn't care where these External Connection TLVs come from, but it is my understanding that there is WG consensus that DHCPv6-PD is the default mechanism. I don't think there's anything in any of our RFCs that would prevent an implementation from obtaining External Prefixes using a different protocol, e.g. manual configuration, a proprietary provisioning protocol or even algorithmically derived from an IPv4 address (as with 6rd). Both implementations of HNCP are easy to extend with a different mechanism for obtaining External Prefixes, should you wish to experiment. -- Juliusz From nobody Wed Mar 29 14:05:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8C6126DDF; Wed, 29 Mar 2017 14:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 METRaPwEtr4c; Wed, 29 Mar 2017 14:05:01 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 2BFF9124217; Wed, 29 Mar 2017 14:05:01 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v2TL4uiB016063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Mar 2017 23:04:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id v2TL4uUb006204; Wed, 29 Mar 2017 23:04:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2813ED78F6; Wed, 29 Mar 2017 23:04:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id wBxGdJggd7pu; Wed, 29 Mar 2017 23:04:55 +0200 (CEST) Received: from ijon.irif.fr (dhcp-8558.meeting.ietf.org [31.133.133.88]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C64B5D78C3; Wed, 29 Mar 2017 23:04:46 +0200 (CEST) Date: Wed, 29 Mar 2017 16:04:50 -0500 Message-ID: <87r31fhk0d.wl-jch@irif.fr> From: Juliusz Chroboczek To: Brian E Carpenter Cc: Michael Richardson , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 29 Mar 2017 23:04:56 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 29 Mar 2017 23:04:56 +0200 (CEST) X-Miltered: at korolev with ID 58DC2178.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 58DC2178.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58DC2178.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 58DC2178.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58DC2178.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 58DC2178.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:05:03 -0000 > There's already a thing called an HNCP agent. Why couldn't > it be enhanced to negotiate with an upstream ASA for resources? Could you please clarify what you mean by "negotiate"? Current HNCP implementations are provided with a bunch of External Prefixes, which they then carve into /64, one per prefix. Are you envisioning a scenario where the HNCP implementation actually performs active negotiation on its external interfaces? -- Juliusz From nobody Wed Mar 29 14:39:12 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FE91293EE; Wed, 29 Mar 2017 14:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pKoT4lbMrvUk; Wed, 29 Mar 2017 14:38:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BB71250B8; Wed, 29 Mar 2017 14:38:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C9D6203B0; Wed, 29 Mar 2017 18:02:51 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B6D69636E0; Wed, 29 Mar 2017 17:38:55 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org In-Reply-To: <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:38:58 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> I just don't see the point of the ASA here. > There's already a thing called an HNCP agent. Why couldn't > it be enhanced to negotiate with an upstream ASA for resources? Because it's already done. It's called DHCPv6. It already has extensive running code :-) It's not even that complex. I would love to request address space via ASA from the DHCPv6 server. That would all happen within the ISP's ACP though. Right now (on DSL lines), the address space mostly comes via radius. Which is to say that the problem has been centralized by MBS builders into being someone else's problem. Advertising the address space is often done by OSPFv3, but there are additional things that would be easier for the DHCPv6 server to do, such as the DNS delegations that homenet is working on finishing. I think that CASM could very nicely define/extend the prefix ASA to deal with DNS reverse names, and as the RIRs (George) said, better link the delegated prefix to clear ownership records. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcKW8ACgkQgItw+93Q 3WU72wf+PPC8ZFrnt9lHQqsaBLizGmYzqdllAEWch6TnQETLwAJjiMk644oPUN+2 GmC8AtgW6PzffL/1zsZHYlMLBn5uM2sZunQBufsW5da9yXkThUeHAsRUQ85n3uGC HI1xFQaCAkrelussMo9OKofLWMLv1repOQURuiKGNdP0OpD1fn/D+ZsCBhEvPx0l 2b8z/V2K0Oed2KCtDwCtYE8mcG9uiK1FCCPa64VLayD4Mw+uIjXrjrDXDX9RhC9V H5AKNiyeS6NXOmMJs/8TdPlzzceXAY7ek5Bp1c/LzJrqiDR0pozQMMOivuXiCRxQ Sc2lpo8VdcT4sC1RiUa4wVD70t4EgA== =D0pq -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 14:42:02 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529F9129465; Wed, 29 Mar 2017 14:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dOb4eZtLl9LF; Wed, 29 Mar 2017 14:41:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5CB12948C; Wed, 29 Mar 2017 14:41:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CA89203B0; Wed, 29 Mar 2017 18:05:41 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 92365636E0; Wed, 29 Mar 2017 17:41:45 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <87r31fhk0d.wl-jch@irif.fr> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:41:49 -0000 --=-=-= Content-Type: text/plain Juliusz Chroboczek wrote: >> There's already a thing called an HNCP agent. Why couldn't >> it be enhanced to negotiate with an upstream ASA for resources? > Could you please clarify what you mean by "negotiate"? Current HNCP > implementations are provided with a bunch of External Prefixes, which they > then carve into /64, one per prefix. Are you envisioning a scenario where > the HNCP implementation actually performs active negotiation on its > external interfaces? Yes, that's what Brian is suggesting. The HNCP daemon would speak GRASP ASA on the "northbound" interface. It wouldn't necessarily speak HNCP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljcKhkACgkQgItw+93Q 3WX4fAf+P+vJtXc7W3n+tF1e1K8/0EH+L8dyzjmR4yCg6hLICqscAIm/vT6tveB6 4P0Qzmi1TDgYDRZl64aGQ8e044qoURoyh10kj5EHcor5CY+oSA1QKzFseWGzXDCG RLGUbHgrU6Xz/5br+Mf7ACsSyCybCwi/WjRgH6duaIsmM25uQxsuxWukAVeeU4RQ +OAfrTR3MSdiYv/4whiDxCXo1BuGFNqT09zfstcgqTdEA9/9mKL8ZkDNCIsr3pSr deofhFijyNBk/Z8/fUWGjde7Y6UEgffdEB3pLBxZXZdMA7A/SBQP3E22WWTtNC7E 7dlfB2g8faEjPeKtzn7bKf71KGGa9Q== =Ou1x -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 29 14:59:41 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A367126C23; Wed, 29 Mar 2017 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 utFF5lWxX5mc; Wed, 29 Mar 2017 14:59:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 373C312949E; Wed, 29 Mar 2017 14:59:27 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v2TLxMFl029474; Wed, 29 Mar 2017 23:59:22 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 91D84D79D6; Wed, 29 Mar 2017 23:59:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Zk5S5GjTzP9n; Wed, 29 Mar 2017 23:59:21 +0200 (CEST) Received: from ijon.irif.fr (dhcp-8558.meeting.ietf.org [31.133.133.88]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2FC51D79B8; Wed, 29 Mar 2017 23:59:20 +0200 (CEST) Date: Wed, 29 Mar 2017 16:59:22 -0500 Message-ID: <87h92bhhhh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Michael Richardson Cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <1636.1490823705@obiwan.sandelman.ca> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 29 Mar 2017 23:59:22 +0200 (CEST) X-Miltered: at korolev with ID 58DC2E3A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 58DC2E3A.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 58DC2E3A.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:59:29 -0000 >> Could you please clarify what you mean by "negotiate"? Current HNCP >> implementations are provided with a bunch of External Prefixes, which they >> then carve into /64, one per prefix. Are you envisioning a scenario where >> the HNCP implementation actually performs active negotiation on its >> external interfaces? > Yes, that's what Brian is suggesting. > The HNCP daemon would speak GRASP ASA on the "northbound" interface. Sorry if I wasn't clear. Would it merely request address space and handle it out using HNCP, or would it actively renegotiate address space in response to HNCP events? If the latter -- why? From nobody Wed Mar 29 15:15:09 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585D6126C23; Wed, 29 Mar 2017 15:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 67qQ_J0_fXwM; Wed, 29 Mar 2017 15:15:05 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A5F1279E5; Wed, 29 Mar 2017 15:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3799; q=dns/txt; s=iport; t=1490825705; x=1492035305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DFCqdQxT9B/m0+ZuK1XWA7a7oR1wzfDZFc5xltaGbDE=; b=BTd/yzJtWdhMUZt/zi7s+slMkv9O7BrA/y6MYDsQSgyzi7i0hLlNH9g0 UqHo7CwQ4W+XkH6664pNCwJzQvYRLzeRBarosSEGLLip+DLa3WHyI5Sxx 5xa5wY9XlPUHnS4dDRkzzjf3tUOBb/wPtZF4Pqr39pNV4VIUKLy786fGM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQCCMdxY/4UNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQsHjWyRMh+VToIOHwuCQoJsSgKDQz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBODQLBQsCAQgYHhAnCyUCBA4FigIIDrAmilkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYhTCIJihFSDNIIxBZxgAYZ8gyqIKZEzk2kBHziBBFkVQRE?= =?us-ascii?q?BhkZ1iCmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,243,1486425600"; d="scan'208";a="229445798" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 22:14:38 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2TMEc11001665 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 22:14:38 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 17:14:37 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 17:14:37 -0500 From: "Mark Townsley (townsley)" To: Michael Richardson CC: "casm@ietf.org" , "anima@ietf.org" , "homenet@ietf.org" Thread-Topic: [homenet] prefix assignment Thread-Index: AQHSp9vjxu1NLCXsxk6FBlrX+TkYTqGqzpsAgAFw7ACAAHhGAA== Date: Wed, 29 Mar 2017 22:14:37 +0000 Message-ID: <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> In-Reply-To: <28218.1490799848@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.184.139] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:15:07 -0000 > On Mar 29, 2017, at 10:04 AM, Michael Richardson = wrote: >=20 >=20 > This discussion started in a private thread, so I'll try to bring people > up-to-date by repeating and moving around text. >=20 > The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is > to do distributed prefix allocation. This is very much in the space of > *coordinated* address management. >=20 > (My take, BTW, is that CASM should be considered the first spin-off WG > From ANIMA...) >=20 > Mark and Brian discussed how HNCP does prefix distribution within Homenet= . I was really pointing out that RFC 7695 could be used independent of HNCP.= =20 HNCP is just one protocol that uses the RFC 7695 distributed prefix assignm= ent algorithm (which actually began as extensions to OSPF before HNCP even = existed).=20 - Mark >=20 > Brian then suggests: >=20 > brian> But if the CE includes a little autonomic service agent (ASA) whi= ch > brian> is in the ISP's security domain (not the SOHO domain), it can act= for > brian> HNCP to solicit address space from the ISP. That's the southern s= ide > brian> of the CASM model and the northern side of HNCP. >=20 > I asked a simple question: don't we have DHCPv6 for this? >=20 > I also then asked: >=20 >> a) the CPE device is now part of the ISP's ACP. >> That's okay if the CPE device is owned by the ISP and/or the CPE device >> includes some kind of trusted computation environment. >> {But a CPE owned by the ISP, might not be trusted by the home owner, >> so another router in between would be needed, >=20 > Brian answered: >> Really? Why not? >=20 > I don't think that the ISP can trust to have code controlled by end users > running in their ACP domain. >=20 > I also think that many end-users will be quite reasonably upset that thei= r > ISPs can snoop on their internal traffic. This may in fact violate many > work-at-home agreements; which is often the case of why you see multiple > routers/firewalls in documents like > https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-route= r. >=20 > (Fred had more interesting diagrams in presentations, which I could dig u= p) >=20 >>> b) DHCPv6 PD is already the protocol that solves prefix allocation acro= ss >>> trust boundaries. >=20 >> Indeed. That's why we have "PD supported" as a Boolean property of the >> PrefixManager objective. There's no intention to undermine PD. >=20 > Why do I need to run a protocol in order to find if I can run a protocol, > when DHCP has the same mechanism already. And use of DHCPv6 itself is we= ll > defined in cable and DSL connections already. >=20 >>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deal= s with >>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the = north. >=20 >> Yes, the DSLAM is definitely a good place to put one. >=20 >=20 >>> North of the ISP's device would be the ISP's (distributed) IPAM. >>> GRASP/ASA-Prefix would be the protocol between. >=20 >> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are >> complementary not competitors. >=20 > I don't see you saying that. >=20 > I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and = HNCP > in the home) such that they interact directly, rather than using PD. You > say this right here: >=20 > brian> But if the CE includes a little autonomic service agent (ASA) whi= ch >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Wed Mar 29 15:42:51 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DBA129611 for ; Wed, 29 Mar 2017 15:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 vEJA_UB0UG8V for ; Wed, 29 Mar 2017 15:42:48 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 ADEB71295EE for ; Wed, 29 Mar 2017 15:42:48 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id 68so1266892ioh.3 for ; Wed, 29 Mar 2017 15:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xSJQMyaxBrNObtZRZUI2oQ+OhIrDTsB3YpTVllwpO3o=; b=Ko/tFZCQho3x/AZbip9WW19M2QxSYuVd7RuDLNRCwCvZwUd+DdFCwj4eOas4mXIw55 uKjHP+jcV/UQUhJj+940UJG+io4aAMp0L54YV19Bp2svN27jlaUHCJ3GKGNm4I2rhwlu jznGGKrusiah2boUF1gZU+1np/TvwrETi0Hay23r9PCQopYuEtSKBYpk2bvvzoxAlhTe N+uWhVaPfnREN2LdTygj1Hr55ZQ2xC8VQPXnLscrqusSljjMj3irTLFLDvXkUpj8RXY5 1bptczRNnKgboPRQv1jffWFcqp3S8EFb5WaN9cn0kJmFRegOPxnzFSoKO4cyof3WrSNs +kaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=xSJQMyaxBrNObtZRZUI2oQ+OhIrDTsB3YpTVllwpO3o=; b=DbMvEl1cYtdokymf0LvBbZMvv2TuIGdWiQrcZ/cW8XF8RXa00yQr6vEqcDOTAsiZ+6 qe9ipFHd/ELtt75+P5gM8G3Dd+wcyfG62kteJJo+0Tjjx0qSN/KKPyma9TyeLqxd7adO WLRyVWA22XnDFyRSoL+IvcAmTVtLAs5eblHUApWCPpsqKfPAMf/XrBWbA6LFgD0lAEXr w6F2AOHWyIIS9gMLhZyCi0vc8LwH5ix5JZVfU8yaQEO207o45yAutY55ckV+cRbeXoI+ 1ohbxV+n7SAuexI/lzJlDbq8MxQDo9S1s41IAOBbzBf6l2dgoeK9ACqpJC+QxwD5it8y qabQ== X-Gm-Message-State: AFeK/H3HNHlrZeRwtOKQ3DOyVs0wjoZtwXQFQwj43ErYQeUKsnxg8R4PA5S0nDF8Z4YILA== X-Received: by 10.107.16.217 with SMTP id 86mr3455974ioq.228.1490827367920; Wed, 29 Mar 2017 15:42:47 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m100sm391461iod.14.2017.03.29.15.42.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 15:42:46 -0700 (PDT) To: Michael Richardson References: <34d5f82d-c7b9-31c1-39b2-3ed51afe3665@gmail.com> <22694.1490820730@obiwan.sandelman.ca> Cc: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 11:42:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <22694.1490820730@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] FYI: GRASP testing this week X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:42:50 -0000 On 30/03/2017 09:52, Michael Richardson wrote: > > Brian E Carpenter wrote: > > with the Python implementation was not possible. I also learned the > > hard way that the Python code throws an exception on a badly > > malformed Discovery packet (will fix!). > > It would be nice to capture that broken packet as a test case. > Please send pcap if you have it. off list > > > We also tested the Python code on MacOS and showed it interoperating > > between Windows, Linux and MacOS simultaneously. > > And your code needs python 3.4, 3.2 isn't new enough. 3.3 is fine. I could try to figure which 3.2 -> 3.3 "improvement" caused the issue, except that it's only a prototype... Brian From nobody Wed Mar 29 16:01:39 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7FD129631; Wed, 29 Mar 2017 16:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 apNzLDl67z0U; Wed, 29 Mar 2017 16:01:30 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 D702712967E; Wed, 29 Mar 2017 16:01:21 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id y18so11430703itc.2; Wed, 29 Mar 2017 16:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=z3NQr6PmrxvynVU1cLKKReWc5O/wpv8YszuQDLz7kmQ=; b=GQHvN0s6ezlw2quvyGoBOEt8xjEzC5MyZGItnXpMxJNr6e+W/dbzfR/ym7cfX6Dygp 8ynaPdeHMX4tB00ySamWAHHqt3KLjDdnxGmg56BA4kf6fb7Fqg55p9KQ8R4eg+m1tITR Hg2uFaX/7Lpiqb8HchrqlWRORE2hniqE3s27XyWTCaaKWeodkbM1kxYKB+/Jff1EZ3Cs Ed1vi9A7HRWA/6W7FV0XjunnpqAt7poqc8+YFO4Lfza9vQn10bpR3dQuLBnh3NHYcjt5 y5SdruibIPkM4T8FRCPmvjDwAJSq4IwgdhDDT59bZDKA3FnaCWCTRbc8nWAfLusOydtE p1fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=z3NQr6PmrxvynVU1cLKKReWc5O/wpv8YszuQDLz7kmQ=; b=KVErrBcmNZGqildmnv1e0PXqqhCj2gjbrrfR8+WB7Yk0MQSFKQtHYPSAWmaGpnCpoe FA1toHXWlx3F87AFqGPEjOTF5SoyIrIS8kfqphNkJMjyVxf3KzU76HdAXzw+92KnSENF WcavZv9jT51DOEszbbiG/+X5LlyxiszowGlDvSpS1GX8o2idr/xZ7iQ7cxCzGkPzW52P QVeiCLnvFstC+EmoyQ+QMB97LqLSx2quRv185piJHrMIty7RbE5BQkT9BsdXmtPPD1Ul kEg96ZUR3hcies22xOuVuYoMh01D5BNzw2CvIem1bUY7hWng/5IPKjvkDfD+qqRQIZmx WJsA== X-Gm-Message-State: AFeK/H2t/tcnlanqGhU4a6iq8Sn/EWiCzjF2j2h4DL8R8zKJX5mrFpPcv5vjmMlsuvHCFQ== X-Received: by 10.36.87.136 with SMTP id u130mr1080438ita.100.1490828481039; Wed, 29 Mar 2017 16:01:21 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p6sm424258iof.12.2017.03.29.16.01.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 16:01:20 -0700 (PDT) To: Juliusz Chroboczek References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> Cc: Michael Richardson , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 12:01:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87r31fhk0d.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 23:01:33 -0000 On 30/03/2017 10:04, Juliusz Chroboczek wrote: >> There's already a thing called an HNCP agent. Why couldn't >> it be enhanced to negotiate with an upstream ASA for resources? > > Could you please clarify what you mean by "negotiate"? Current HNCP > implementations are provided with a bunch of External Prefixes, which they > then carve into /64, one per prefix. Are you envisioning a scenario where > the HNCP implementation actually performs active negotiation on its > external interfaces? Yes. But if it's a useless use case, that's fine. I was motivated to point out that there *really* is no conflict between the homenet work and Anima, and that they could be complementary if we want. Brian From nobody Wed Mar 29 16:04:54 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73564129631; Wed, 29 Mar 2017 16:04:52 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 xq7zwxoZaaKl; Wed, 29 Mar 2017 16:04:50 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 64F7F129572; Wed, 29 Mar 2017 16:04:50 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id 190so11422060itm.3; Wed, 29 Mar 2017 16:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cTFHsouxE3/yMR/FXksA1Btsf0Q1oZje3k8oykMT7x4=; b=gEtx2tnxJtPuzaRKjRYNT25gm+dgypFrn7KBO2sOl5yn/dIRX36L4j5vHqOTwkmAJV P5/609heesE913NhtOmXCAvW081CEqdauQM8eC5Vm2w73cwyhc7GrD5owFzlE+ifq07+ 9DEgYmbnKuanhFp4ZtO/eEdbzjCwx2M3OwIorFHNJCcLK8y8ZXtbueUF0Kid4NsaLGdf Zslw8mD3ZaVaQdYWilx8Tt+1vnW5FrlJKC5CDqiz/jM+ohFs2rP3rfiwyL7oUWBHv3/T LsbHhJFaJ7Qxu2RWgJhDekmtAL8t10afXPj9XFdNHY+ciDpzlaCO4ilvxMcJgJSl4jPk fT+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cTFHsouxE3/yMR/FXksA1Btsf0Q1oZje3k8oykMT7x4=; b=WeeUppyXueSkeN+z8lmFmQywwCZ4l9wYKzG009lw+6V7dQ9Clw3EC+Eb+g7iquUMKY O8EdgTqy5XjF2y/IUNMMyM5FcfW072f8EqpR+tPhRwC8NXUq8XeA/loUSD1+BGuiqZPA utVel1RFN5hNQWGi42FSfFvIaAsPmaSDNtjB8fML5qv2/yRcMCIMhQhHtqgv/V7vGkra PK6NsMbdCQfHWzoYP0HwQhgXNBtnWX3SRuGuR4Dw8kvNtyJxYUpkyzb3MrIn0XcdBCav 40PdOIoV4z0EhgtebWsUWqkukZe/5d8gD74rHEkYeWEmlFRb4zME7ArzrpJYIE0r451Y 0xRA== X-Gm-Message-State: AFeK/H2bIBnMFYff0+cj/rDBxCBAc+Wca+KImhkw/HQQVRDOFHJoCosmpegxrRil6MqG6Q== X-Received: by 10.36.87.15 with SMTP id u15mr1091888ita.58.1490828689611; Wed, 29 Mar 2017 16:04:49 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b126sm410720ioa.55.2017.03.29.16.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 16:04:48 -0700 (PDT) To: "Mark Townsley (townsley)" , Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> Cc: "homenet@ietf.org" , "casm@ietf.org" , "anima@ietf.org" From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 12:04:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 23:04:52 -0000 On 30/03/2017 11:14, Mark Townsley (townsley) wrote: > >> On Mar 29, 2017, at 10:04 AM, Michael Richardson wrote: >> >> >> This discussion started in a private thread, so I'll try to bring people >> up-to-date by repeating and moving around text. >> >> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is >> to do distributed prefix allocation. This is very much in the space of >> *coordinated* address management. >> >> (My take, BTW, is that CASM should be considered the first spin-off WG >> From ANIMA...) >> >> Mark and Brian discussed how HNCP does prefix distribution within Homenet. > > I was really pointing out that RFC 7695 could be used independent of HNCP. > > HNCP is just one protocol that uses the RFC 7695 distributed prefix assignment algorithm (which actually began as extensions to OSPF before HNCP even existed). True. And I don't see any reason why a CASM system including autonomic service agents shouldn't be used to supply prefixes for use by an RFC7695 implementation. So the various tools can fit together. Brian > > - Mark > >> >> Brian then suggests: >> >> brian> But if the CE includes a little autonomic service agent (ASA) which >> brian> is in the ISP's security domain (not the SOHO domain), it can act for >> brian> HNCP to solicit address space from the ISP. That's the southern side >> brian> of the CASM model and the northern side of HNCP. >> >> I asked a simple question: don't we have DHCPv6 for this? >> >> I also then asked: >> >>> a) the CPE device is now part of the ISP's ACP. >>> That's okay if the CPE device is owned by the ISP and/or the CPE device >>> includes some kind of trusted computation environment. >>> {But a CPE owned by the ISP, might not be trusted by the home owner, >>> so another router in between would be needed, >> >> Brian answered: >>> Really? Why not? >> >> I don't think that the ISP can trust to have code controlled by end users >> running in their ACP domain. >> >> I also think that many end-users will be quite reasonably upset that their >> ISPs can snoop on their internal traffic. This may in fact violate many >> work-at-home agreements; which is often the case of why you see multiple >> routers/firewalls in documents like >> https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. >> >> (Fred had more interesting diagrams in presentations, which I could dig up) >> >>>> b) DHCPv6 PD is already the protocol that solves prefix allocation across >>>> trust boundaries. >> >>> Indeed. That's why we have "PD supported" as a Boolean property of the >>> PrefixManager objective. There's no intention to undermine PD. >> >> Why do I need to run a protocol in order to find if I can run a protocol, >> when DHCP has the same mechanism already. And use of DHCPv6 itself is well >> defined in cable and DSL connections already. >> >>>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals with >>>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to the north. >> >>> Yes, the DSLAM is definitely a good place to put one. >> >> >>>> North of the ISP's device would be the ISP's (distributed) IPAM. >>>> GRASP/ASA-Prefix would be the protocol between. >> >>> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are >>> complementary not competitors. >> >> I don't see you saying that. >> >> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP >> in the home) such that they interact directly, rather than using PD. You >> say this right here: >> >> brian> But if the CE includes a little autonomic service agent (ASA) which >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Mar 29 16:12:50 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01EB1296BF; Wed, 29 Mar 2017 16:12:48 -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 j4-15ZYqhCar; Wed, 29 Mar 2017 16:12:46 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 56D7012969C; Wed, 29 Mar 2017 16:12:42 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id 190so11437448itm.3; Wed, 29 Mar 2017 16:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8CGAL/RuUywWYk2fEbxCeGAyc+X0KJBT/AlqCrec1Mc=; b=QI+SpNfF8UzkJiBoPsDp1NzqBvVyhawTPqHJj0z27tRy0dg/r4vsgChIfMGY4HNk0B IVu91fMRHZBZGtsu4gT33u0dFJUs2dN0dvh4gQxPkFGbKR1zoQ+h8RwFcFSaZFeXYnlF O65EY3pGfA7fEkvJQ1HD6dAb5LsSz9xjR8rlWz+XTkhIh65tutJQLfRl6iUd8L9NbvST uRql75OBB4fIdF1xFWyLHkFXcCOYLmuayfu4+YGNOnafok5TTZjRcs5QmS8k4qMQLzqN LfXzHZZ1HjjzFOkVwPb0JtM1Ovr1HDiJY3ZfQIO9cBYYB+nR1o9ZWb/WdmW7LEEpyZHA ZHFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=8CGAL/RuUywWYk2fEbxCeGAyc+X0KJBT/AlqCrec1Mc=; b=Dk/9QCBK7xZqSmiZOA/HC+B7j8O2WfHJBqXDAlmSvRafqaY68dnX1LRps6jbyXgkiZ WiS9xvPAEEui/eWsYqzdlzorXqRNGpDjOUDBlq+H3nucvoyhB+F0944Tnzq4l0Rjgt9Y gVAhSC2vzp7dw1xk3xAU0s7lw1iZOB4GQItA9HvsmixHVQMqym6uLD8vgA5Owek5Fj75 PcA9agXsJX8S38gjiKZVsXWNTmJ2qFPjIZEemo9qZWeXH1FGuOVcg0ix6DBowAxw5K1E y+ial8w6CwiQa+XqbVJ2TaoRNhxPFgOoLK79eSjwBzjNvZMKzMLtUQLgfScMDpTD7SOl jwzQ== X-Gm-Message-State: AFeK/H22XYpG5UA0lhKOKrFLpG7b4h7fHbp1j97RasDf8fPhstD6qMdecbWZvz/tMj4qTg== X-Received: by 10.36.111.9 with SMTP id x9mr1160426itb.102.1490829161628; Wed, 29 Mar 2017 16:12:41 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b25sm433380iod.32.2017.03.29.16.12.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 16:12:41 -0700 (PDT) To: Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <916.1490823535@obiwan.sandelman.ca> Cc: casm@ietf.org, anima@ietf.org, Mark Townsley , homenet@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 30 Mar 2017 12:12:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <916.1490823535@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 23:12:48 -0000 On 30/03/2017 10:38, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> I just don't see the point of the ASA here. > > > There's already a thing called an HNCP agent. Why couldn't > > it be enhanced to negotiate with an upstream ASA for resources? > > Because it's already done. It's called DHCPv6. > It already has extensive running code :-) > It's not even that complex. All true. But it isn't designed for negotiation as far as I know, just a request/response. > I would love to request address space via ASA from the DHCPv6 server. > That would all happen within the ISP's ACP though. Agreed, that is a little higher up the food chain. Maybe that is as close to the user as an ASA will get. I don't really care; I just wanted to explore the way we might fit our various tools together. > Right now (on DSL lines), the address space mostly comes via radius. > Which is to say that the problem has been centralized by MBS builders into > being someone else's problem. Advertising the address space is often done by > OSPFv3, but there are additional things that would be easier for the DHCPv6 > server to do, such as the DNS delegations that homenet is working on > finishing. Yes, indeed, and then we could discuss how the radius server gets new address space when it runs out. > I think that CASM could very nicely define/extend the prefix ASA to deal with > DNS reverse names, and as the RIRs (George) said, better link the delegated > prefix to clear ownership records. Yes, by defining a full set of relevant objectives. Brian From nobody Wed Mar 29 16:23:47 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CF31287A0; Wed, 29 Mar 2017 16:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 U4On6zk8OT_y; Wed, 29 Mar 2017 16:23:44 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B30A12773A; Wed, 29 Mar 2017 16:16:51 -0700 (PDT) Received: from [10.61.228.52] (unknown [173.38.220.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 2B52A564797; Thu, 30 Mar 2017 01:16:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Pierre Pfister In-Reply-To: Date: Wed, 29 Mar 2017 18:16:43 -0500 Cc: Mark Townsley , Michael Richardson , "homenet@ietf.org" , "casm@ietf.org" , "anima@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3259) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Mar 30 01:16:47 2017 +0200 (CEST)) Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 23:23:46 -0000 > Le 29 mars 2017 =C3=A0 18:04, Brian E Carpenter = a =C3=A9crit : >=20 > On 30/03/2017 11:14, Mark Townsley (townsley) wrote: >>=20 >>> On Mar 29, 2017, at 10:04 AM, Michael Richardson = wrote: >>>=20 >>>=20 >>> This discussion started in a private thread, so I'll try to bring = people >>> up-to-date by repeating and moving around text. >>>=20 >>> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is >>> to do distributed prefix allocation. This is very much in the space = of >>> *coordinated* address management. >>>=20 >>> (My take, BTW, is that CASM should be considered the first spin-off = WG >>> =46rom ANIMA...) >>>=20 >>> Mark and Brian discussed how HNCP does prefix distribution within = Homenet. >>=20 >> I was really pointing out that RFC 7695 could be used independent of = HNCP.=20 >>=20 >> HNCP is just one protocol that uses the RFC 7695 distributed prefix = assignment algorithm (which actually began as extensions to OSPF before = HNCP even existed). >=20 > True. And I don't see any reason why a CASM system including autonomic = service > agents shouldn't be used to supply prefixes for use by an RFC7695 = implementation. > So the various tools can fit together. Absolutely. RFC7695 Applicability Statement (Section 3.) explains that = the algorithm can be used as long as participating nodes gets configured with an eventually = consistent set of non-overlaping prefixes, which are then used to carve-out sub-prefixes that are assigned to = link/nodes/objects/toasters. - If ANIMA provides a protocol capable of configuring nodes with such a = set of delegated prefixes, RFC7695 can be used.=20 - CASM can also be used, as discussed earlier, in order to provision = HNCP (by the mean of a border router), and hence be used as a = provisioning mechanism to Homenet border routers. - If CASM intends to adopt a distributed architecture, and assuming the = existence of a reliable flooding protocol (AFAIK, grasp would be capable = of such a thing), RFC7695 could be used in order to reliably carve and = assign prefixes out of available addressing space. =20 - Pierre >=20 > Brian >>=20 >> - Mark >>=20 >>>=20 >>> Brian then suggests: >>>=20 >>> brian> But if the CE includes a little autonomic service agent (ASA) = which >>> brian> is in the ISP's security domain (not the SOHO domain), it can = act for >>> brian> HNCP to solicit address space from the ISP. That's the = southern side >>> brian> of the CASM model and the northern side of HNCP. >>>=20 >>> I asked a simple question: don't we have DHCPv6 for this? >>>=20 >>> I also then asked: >>>=20 >>>> a) the CPE device is now part of the ISP's ACP. >>>> That's okay if the CPE device is owned by the ISP and/or the CPE = device >>>> includes some kind of trusted computation environment. >>>> {But a CPE owned by the ISP, might not be trusted by the home = owner, >>>> so another router in between would be needed, >>>=20 >>> Brian answered: >>>> Really? Why not? >>>=20 >>> I don't think that the ISP can trust to have code controlled by end = users >>> running in their ACP domain. >>>=20 >>> I also think that many end-users will be quite reasonably upset that = their >>> ISPs can snoop on their internal traffic. This may in fact violate = many >>> work-at-home agreements; which is often the case of why you see = multiple >>> routers/firewalls in documents like >>> = https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router. >>>=20 >>> (Fred had more interesting diagrams in presentations, which I could = dig up) >>>=20 >>>>> b) DHCPv6 PD is already the protocol that solves prefix allocation = across >>>>> trust boundaries. >>>=20 >>>> Indeed. That's why we have "PD supported" as a Boolean property of = the >>>> PrefixManager objective. There's no intention to undermine PD. >>>=20 >>> Why do I need to run a protocol in order to find if I can run a = protocol, >>> when DHCP has the same mechanism already. And use of DHCPv6 itself = is well >>> defined in cable and DSL connections already. >>>=20 >>>>> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that = deals with >>>>> prefixes. It would speak DHCPv6-PD to the south, and GRASP/ASA to = the north. >>>=20 >>>> Yes, the DSLAM is definitely a good place to put one. >>>=20 >>>=20 >>>>> North of the ISP's device would be the ISP's (distributed) IPAM. >>>>> GRASP/ASA-Prefix would be the protocol between. >>>=20 >>>> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are >>>> complementary not competitors. >>>=20 >>> I don't see you saying that. >>>=20 >>> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, = and HNCP >>> in the home) such that they interact directly, rather than using PD. = You >>> say this right here: >>>=20 >>> brian> But if the CE includes a little autonomic service agent (ASA) = which >>>=20 >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Mar 30 07:46:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB4012922E; Thu, 30 Mar 2017 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 Dmig_WhXRgpE; Thu, 30 Mar 2017 07:46:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE6712706D; Thu, 30 Mar 2017 07:46:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 146A4203AD; Thu, 30 Mar 2017 11:09:58 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BB607636BB; Thu, 30 Mar 2017 10:45:59 -0400 (EDT) From: Michael Richardson To: Juliusz Chroboczek cc: Brian E Carpenter , Mark Townsley , homenet@ietf.org, casm@ietf.org, anima@ietf.org In-Reply-To: <87h92bhhhh.wl-jch@irif.fr> References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> <87h92bhhhh.wl-jch@irif.fr> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:46:04 -0000 --=-=-= Content-Type: text/plain Juliusz Chroboczek wrote: >>> Could you please clarify what you mean by "negotiate"? Current HNCP >>> implementations are provided with a bunch of External Prefixes, which they >>> then carve into /64, one per prefix. Are you envisioning a scenario where >>> the HNCP implementation actually performs active negotiation on its >>> external interfaces? >> Yes, that's what Brian is suggesting. >> The HNCP daemon would speak GRASP ASA on the "northbound" interface. > Sorry if I wasn't clear. Would it merely request address space and handle > it out using HNCP, or would it actively renegotiate address space in > response to HNCP events? > If the latter -- why? It would hand out space via HNCP, and if it ran out of space, get more. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdGicACgkQgItw+93Q 3WWMlwgAl2WAbqmbiT8TAGHIMHZ1Annwj1stda9GhqGU6bxJkOC77GcKFHK34h5E eoxYV/0g4HAg8ZFn6dP2Pfli9uIFQ3TCJCpOw/3aQbYgK0J+5a0K5lPA+lwGopB+ goLAMyjU7Tewzo0K6aSvmKNcxfeJkxcqJLaxURXs0Xc/n5F0Gtp2NfntH9ljjuI6 XvLRk2jkc7HZWLnpwaQd3KmjuNCcObQjXWcopuMwsB1Kz/OvTuLIcq1R7QrehFr4 BON17dnTBC8rVyCQ+ZETsjFafTlRTnaen0vgxmqv0TvPnPoNNWkMSGUZ/C02UQan NoLcrprgqlWTCn5XbGNtmQro8N2vrA== =XGT1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 07:50:42 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3785A1294EC for ; Thu, 30 Mar 2017 07:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 aA0NlIfGmNwl for ; Thu, 30 Mar 2017 07:50:39 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 68BDD1294D8 for ; Thu, 30 Mar 2017 07:50:39 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id f84so20569760ioj.0 for ; Thu, 30 Mar 2017 07:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Yi/kzougTnU3ZgNQxjBPkBPsMVDd+mswulKoBxMqF1M=; b=P1WraYwOvE/GMDRw9AucHuHGl7ZnDrATdAdw0rHuohkDTkZBeLGNCyCSLFAoA1k3Hq btcOPvk0Bgya2rlMRG20foYNlNX9I//WghEkk/0dusQBDlucq5S712HAhjWMfXpCLVWm mLiXA2ZW50LzUG9lvEIiSLXh7FGpydxw6zRHt5cUuEpanKGoGSNIE0jptQy9GP5XsM0+ sMV+BiDNasEvJUyERrLnbNHkwz75RvUsCY5n2zR3B6DPd6mu8uW2xzOUAev8A4MSwdpy VWxgvEi7PVAbLoQTaO0PpySg/HqnZLJF9HUWgmNJJ0drRgcfEW9QwnvP/wTdxKnh8Fw2 vryQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Yi/kzougTnU3ZgNQxjBPkBPsMVDd+mswulKoBxMqF1M=; b=GNg5iWIj3p5ilbZRibUeKHNy9HCZM05ry9efbngxFwchkrQcEEBsaqSxksY/VO65+w EBE8LwobmTSl1ZrzPKpa77ORoQdLai0/8VnUf4Y/J7zGd+sS9/1kPUCmGkCwO4OLCTVa F335CnL6ztY+HwJr6FKlrcaIKMzSecBioVUTmgh5HDi/gqMbgwJZEwXzMVd0ThXhwcNP XHPoqii0f20EwxMQu8zBdQyHaUBSy0sXOasDL/of2RX1kpHMpm1fRPUtHA0xPz54vn64 xjzcN18hVYZ/z0Wap1npEcOseeNVO3+su1eXFA0WXLvSvZb+TUGV7PaTdZMoRfINpCM2 70cw== X-Gm-Message-State: AFeK/H1cMyeXbOERTh2BMpfLT6TKjVahWZ99uE0E0xIBBihxN16cu0cMkkObOa6WSDB6rA== X-Received: by 10.107.35.198 with SMTP id j189mr868764ioj.76.1490885438787; Thu, 30 Mar 2017 07:50:38 -0700 (PDT) Received: from t2001067c0370199861d1a9fa7f011c21.v6.meeting.ietf.org (t2001067c0370199861d1a9fa7f011c21.v6.meeting.ietf.org. [2001:67c:370:1998:61d1:a9fa:7f01:1c21]) by smtp.gmail.com with ESMTPSA id q185sm5120992itc.22.2017.03.30.07.50.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 07:50:37 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 30 Mar 2017 09:50:36 -0500 In-Reply-To: <969.1490885159@obiwan.sandelman.ca> Cc: Juliusz Chroboczek , Mark Townsley , HOMENET , anima@ietf.org, casm@ietf.org To: Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> <87h92bhhhh.wl-jch@irif.fr> <969.1490885159@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:50:41 -0000 --Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 30, 2017, at 9:45 AM, Michael Richardson = wrote: > It would hand out space via HNCP, and if it ran out of space, get = more. This can also be done with DHCP. --Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Mar 30, 2017, at 9:45 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
It would hand out space via HNCP, and if = it ran out of space, get more.

This = can also be done with DHCP.

= --Apple-Mail=_B248B620-BC86-4DF1-BDA7-EE4F86932942-- From nobody Thu Mar 30 07:52:01 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A26D12950E; Thu, 30 Mar 2017 07:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 DkMp-I1Wqxg0; Thu, 30 Mar 2017 07:51:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F39120726; Thu, 30 Mar 2017 07:51:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5966F203AD; Thu, 30 Mar 2017 11:15:49 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 122CA636BB; Thu, 30 Mar 2017 10:51:51 -0400 (EDT) From: Michael Richardson To: "homenet\@ietf.org" , "casm\@ietf.org" , "anima\@ietf.org" CC: Pierre Pfister , Brian E Carpenter , Mark Townsley In-Reply-To: References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <4C898133-C860-4369-8BDC-E5868CA70EB9@cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:51:54 -0000 --=-=-= Content-Type: text/plain Pierre Pfister wrote: > Absolutely. RFC7695 Applicability Statement (Section 3.) explains that > the algorithm can be used as > long as participating nodes gets configured with an eventually > consistent set of non-overlaping prefixes, > which are then used to carve-out sub-prefixes that are assigned to > link/nodes/objects/toasters. I think that I can envision a situation where a largish distributed enterprise could use auto-configuring Homenet technology in a "Small Office" configuration, and would use a CASM/ANIMA mechanism at the edge to ask for more address space from HQ. (That could well be occuring via a VPN, or some dark fiber, doesn't matter) In that case, the HNCP and ANIMA parts would be in a common trust environment. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljdG4YACgkQgItw+93Q 3WUbwwf/ZiCAABSrUsDqCI8zjLTV3Cz+VsFLSstl7cQyBOJx8qac3FlmiuD1UaO0 PptytK/0ttqbm6h0Pzn6aSUri9p0F7gyxu6ou95NuyEni1bOSNad0DDrbKPjdiKV CIRxi6WTNzi3GcjtDhLp9BCIY4Xs7HZUkga5RXzWjoFMO9uOorh/fZF+trImegGt ymKSK4tA8DPLPZ6m8qB2V3sc6sOhDtXsHekMU4y+iHWKHjQZmHEtGCYisoDLnlm0 8iMRqZnX0PU5wT3rc3YopS8g5f0rarCoyHJyJvHQQYhtc+MNWunJDvyPIDjzoqB2 FfZpQ+FGGIwqbJ04awCJCR9OZ7FXbQ== =/lkD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 30 08:27:05 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835EF1296CD; Thu, 30 Mar 2017 08:26:53 -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 e7IRGCtUj_tU; Thu, 30 Mar 2017 08:26:51 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 2BDD912952F; Thu, 30 Mar 2017 08:26:51 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id n76so3216199ioe.1; Thu, 30 Mar 2017 08:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GgB26uphbGPvc5jOBtWTx/6FP8vWqNeVvu9tzTlcc/4=; b=b6yBTqKuG/yM6mxinQa5pESkrT0lQaEKj4H/V73yc0EmKvY0CKlC8eOFfKqgFdgElT RTXpKnXxq5Rpbt0j4BDynuBR0WuRxlgcXzF7c06qC6O+EIuEOCC8ZVy2QRhYxIurgLCw EOsDaJ+1PnDnwxehCstuCjzsQDb53pZ9Y6kQnY4sL/WwyiEZracjmsoYZ7DHJCu9F+jJ r8ALFGCDNkwmFbu3f5iYgQeX/lZU642wIP+3DqlQFSnZyFDHJQydly5WvcLTKswQqI3k K/8CgOj9+GM90XhA2csQbGHaAyIKn7dpW6GMuYHdxDs2ReZK35y6kg9tBELcX7HA+moQ rwPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GgB26uphbGPvc5jOBtWTx/6FP8vWqNeVvu9tzTlcc/4=; b=ngg7gi5w2KMh3LU5hLhtlU8Li7YdeuJSzCx3i0cgd3QR7dFNjhwvqTIZZZ02HHTW4h juGC/wrCF4c/6PX7zMZzP0QQFeHbcfbgCM7uSw+GyQPNWej0Gw64CV902X/OoS3W4lH1 bmjga89Di/U2gCD4DhS65HUVbZ7q10urX5CaU2sTzQ7SVG2OGN6J6IjhaDrlchipHSVz +8VJsO951hoDw+csks7Iy/KPbS/dMQdSqCi+WJTEOcb4tnMMxnXqsh1a0ttwlg7jNBOp X0JLRCXrjyTxG2THbotLcgnqNr07rjedcDztE8OcS6ZheJo9GGXvVpYTWHvWAdtUUeZ7 rTuQ== X-Gm-Message-State: AFeK/H1P3Cw3SwXu6gBT0pX2yDJ1CDOXeobgU0nk5BdKSB0pJhHmTxacRLpVp1/VOaYrpQ== X-Received: by 10.107.35.211 with SMTP id j202mr1091444ioj.158.1490887610461; Thu, 30 Mar 2017 08:26:50 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f196sm1178412itc.2.2017.03.30.08.26.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 08:26:49 -0700 (PDT) To: Ted Lemon , Michael Richardson References: <21984.1490644275@obiwan.sandelman.ca> <9240.1490649148@obiwan.sandelman.ca> <672bec4c-0e93-362c-21bf-99938cd0a066@gmail.com> <27800.1490654163@obiwan.sandelman.ca> <27680a33-708d-84b7-f378-3a47ee71840a@gmail.com> <2491.1490716597@obiwan.sandelman.ca> <5a41375c-2a4c-d5ca-e703-06d8e76f8728@gmail.com> <28218.1490799848@obiwan.sandelman.ca> <14579.1490818588@obiwan.sandelman.ca> <53a40584-bc26-e7ec-e4c9-e76c86dcec03@gmail.com> <87r31fhk0d.wl-jch@irif.fr> <1636.1490823705@obiwan.sandelman.ca> <87h92bhhhh.wl-jch@irif.fr> <969.1490885159@obiwan.sandelman.ca> Cc: Mark Townsley , HOMENET , anima@ietf.org, Juliusz Chroboczek , casm@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <1aab4a0c-24bc-1b4b-0c0d-8ab7ba38726f@gmail.com> Date: Fri, 31 Mar 2017 04:26:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [homenet] prefix assignment X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 15:26:54 -0000 On 31/03/2017 03:50, Ted Lemon wrote: > On Mar 30, 2017, at 9:45 AM, Michael Richardson wrote: >> It would hand out space via HNCP, and if it ran out of space, get more. > > This can also be done with DHCP. Indeed. I'm not trying to force the Anima approach, just pointing out that it will be available in contexts where more than a simple PD operation might be appropriate. Brian From nobody Thu Mar 30 12:16:42 2017 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F8A12778D; Thu, 30 Mar 2017 12:16:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149090139505.15603.6042033943301646669@ietfa.amsl.com> Date: Thu, 30 Mar 2017 12:16:35 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-11.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:16:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. Title : A Generic Autonomic Signaling Protocol (GRASP) Authors : Carsten Bormann Brian Carpenter Bing Liu Filename : draft-ietf-anima-grasp-11.txt Pages : 77 Date : 2017-03-30 Abstract: This document establishes requirements for a signaling protocol that enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-11 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 30 12:21:07 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15151129441 for ; Thu, 30 Mar 2017 12:21:06 -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 JNYztNfItZ-y for ; Thu, 30 Mar 2017 12:21:03 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 C7A8F126C3D for ; Thu, 30 Mar 2017 12:21:03 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id z13so26341337iof.2 for ; Thu, 30 Mar 2017 12:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1xbG9kdFM8Ow3vZGJl1VfqVwEm5t3J6JypVFvN6TX0Y=; b=rb87EjYGmMm/kudY6uFTDkUVC3n+MpLBfCAnADD7B+oTw71z9w39Ktzy82TJL8/+CZ 86ID4m4tEIxPqTli77OS3qxsnhpcr3dV/vNWD6cvNdXO+vXHWVrg35xeqf8iIvb6Zfg5 7+SWM5yqE6GMLGB5nlnhMwpCcILyfzmkBXJY+Yo4GJUQDGu8wiqYvIvakpqn8abFzOhf Dwl/XS1k90uGOxFS2ZiG/ymLQmruJnEZi77mbLr5nN2b/UjIwocdf3dOXttcqorHIRd3 3/aBU4+iXBDBrbwtl5twKlvFY0qpiE1ddZx0Ymg/LMeu7Alc3c/eO1oKfiT/gaYOBxxj wgdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=1xbG9kdFM8Ow3vZGJl1VfqVwEm5t3J6JypVFvN6TX0Y=; b=qFHS5/4pqoCtxo5lw53qXKwOMOcVPkiYExaPCnJQQ+o2MHOSgTnbVSk/y8JPtx6JnT 41C/Dl4kiyvZx+TtTLWN6n9RcDIdtS6WMnuFPNtf3jHeR7lQtCci2uM/OsoZdLZV4F5V IyCM42WeXJWnHg99arBcBGzubyPUOzoVqOYTvglPpDlcRcKtBBTwEYjOhvekQPN0Zp3y g9orSbi7fyrcy1LTucg8TiaiuYBe2sFmmPmVxEhUUk7R+4ykps4QxEW/UqSb+2pIp1Ab TFQrPsnAtSbI+SxOG5sinZrrKjxG+6BYwLkBXl3erFLnf4dVLNXzYwfBfUNGPzz4Yrw0 yWuw== X-Gm-Message-State: AFeK/H2PweB75BVxe5lQ5trKjpqV/rCi2BJ51qbht8hhGtTxrs34otimsNSCwCdqQ0Eidg== X-Received: by 10.107.140.82 with SMTP id o79mr2511844iod.17.1490901662982; Thu, 30 Mar 2017 12:21:02 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? (t2001067c0370012828ccdc4c97036781.v6.meeting.ietf.org. [2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 89sm1904022ioj.17.2017.03.30.12.21.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 12:21:02 -0700 (PDT) References: <149090139505.15603.6042033943301646669@ietfa.amsl.com> To: anima@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 31 Mar 2017 08:21:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149090139505.15603.6042033943301646669@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-11.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:21:06 -0000 This version has updates that are supposed to close the open issues discussed on Monday: Encryption changed to a MUST implement. Pointed to guidance on UTF-8 names. Over to the WG Chairs and AD for the next step. Regards Brian, Bing, Carsten On 31/03/2017 08:16, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF. > > Title : A Generic Autonomic Signaling Protocol (GRASP) > Authors : Carsten Bormann > Brian Carpenter > Bing Liu > Filename : draft-ietf-anima-grasp-11.txt > Pages : 77 > Date : 2017-03-30 > > Abstract: > This document establishes requirements for a signaling protocol that > enables autonomic nodes and autonomic service agents to dynamically > discover peers, to synchronize state with them, and to negotiate > parameter settings with them. The document then defines a general > protocol for discovery, synchronization and negotiation, while the > technical objectives for specific scenarios are to be described in > separate documents. An Appendix briefly discusses existing protocols > with comparable features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-11 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Fri Mar 31 07:34:00 2017 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B241296B1 for ; Fri, 31 Mar 2017 07:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 mqpc6dwcZC5R for ; Fri, 31 Mar 2017 07:33:57 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4655212987B for ; Fri, 31 Mar 2017 07:33:55 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B65D558C4AE for ; Fri, 31 Mar 2017 16:33:51 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9B2A3B0BB82; Fri, 31 Mar 2017 16:33:51 +0200 (CEST) Date: Fri, 31 Mar 2017 16:33:51 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20170331143351.GF29793@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Anima] jabber X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:33:59 -0000 Sorry folks, got problems with jabber, so can not join it during todays anima WG meeting.